Distribution: Gentoo Hardware Environment: Pentium 4, Asus WMT-LX Software Environment: kernel 2.6.10 Problem Description: i2c chip module w83627hf and w83781d don't create entries under /sys/bus/i2c/devices/. None of the hardware sensors information, including the root directory (/sys/bus/i2c/devices/*-0290) doesn't show up. The same configiration works with kernel 2.6.9 and before. I have enabled "Device Drivers > I2C Support > I2C Chip debugging messages", but there is no related entry in the kernel messages (or I don't know where to look for those debugging messages) The output of "lsmod | grep i2c": i2c_sensor 3200 1 w83627hf i2c_dev 7808 0 i2c_isa 1920 0 i2c_core 18960 4 w83627hf,i2c_sensor,i2c_dev,i2c_isa Steps to reproduce: modprobe i2c-isa w83627hf i2c-dev
You problem reminds me of this report: http://lkml.org/lkml/2005/1/7/351 Do you have "Plug and Play ACPI support" enabled? If you do, does disabling it solve the problem?
Right on. There was IO conflict. 0x265-0x296 was reserved by PnP. Disabling ACPI PnP did the trick. Thanks,
OK. Now we know where the conflict lies, but it doesn't mean that the problem is solved. Moving bug to the ACPI category.
Sorry, I know it doesn't mean it is solved. But I am using this bugzilla the first time, I wasn't sure what to do. When it comes to ACPI, my MB is buggy (It is a Sony Vaio desktop with a modified Asus MB), nothing works except Power Button. I assumed the MB's ACPI implementation was to blame for the IO conflict. I even get ACPI errors during boot. I will gladly provide any output, log or diagnostic messages if needed.
A similar problem report can be seen on the sensors mailing-list archive here: http://archives.andrew.net.au/lm-sensors/msg29030.html
Could you please attach the acpidmp, dmesg and /proc/ioports info? I'd like to check it.
Created attachment 4422 [details] acpidmp output
Created attachment 4423 [details] dmesg output
Created attachment 4424 [details] /proc/ioports
acpidmp, dmesg and /proc/ioports attached with ACPI Plug And Play enabled.
Thanks for the information, so if you disable PNPACPI, the IO ports of the i2c device will be from 295 - 29D, right? Looks like the BIOS reports wrong io ports. I guess change the DSDT a little (just change it to 295 - 29D, or just remove the io ports) will solve the problem. But it isn't a fix. Will try to get a fix if possible.
I wish to add a clarification about the I/O range. The full device I/O range is 0x290-0x297 (this is what the w837627hf driver will attempt to reserve). However, only the 0x295-0x296 range is useful, the other I/O ports are left unused. So the I/O range detected by PNPACPI makes sense. To me the problem is that PNPACPI shouldn't reserve this range since (I guess) it doesn't make anything useful with it while another driver would. But maybe I'm just not understanding what PNPACPI is there for. Why is it reserving all these ranges at all?
>0x290-0x297 (this is what the w837627hf driver will attempt to reserve). >However, only the 0x295-0x296 range is useful, the other I/O ports are left Yep, this makes sense too. PNPACPI reserved is so-called motherboard resources. The resources generally can't be gotten from PCI config space. Without it, hotplug (such as PCMCIA) possibly get resource conflict.
Could the driver just reserve '0x295-0x296' or do this when reserving '0x290- 0x297' failed, considering it just uses '0x295-0x296'?
It possibly could, but how would it help? The 0x295-0x296 range is precisely what PNPACPI reserved, unsurprisingly.
PNPACPI mark the resource as unbusy, so a driver actually can reserve it if the resource len <= PNPACPI reserved.
I see. Wouldn't it make more sense to extend the checking mechanism to allow requests that contain (as opposed to exactly match) a non-busy range? It would be more efficient than modifying all drivers that might be affected. There is no reason why only the w83781d and w83627hf drivers would be affected. I can also imagine that different BIOSes might define different ranges in PNPACPI for a given device. We certainly don't want to try all combinations until we succeed.
Yep, I also have the same thoughts. I actually propose to introduce a new resource flag for such specal case. Changing the resource management is a better fix. My concern is if this will break normal resource protect.
I don't know exactly how resource reservation works so I might be wrong, but it doesn't seem to be a completely new case to me. If it was already possible to request an already requested range providing that the first requester tagged it as "non-busy" (frankly I didn't know it was possible), it is just a matter of extending that possibility to ranges that includes such non-busy ranges instead of just allowing the exact same range to be re-requested. If we can do that then we don't have to introduce a new flag.
The problem is the non-busy resource is smaller than that you requested, so it failed. You possibly want the requested resource to be the parent of the non- busy resource, but this is very odd. After taking a close look at the resouce mangament code, I think new flag can't help also. So far, I think the I2C driver only requests what it really needed is better solution.
Requesting the sub-range might work for the w83627hf driver (the other I/O addresses are actually not used) but there are other drivers (lm78, it87, w83781d) which do use the rest of the range for detection purposes. If we end up only requesting the sub-range, we won't be able to do these tests and we will weaken the detection process. Also, I doubt that only these four hardware monitoring drivers will have the problem. Depending on the specific ACPI implementation, I guess that almost any "motherboard component" could be pre-requested by PNPACPI with slightly different ranges from what the corresponding driver expects, and cause similar trouble. Finally, not requesting the full device range makes it possible for others to request the remaining parts for a different use in good faith, which is likely to cause trouble. I admit that in this particular case, the remaining ranges are very short - 5 and 1 bytes, respecively - so it is unlikely anyone will want them, but in the general case it might be a concern. I really believe that the range request mechanism needs to be extended to handle this new case raised by PNPACPI. I don't know how it works internally so I can hardly do any technical proposal, but modifying device drivers to workaround a subsystem problem doesn't sound quite right to me.
*** Bug 4224 has been marked as a duplicate of this bug. ***
Created attachment 4882 [details] cat /var/log/kernel/current prior to recompiling to remove PNPACPI Same problem here. Thanks to Jean Delvare's help, I was able to recompile kernel with PNPACPI off, and fixed the issue. My system board is iWill Zmaxdp, which uses the w83267hf chip and is an Nforce3 250 Pro system chipset. Bios is latest and greatest v 1.11 (AMI BIOS). I am using kernel 2.6.11-gentoo-r6 (also occurred under -r5, have not checked other kernel versions). Prior to recompiling the kernel with PNPACPI disabled, I had the following in /proc/ioports, where the w83627hf should have appeared: 0295-0296 : pnp 00:09 I have attached kernel messages (before recompiling to remove PNPACPI). Could not find acpidmp utility - do you happen to know what gentoo package it is in?
I'm adding a "me too" to this one, I was pointed to this bug after posting this problem on the lm_sensors mailing list. I have a Sony Vaio PCV-RX550 with an ASUS P4B-LX motherboard, but when PNPACPI is enabled, I cannot accesss the W83781D/W83627HF. The w83781d driver complains (with i2c chip debugging) "Request of region 0x290-0x297 for w83781d failed", and /proc/ioports shows "pnp 00:0d" at port 0x0295-0x0296. This machine is dual-booted with Windows XP, which has no problem with the fan control. The DSDT compiles file with the Intel compiler, only giving 1 warning about _WAK. I can provide any logs/dumps needed, for now, I've disabled PNPACPI and switched to PNPBIOS in the meantime.
Explanation in #21 is bogus. BIOS is correct, and chips responds to the xx5 & xx6 addresses only, so Linux driver requesting xx0 - xx7 is incorrect, mixing requested region alignement with its size and base. I see no problem with it87/lm78/w83781d drivers - if they want to request full 8 byte range, let's do that. Though I think that it87/lm87/w83781d drivers just suffer from same problem like w83627hf driver - all three drivers are poking at ports base + 1, base + 2, base + 3, base + 7 - which all do not exist, and so on most of motherboards they'll all yield 0xFF, and so this "detection" passes. But this says nothing about what chip is at base + 5 & base + 6, only address to which it87/lm78/w83781d/w836x7 chips respond. They only tell you that I/O ports around this hardware monitor chip are unused. But it is completely legal to put legacy LPT port at 0x378-0x37A while hardware monitor at 0x37D-0x37E, and for this configuration "test" in it87/lm87/w83781d fails, and all four drivers in their current state fail to load as they incorrectly request range parallel port driver already reserved for itself.
Petr finally convinced me he was right about the W836x7HF family of chips, requesting only 0x295-0x296 instead of 0x290-0x297 is correct and should be safe unless other drivers themselves are broken. I've accepted a patch which changes the I/O range requested by the w83627hf and w83627ehf drivers. It should hit -mm within a release or two, and 2.6.15 should include it. David, can you reassign this bug to me? It was actually a hardware monitoring driver issue, even if it wasn't totally obvious to me at first. As for the other chips and drivers: * it87: The IT8705F/IT8712F chips do decode the whole address range, so requesting 0x290-0x297 is correct and won't be changed. * lm78: Only 0x295-0x296 seems to be decoded by the LM78/LM79. However, the non-decoding of the other ports is used for pre-detection purposes, because this is about the only way we have to be reasonably sure that we have a hardware monitoring chip (or nothing at all) at this location and writing to 0x295 will not break anything. Using the non-decoded ports for a different device would break detection, so there's little point in changing the driver to support it. * w83781d: Not tested, but the requirements are the same as for lm78 WRT pre-detection, so let's not change it.
2.6.14-rc4-mm1 has Petr's fix and should work.
The fix is in 2.6.15-rc1, I'm closing this bug.