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