It hangs with a _very_ long backtrace around the time it initializes drivers. At least I see some refs to e1000 functions (compiled in for netconsole). I can't capture anything, unfortunately - none of my 32bit boxes have a serial console. And despited that e1000 shows up in the backtrace, netconsole is not yet up and running when it crashes.
Obviously I've tried to build e1000 as a modules, suspecting it creates havoc. Didn't help.
Diffing my .config with the last non-working one the pointed me to the culprit.
The hang does not seem to be 100% reliable between kernel versions. Some kernels boot with CONFIG_NO_BOOTMEM=y. But the ones that don't boot do so reliably and can be "fixed" reliably with CONFIG_NO_BOOTMEM=n.
Diagnosed on my IBM Thinkpad X40, 1.2 GHz Pentium M, 1.5GB RAM. Also affected: HP Mini, 1.66 GHz Atom, 2GB RAM. Both machines run 32bit kernels. In other words 2 out of 2 of my 32bit x86 machines have this problem. I don't see any similarities than that between time, that could affect the outcome _this_ early in the boot process.
Marked as a regression because it's default y.
and boot log with CONFIG_NO_BOOTMEM not defined...
Created attachment 25533 [details]
dmesg from Thinkpad X40, 2.6.34-rc1 + some unrelated drm patches
Created attachment 25534 [details]
config from Thinkpad X40, 2.6.34-rc1 + some unrelated drm patches
Created attachment 25535 [details]
dmesg from the HP Mini, 2.6.34-rc1 + some unrelated drm patches
Created attachment 25537 [details]
config from the HP Mini, 2.6.34-rc1 + some unrelated drm patches
please check if this patch help...
please seperate them to two bugs...
(In reply to comment #4)
> Created an attachment (id=25535) [details]
> dmesg from the HP Mini, 2.6.34-rc1 + some unrelated drm patches
this one is not complete...
please increase the dmesg buffer.
two config (change to use CONFIG_NO_BOOTMEM) works on all my test setups.
maybe same as bug 15496
*** This bug has been marked as a duplicate of bug 15600 ***