> - 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-1_83-GHz-667-MHz-FSB ... Am I correct?

[2] What is GEODE in this context? 500 Mhz i486AMD 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