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. http://patchwork.kernel.org/patch/27403/
Works beautifully, thanks.
8bc1ad7dd301b7ca7454013519fa92e8c53655ff kernel/resource.c: fix sign extension in reserve_setup() shipped in linux-2.6.31-rc2 closed.