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