coreboot July 2017

coreboot@coreboot.org

54 participants
131 discussions

Re: [coreboot] Ethernet/Wifi not working with coreboot/seabios/me_cleaner on a Thinkpad x230
by John Lewis 06 Jul '17

06 Jul '17

Yes, as Pavel said, "remount-ro" is just what happens if the filesystem encounters an error which presumably it hasn't, at this point. :) On 06/07/17 12:11, Pavel Alyev wrote: > > > First line: mount without options from initrd. Second: remount "/" > with options from fstab. > > It's not mean what it mounted in ro mode. > > > 06.07.2017 13:59, Zoran Stojsavljevic пишет: >> > If there are critical dmesg values that can be optimized, do not hesitate to point them >> out! :) >> >> [user@localhost dungeon]$ cat marcelo_dmesg.log | grep EXT4 >> [ 2.127239] EXT4-fs (sda1): mounted filesystem with ordered data >> mode. Opts: (null) >> */_[ 2.332115] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro_/* >> [user@localhost dungeon]$ >> >> Line in */_RED_/* is concerning me. Do you have / ro? >> >> Zoran >> >> On Thu, Jul 6, 2017 at 11:42 AM, Marcel Maci <elpinguino(a)gmx.ch >> <mailto:elpinguino@gmx.ch>> wrote: >> >> >> > By that time (Y2161) I'll look something like this (200Y old man): >> > >> https://s-media-cache-ak0.pinimg.com/originals/b1/c9/8f/b1c98fb01833bdbd065… >> <https://s-media-cache-ak0.pinimg.com/originals/b1/c9/8f/b1c98fb01833bdbd065…> >> > >> > There are other problems (as well) in your dmesg log. But not to >> > spoil the situation (KUDOS to John). If you find anything else >> wrong, >> > just scream! ;-) >> > >> > Zoran >> >> Thx for the photo - I see you are optimistic for the future ... ;) >> If there are critical dmesg values that can be optimized, do not >> hesitate to point them out! :) >> >> Marcel >> >> >> >> > > -- > With best regards, > Pavel Alyev > anotherhosting.net chief administrator

2 1

Re: [coreboot] x86: best approach to debug consumer hardware?
by Andrey Korolyov 06 Jul '17

06 Jul '17

On Thu, Jul 6, 2017 at 8:20 AM, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: > OK, both Andrjusas, > > I am a bit ignorant, and I read beginning of the Coreboot log: > > DIMM 0 side 0 = 1024 MB > DIMM 0 side 1 = 1024 MB > DIMM 2 side 0 = 1024 MB > DIMM 2 side 1 = 1024 MB > tRFC = 43 cycles > Setting Graphics Frequency... > FSB: 667 MHz Voltage: 1.05V Render: 250MHz Display: 200MHz > Setting Memory Frequency... CLKCFG = 0x00010023, CLKCFG = 0x00010043, ok > Setting mode of operation for memory channels...Dual Channel Interleaved. > Programming Clock Crossing...MEM=667 FSB=667... ok > Setting RAM size... > C0DRB = 0x40404020 > C1DRB = 0x40404020 > TOLUD = 0x00d0 <<==========??? > > 4GB (two channel) memory, in two slots out of 4... ?! > > Top of Low Usable RAM 00d0h??? Any explanation for that? @Zoran Thanks, that could be the point, though it seem to be same low for X/T60 [0]. I would check if reading PCI space in Linux would result to same small address and may be this is the point (also I could quickly run completely headless kernel to verify that). > > Andy (Korolev), > > Did you manage to get to Linux emergency mode called Dracut? I think that you meant dracut-produced initrd and try it against SMP kernel, right? If I could get your idea, you are possibly suggesting to cut off every device from being initalized except SuperIO, get to ramdisk and try to work things out from there? I didn`t tried this yet, mainly because I don`t want to spend much time with blind efforts on very old laptop whose support has almost no real value... If I am wrong, please explain what you`ve suggested in there. > > So you are after memory contents? Freeze DIMMS, turn off memory scrambling > and flash firmware that dumps memory contents. In essence, cold boot attack. @Andrey That`s what I meant under 'spending few days', getting memory access during both cold-boot run and DMA-assisted run is a matter of tens of minutes, but the analysis of the dump would take much more time. The main problem is that I am losing dynamic picture for memory contents if I would do only post-mortem analysis and (with cold-boot attack) I`ll lose small portion of the memory state anyway, due to bootloader`s needs to initialize PCI devices (though I could imagine very slow and boring transfer using CAR and USB debug port and there`s bit of code need to be written for that). The fastest way to get close to the point of failure and see at least a dynamic stuff is, probably, a timer-based non-preemptible hack within ieee1394 driver which would literally freeze system to allow me to take snapshots without risk of hitting crash in the middle. Anyway, this closes down to analysis of what is going on within the dump and with Linux mm it`s not an easy task if you are not searching for something specific like LUKS key :) 0. https://mail.coreboot.org/pipermail/coreboot/2014-October/078752.html

1 0

Re: [coreboot] Ethernet/Wifi not working with coreboot/seabios/me_cleaner on a Thinkpad x230
by Pavel Alyev 06 Jul '17

06 Jul '17

First line: mount without options from initrd. Second: remount "/" with options from fstab. It's not mean what it mounted in ro mode. 06.07.2017 13:59, Zoran Stojsavljevic пишет: > > If there are critical dmesg values that can be optimized, do not hesitate to point them out! :) > > [user@localhost dungeon]$ cat marcelo_dmesg.log | grep EXT4 > [ 2.127239] EXT4-fs (sda1): mounted filesystem with ordered data > mode. Opts: (null) > */_[ 2.332115] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro_/* > [user@localhost dungeon]$ > > Line in */_RED_/* is concerning me. Do you have / ro? > > Zoran > > On Thu, Jul 6, 2017 at 11:42 AM, Marcel Maci <elpinguino(a)gmx.ch > <mailto:elpinguino@gmx.ch>> wrote: > > > > By that time (Y2161) I'll look something like this (200Y old man): > > > https://s-media-cache-ak0.pinimg.com/originals/b1/c9/8f/b1c98fb01833bdbd065… > <https://s-media-cache-ak0.pinimg.com/originals/b1/c9/8f/b1c98fb01833bdbd065…> > > > > There are other problems (as well) in your dmesg log. But not to > > spoil the situation (KUDOS to John). If you find anything else > wrong, > > just scream! ;-) > > > > Zoran > > Thx for the photo - I see you are optimistic for the future ... ;) > If there are critical dmesg values that can be optimized, do not > hesitate to point them out! :) > > Marcel > > > > -- With best regards, someone from somewhere...

1 0

Re: [coreboot] Ethernet/Wifi not working with coreboot/seabios/me_cleaner on a Thinkpad x230
by Zoran Stojsavljevic 06 Jul '17

06 Jul '17

> If there are critical dmesg values that can be optimized, do not hesitate to point them out! :) [user@localhost dungeon]$ cat marcelo_dmesg.log | grep EXT4 [ 2.127239] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) *[ 2.332115] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro* [user@localhost dungeon]$ Line in *RED* is concerning me. Do you have / ro? Zoran On Thu, Jul 6, 2017 at 11:42 AM, Marcel Maci <elpinguino(a)gmx.ch> wrote: > > > By that time (Y2161) I'll look something like this (200Y old man): > > https://s-media-cache-ak0.pinimg.com/originals/b1/c9/8f/ > b1c98fb01833bdbd06513a3ffc8f6590.jpg > > > > There are other problems (as well) in your dmesg log. But not to > > spoil the situation (KUDOS to John). If you find anything else wrong, > > just scream! ;-) > > > > Zoran > > Thx for the photo - I see you are optimistic for the future ... ;) > If there are critical dmesg values that can be optimized, do not > hesitate to point them out! :) > > Marcel >

1 0

Re: [coreboot] x86: best approach to debug consumer hardware?
by Andrey Petrov 06 Jul '17

06 Jul '17

On 07/05/2017 10:01 AM, Andrey Korolyov wrote: > The fourth/fifth points has very high likeness for the fact that the > regular kernel debugging would not help at all and I hardly imagine > myself spending few more days to manage firewire memory 'sniffer' to > work, though this method has highest successful potential among other > approaches, excluding (unavaiable due to pricing of the counterparting > LA) memory interceptor. What could be a suggestion to move on with > least effort at this point? So you are after memory contents? Freeze DIMMS, turn off memory scrambling and flash firmware that dumps memory contents. In essence, cold boot attack. Andrey

2 1

Re: [coreboot] x86: best approach to debug consumer hardware?
by Nico Huber 06 Jul '17

06 Jul '17

I'd start with examining the coreboot console log. Are there resource conflicts? Are all APs initialized? Was the microcode updated for all of them? etc... If you don't have it already, you can grab the log from your running non-smp OS with `cbmem -c` (see util/cbmem/ in the coreboot tree). Feel free to attach it, if you want somebody else to look through it. Nico On 05.07.2017 19:01, Andrey Korolyov wrote: > Hi, > > since I`ve got em100 few days ago, I decided to test it against one of > my x86 devices and try to put coreboot on it at once. The selection > was Z61m (T2400 CD/i945/82801). After fixing few things in i945 code > borrowed from t60, I noticed severe problem when I tried to use SMP > kernel, because most times I try stuff against non-smp i486 which is > common denominator for Geode. It looks like that all SMP boot-ups will > hang quite soon, just after a few seconds after jumping into > initrd/driver initialization stage. > > There are few points: > - sometimes video memory is corrupted, screen displaying periodical > flickering pattern (even if almost all late-stage linux drivers are > disabled), > - the hang itself is not accompanied by any SMI assertion or event > otherwise visible in the coreboot log, > - kernel also is unable to produce any kind of backtrace over all > (easily) available channels, > - usb port with an active usb stick may become unusable until entire > device is power-cycled with external switch, > - SMI poweroff handler is not responsive after the failure event. > > The fourth/fifth points has very high likeness for the fact that the > regular kernel debugging would not help at all and I hardly imagine > myself spending few more days to manage firewire memory 'sniffer' to > work, though this method has highest successful potential among other > approaches, excluding (unavaiable due to pricing of the counterparting > LA) memory interceptor. What could be a suggestion to move on with > least effort at this point? > > Thanks. >

2 1

Re: [coreboot] Overclocking Opteron 6200 from coreboot ?
by Taiidan＠gmx.com 06 Jul '17

06 Jul '17

On 07/05/2017 10:22 AM, BogDan Vatra wrote: > Thanks a lot for the link, it has a link to an overclocking software, which > I'll try it tomorrow :D . > > BogDan. It only works on ES CPU's :[

1 0

Re: [coreboot] x86: best approach to debug consumer hardware?
by Andrey Korolyov 05 Jul '17

05 Jul '17

> [1] Platform T2400/i945 -> > http://ark.intel.com/products/27235/Intel-Core-Duo-Processor-T2400-2M-Cache… > ... Am I correct? Yup. > [2] What is GEODE in this context? 500 Mhz i486AMD Geode processor (Single > HW threaded, one core, no HT)? Just a remark about how I got warning that late - I went through usual test routines on a non-SMP kernel because my basic test image does use it by default, primarily it is designated to a DB800 dev board. > [3] And what are the Linux distro and the distro kernel you are using > (version and size ? 32 : 64, please)? This is 32-bit CPU, so answer is obvious :) I think that I`m hitting the problem independent of the kernel version I am running, but I`ve tried few stable versions from 3.2 to 4.9 without spotting any noticeable difference. Windows hangs as well as soon as it finishes driver loading procedure, this is visible from safe mode. > [4] Am I reading that you are not able to produce dmesg? If YES, please, > post failing dmesg here! Nope, this is not the case. May be initial text is not clear enough, but I`m getting a 'dead' hang of the board itself - I mentioned that SMI handler is not chewing anything after this point, all the peripherals seem to be pretty dead as well, at least I was unable to see anything past the failure via usb debug and serial console. > [5] I assume that you have SeaBIOS as payload, don't you? > [6] Are you booting via GRUB? Yes, I am using SeaBIOS and GRUB for local boots. I could share a successful non-SMP dmesg as well as part of SMP dmesg before hang, but there are virtually zero points to take on. May be the only difference between dmesg contents over stock one aside complaining about missing hard-coded battery slot is the snip below, just because I didn`t fixed this yet (specific to native gfxinit, but board also happily hangs with stock vbios and smp kernel, just for the case) [drm] failed to find VBIOS tables vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [drm] initialized overlay support [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state > >> - sometimes video memory is corrupted, screen displaying periodical >> flickering pattern >> (even if almost all late-stage linux drivers are disabled), > > [7] Are you able to produce Xorg.0.log messages? If yes, could you post 'em > here? I honestly don`t think that this is the case - for non-SMP boot, the Xorg log absolutely resembles everything that I`m getting with vendor bios and for SMP boot system hangs a bit earlier. Video memory garbling is not a persistent but rather floating effect, forgot to mention that. > > I have also other ideas how to debug this all, but lets go with these for > starters, shall we??? ;-) I thought about hidden interrupt storm which could possibly manifest itself in that way, but I`ve never seen IS being *that* bad. Honestly I`m out of ideas why turning on SMP results in a horrible memory corruption/overlap, SMP-ed Memtest was able to pass few rounds without any warning. Even if all platform and peripheral drivers blacklisted, the problem still shows up, so it does not limit itself, at least obviously, to one single device whose DMA region(s) splats over areas where it shouldn`t be.

1 0

Re: [coreboot] x86: best approach to debug consumer hardware?
by Zoran Stojsavljevic 05 Jul '17

05 Jul '17

> - kernel also is unable to produce any kind of backtrace over all (easily) available channels, [1] Platform T2400/i945 -> http://ark.intel.com/products/27235/Intel-Core-Duo-Processor-T2400-2M-Cache… ... Am I correct? [2] What is GEODE in this context? 500 Mhz *i486*AMD Geode processor (Single HW threaded, one core, no HT)? [3] And what are the Linux distro and the distro kernel you are using (version and size ? 32 : 64, please)? [4] Am I reading that you are not able to produce dmesg? If YES, please, post failing dmesg here! [5] I assume that you have SeaBIOS as payload, don't you? [6] Are you booting via GRUB? > - sometimes video memory is corrupted, screen displaying periodical flickering pattern > (even if almost all late-stage linux drivers are disabled), [7] Are you able to produce Xorg.0.log messages? If yes, could you post 'em here? I have also other ideas how to debug this all, but lets go with these for starters, shall we??? ;-) Thank you, Zoran On Wed, Jul 5, 2017 at 7:01 PM, Andrey Korolyov <andrey(a)xdel.ru> wrote: > Hi, > > since I`ve got em100 few days ago, I decided to test it against one of > my x86 devices and try to put coreboot on it at once. The selection > was Z61m (T2400 CD/i945/82801). After fixing few things in i945 code > borrowed from t60, I noticed severe problem when I tried to use SMP > kernel, because most times I try stuff against non-smp i486 which is > common denominator for Geode. It looks like that all SMP boot-ups will > hang quite soon, just after a few seconds after jumping into > initrd/driver initialization stage. > > There are few points: > - sometimes video memory is corrupted, screen displaying periodical > flickering pattern (even if almost all late-stage linux drivers are > disabled), > - the hang itself is not accompanied by any SMI assertion or event > otherwise visible in the coreboot log, > - kernel also is unable to produce any kind of backtrace over all > (easily) available channels, > - usb port with an active usb stick may become unusable until entire > device is power-cycled with external switch, > - SMI poweroff handler is not responsive after the failure event. > > The fourth/fifth points has very high likeness for the fact that the > regular kernel debugging would not help at all and I hardly imagine > myself spending few more days to manage firewire memory 'sniffer' to > work, though this method has highest successful potential among other > approaches, excluding (unavaiable due to pricing of the counterparting > LA) memory interceptor. What could be a suggestion to move on with > least effort at this point? > > Thanks. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

x86: best approach to debug consumer hardware?
by Andrey Korolyov 05 Jul '17

05 Jul '17

Hi, since I`ve got em100 few days ago, I decided to test it against one of my x86 devices and try to put coreboot on it at once. The selection was Z61m (T2400 CD/i945/82801). After fixing few things in i945 code borrowed from t60, I noticed severe problem when I tried to use SMP kernel, because most times I try stuff against non-smp i486 which is common denominator for Geode. It looks like that all SMP boot-ups will hang quite soon, just after a few seconds after jumping into initrd/driver initialization stage. There are few points: - sometimes video memory is corrupted, screen displaying periodical flickering pattern (even if almost all late-stage linux drivers are disabled), - the hang itself is not accompanied by any SMI assertion or event otherwise visible in the coreboot log, - kernel also is unable to produce any kind of backtrace over all (easily) available channels, - usb port with an active usb stick may become unusable until entire device is power-cycled with external switch, - SMI poweroff handler is not responsive after the failure event. The fourth/fifth points has very high likeness for the fact that the regular kernel debugging would not help at all and I hardly imagine myself spending few more days to manage firewire memory 'sniffer' to work, though this method has highest successful potential among other approaches, excluding (unavaiable due to pricing of the counterparting LA) memory interceptor. What could be a suggestion to move on with least effort at this point? Thanks.

1 0

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2017