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.
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)