- 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@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot