[1] Platform T2400/i945 -> http://ark.intel.com/products/27235/Intel-Core-Duo-Processor-T2400-2M-Cache-... ... Am I correct?
Yup.
[2] What is GEODE in this context? 500 Mhz i486AMD Geode processor (Single HW threaded, one core, no HT)?
Just a remark about how I got warning that late - I went through usual test routines on a non-SMP kernel because my basic test image does use it by default, primarily it is designated to a DB800 dev board.
[3] And what are the Linux distro and the distro kernel you are using (version and size ? 32 : 64, please)?
This is 32-bit CPU, so answer is obvious :) I think that I`m hitting the problem independent of the kernel version I am running, but I`ve tried few stable versions from 3.2 to 4.9 without spotting any noticeable difference. Windows hangs as well as soon as it finishes driver loading procedure, this is visible from safe mode.
[4] Am I reading that you are not able to produce dmesg? If YES, please, post failing dmesg here!
Nope, this is not the case. May be initial text is not clear enough, but I`m getting a 'dead' hang of the board itself - I mentioned that SMI handler is not chewing anything after this point, all the peripherals seem to be pretty dead as well, at least I was unable to see anything past the failure via usb debug and serial console.
[5] I assume that you have SeaBIOS as payload, don't you? [6] Are you booting via GRUB?
Yes, I am using SeaBIOS and GRUB for local boots. I could share a successful non-SMP dmesg as well as part of SMP dmesg before hang, but there are virtually zero points to take on. May be the only difference between dmesg contents over stock one aside complaining about missing hard-coded battery slot is the snip below, just because I didn`t fixed this yet (specific to native gfxinit, but board also happily hangs with stock vbios and smp kernel, just for the case)
[drm] failed to find VBIOS tables vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [drm] initialized overlay support [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
- 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 honestly don`t think that this is the case - for non-SMP boot, the Xorg log absolutely resembles everything that I`m getting with vendor bios and for SMP boot system hangs a bit earlier. Video memory garbling is not a persistent but rather floating effect, forgot to mention that.
I have also other ideas how to debug this all, but lets go with these for starters, shall we??? ;-)
I thought about hidden interrupt storm which could possibly manifest itself in that way, but I`ve never seen IS being *that* bad. Honestly I`m out of ideas why turning on SMP results in a horrible memory corruption/overlap, SMP-ed Memtest was able to pass few rounds without any warning. Even if all platform and peripheral drivers blacklisted, the problem still shows up, so it does not limit itself, at least obviously, to one single device whose DMA region(s) splats over areas where it shouldn`t be.
-
Andrey Korolyov