Kernel Bug Tracker – Bug 13253
x86_64 kernel misinterprets "reserve=" boot parameter
Last modified: 2009-08-29 18:58:19 UTC
I've reported this on Ubuntu Launchpad as bug 370003, but it seemed wise to report it here as well.
My laptop suffers from bug #9905 (#187671 in launchpad), which is in fact a BIOS defect: the ACPI tables suggest an arrangement where MMIO regions for different devices overlap and cause the machine to freeze on loading the sdhci[-pci] module, as well as the vanilla 8139too module (the latter was modified a while back in Ubuntu to use PIO instead, to partially address this problem).
Recently another user reported successfully bypassing the problem by adding "reserve=0xffb00000,0x100000" to the kernel command line. I can confirm this works on the x86 kernel, but not on the x86_64 kernel, which I'm currently running.
When adding the option to the x86_64 kernel, /proc/iomem shows this as the last line:
ffffffffffb00000-ffffffffffbfffff : reserved
which should have been, clearly, one of:
ffb00000-ffbfffff : reserved
00000000ffb00000-00000000ffbfffff : reserved
but for some reason the kernel prepends a bunch of ones instead of zeros to the 32-bit address to produce a 64-bit address. Specifying "reserve=0x00000000ffb00000,0x100000" on the command line does not help, though.
Let me know if I've misclassified the bug, my guess is ACPI, but I may be very wrong here...
please attach the full dmesg ouput after boot.
Created attachment 21457 [details]
dmesg with reserve parameter set on x86_64
Attached. I can also produce dmesgs without using "reserve", and for the 32-bit kernel using an Ubuntu liveCD, if any of these help.
Created attachment 21703 [details]
patch: io_start use unsigned int intead of int
please re-open this bug if the patch doesn't work for you.
patch is also sent to the ACPI mail list.
Works beautifully, thanks.
kernel/resource.c: fix sign extension in reserve_setup()
shipped in linux-2.6.31-rc2