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.