Am Mittwoch, den 15.09.2010, 13:01 +0200 schrieb Carl-Daniel Hailfinger:
Peter, could you please attach /proc/ioports and check if dmesg mentions 0xc06 or 0xc6f or anything close to that?
Attached /proc/ioports and dmesg contents.
/proc/ioports: [...] 0c14-0c14 : pnp 00:02 0c49-0c49 : pnp 00:02 0c52-0c52 : pnp 00:02 0c6c-0c6c : pnp 00:02 [...]
Thanks for the data. Yay for crappy BIOS. The chipset I/O ranges touched by the chipset enable are completely unreserved and other devices may live there.
Quite unlikely. ISA-like devices are usually not allocated to addresses with (addr & 0x3ff) < 0x100, and PCI-like devices are only allocated to areas where (addr & 0xff) is completely unoccopied. This makes 0xCxx a very safe choice for chipset internal registers, as 0xCF8..0xCFF is already occupied by PCI config, and thus the 0xC00..0xFFF range is typically not allocated to PCI devices. And as stated above, ISAPnP-like stuff is usually not allocated to 10-bit-aliases of 0x00..0xff.
I know this is all a bit vague without any proof, but this is how resource allocation in PCs "works" since 30 years: Allocation by convention. I consider the GPIO/system control areas allocated to 0x1000 much more evil than these ports, as they might cause conficts in real-world systems. You might notice that the kernel detects these areas in the PCI quirks but IIRC it does nothing about the 0xCxx I/O ports. (didn't bother to look it up now, sorry)
Regards, Michael Karcher