In order to circumvent bug #187671 (which is caused by a bad BIOS configuration of the MMIO regions for certain laptops) I added the kernel option "reserve=0xffb00000,0x100000" to my default kernel in /boot/grub/menu.lst, which has been reported to work on 32-bit systems (and which I have been able to verify using a 32-bit liveCD).
However, the kernel boot parameter does not work correctly on the 64-bit kernel. The option I specified is interpreted so that the following line appears at the end of /proc/iomem:
ffffffffffb00000-ffffffffffbfffff : reserved
which is clearly incorrect: it looks like the 32-bit address is being padded with ones instead of zeros. Specifying "reserve=0x00000000ffb00000,0x100000" (full-blown 64-bit address) does not change anything, the same line appears in /proc/iomem.
I'm running up-to-date Jaunty, kernel 2.6.28-11.42, x86_64.
In order to circumvent bug #187671 (which is caused by a bad BIOS configuration of the MMIO regions for certain laptops) I added the kernel option "reserve= 0xffb00000, 0x100000" to my default kernel in /boot/grub/ menu.lst, which has been reported to work on 32-bit systems (and which I have been able to verify using a 32-bit liveCD).
However, the kernel boot parameter does not work correctly on the 64-bit kernel. The option I specified is interpreted so that the following line appears at the end of /proc/iomem:
ffffffffffb0000 0-ffffffffffbff fff : reserved
which is clearly incorrect: it looks like the 32-bit address is being padded with ones instead of zeros. Specifying "reserve= 0x00000000ffb00 000,0x100000" (full-blown 64-bit address) does not change anything, the same line appears in /proc/iomem.