Bug 15518 - CONFIG_NO_BOOTMEM=y breaks boot on 32bit
Summary: CONFIG_NO_BOOTMEM=y breaks boot on 32bit
Status: CLOSED DUPLICATE of bug 15600
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: i386 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: platform_i386
URL:
Keywords:
Depends on:
Blocks: 15310
  Show dependency tree
 
Reported: 2010-03-11 15:37 UTC by Daniel Vetter
Modified: 2010-04-08 20:17 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.34-rc1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg from Thinkpad X40, 2.6.34-rc1 + some unrelated drm patches (86.70 KB, text/plain)
2010-03-15 22:31 UTC, Daniel Vetter
Details
config from Thinkpad X40, 2.6.34-rc1 + some unrelated drm patches (63.54 KB, text/x-mpsub)
2010-03-15 22:32 UTC, Daniel Vetter
Details
dmesg from the HP Mini, 2.6.34-rc1 + some unrelated drm patches (122.71 KB, text/plain)
2010-03-15 22:37 UTC, Daniel Vetter
Details
config from the HP Mini, 2.6.34-rc1 + some unrelated drm patches (70.27 KB, text/x-mpsub)
2010-03-15 22:39 UTC, Daniel Vetter
Details

Description Daniel Vetter 2010-03-11 15:37:50 UTC
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.
Comment 1 Yinghai Lu 2010-03-15 22:26:58 UTC
.config?

and boot log with CONFIG_NO_BOOTMEM not defined...
Comment 2 Daniel Vetter 2010-03-15 22:31:42 UTC
Created attachment 25533 [details]
dmesg from Thinkpad X40, 2.6.34-rc1 + some unrelated drm patches
Comment 3 Daniel Vetter 2010-03-15 22:32:42 UTC
Created attachment 25534 [details]
config from Thinkpad X40, 2.6.34-rc1 + some unrelated drm patches
Comment 4 Daniel Vetter 2010-03-15 22:37:04 UTC
Created attachment 25535 [details]
dmesg from the HP Mini, 2.6.34-rc1 + some unrelated drm patches
Comment 5 Daniel Vetter 2010-03-15 22:39:25 UTC
Created attachment 25537 [details]
config from the HP Mini, 2.6.34-rc1 + some unrelated drm patches
Comment 6 Yinghai Lu 2010-03-15 23:09:31 UTC
please check if this patch help...

http://patchwork.kernel.org/patch/83832/
Comment 7 Yinghai Lu 2010-03-15 23:23:18 UTC
please seperate them to two bugs...
Comment 8 Yinghai Lu 2010-03-15 23:24:16 UTC
(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.
Comment 9 Yinghai Lu 2010-03-16 18:19:57 UTC
two config (change to use CONFIG_NO_BOOTMEM) works on all my test setups.
Comment 10 Thomas Meyer 2010-03-18 17:40:55 UTC
maybe same as bug 15496
https://bugzilla.kernel.org/show_bug.cgi?id=15496
Comment 11 Rafael J. Wysocki 2010-04-08 20:16:47 UTC

*** This bug has been marked as a duplicate of bug 15600 ***

Note You need to log in before you can comment on or make changes to this bug.