On Sunday 09 December 2007 09:02:11 pm Mike Houston wrote: > On Mon, 10 Dec 2007 10:31:27 +0800 > Shaohua Li <shaohua.li@xxxxxxxxx> wrote: > > This should exist in previous kernel (before we remove acpi > > motherboard driver) too. Basically it's a broken BIOS. Could below > > patch work around it? > > > > Thanks, > > Shaohua > > > > Index: linux/drivers/pnp/system.c > > =================================================================== > > --- linux.orig/drivers/pnp/system.c 2007-12-10 > > 10:17:46.000000000 +0800 +++ linux/drivers/pnp/system.c > > Thanks Shaohua, I tested this as well and it appears to have worked > around the issue for me. > > Now, in dmesg, I get: > > system 00:01: ioport range 0x290-0x29f has been reserved > (...) > system 00:01: ioport range 0x290-0x294 could not be reserved > > In /proc/ioports I see: > > 0290-029f : pnp 00:01 > 0290-0297 : it87 > 0290-0297 : it87 > > The it87 sensor now works without disabling acpipnp This whole thing is too ugly for words. First of all, it87 only accesses two I/O ports: IT87_ADDR_REG_OFFSET and IT87_DATA_REG_OFFSET, which are at offsets 5 and 6 from the base. So if it87 reserved only those ports, e.g., 0x295-0x296, I think things would work fine (or at least, as well as they used to). Secondly, it87 ignores any information from the BIOS and grubs around for a superio chip at a magic address and tries to figure out what's behind it. I know this is because we don't know the "real" way to read those sensors, but it still sucks, and it still means we're likely to have conflicts with ACPI usage of the device. And no, I don't have anything useful like an ACPI driver to offer :-) Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
