Bug 4014 - w83627hf and w83781d don't create entries in sysfs
w83627hf and w83781d don't create entries in sysfs
Product: Drivers
Classification: Unclassified
Component: Hardware Monitoring
i386 Linux
: P2 normal
Assigned To: Jean Delvare
: 4224 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2005-01-09 17:09 UTC by Cengiz ALKAN
Modified: 2005-11-15 10:10 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.10
Tree: Mainline
Regression: ---

acpidmp output (64.03 KB, text/plain)
2005-01-17 00:14 UTC, Cengiz ALKAN
dmesg output (11.10 KB, text/plain)
2005-01-17 00:14 UTC, Cengiz ALKAN
/proc/ioports (1.00 KB, text/plain)
2005-01-17 00:15 UTC, Cengiz ALKAN
cat /var/log/kernel/current prior to recompiling to remove PNPACPI (93.25 KB, text/plain)
2005-04-08 13:34 UTC, Jeff Norman

Description Cengiz ALKAN 2005-01-09 17:09:27 UTC
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
Comment 1 Jean Delvare 2005-01-11 03:32:10 UTC
You problem reminds me of this report:

Do you have "Plug and Play ACPI support" enabled?

If you do, does disabling it solve the problem?
Comment 2 Cengiz ALKAN 2005-01-11 17:24:48 UTC
Right on. There was IO conflict. 0x265-0x296 was reserved by PnP. Disabling ACPI
PnP did the trick. 
Comment 3 Jean Delvare 2005-01-12 02:12:32 UTC
OK. Now we know where the conflict lies, but it doesn't mean that the problem is

Moving bug to the ACPI category.
Comment 4 Cengiz ALKAN 2005-01-12 03:42:29 UTC
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

I will gladly provide any output, log or diagnostic messages if needed. 
Comment 5 Jean Delvare 2005-01-15 07:01:41 UTC
A similar problem report can be seen on the sensors mailing-list archive here:
Comment 6 Shaohua 2005-01-16 19:05:10 UTC
Could you please attach the acpidmp, dmesg and /proc/ioports info? I'd like to 
check it.
Comment 7 Cengiz ALKAN 2005-01-17 00:14:06 UTC
Created attachment 4422 [details]
acpidmp output
Comment 8 Cengiz ALKAN 2005-01-17 00:14:54 UTC
Created attachment 4423 [details]
dmesg output
Comment 9 Cengiz ALKAN 2005-01-17 00:15:27 UTC
Created attachment 4424 [details]
Comment 10 Cengiz ALKAN 2005-01-17 00:16:55 UTC
acpidmp, dmesg and /proc/ioports attached with ACPI Plug And Play enabled.
Comment 11 Shaohua 2005-01-17 00:45:48 UTC
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.
Comment 12 Jean Delvare 2005-01-17 04:02:17 UTC
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?
Comment 13 Shaohua 2005-01-17 16:54:27 UTC
>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.
Comment 14 Shaohua 2005-01-20 01:03:19 UTC
Could the driver just reserve '0x295-0x296' or do this when reserving '0x290-
0x297' failed, considering it just uses '0x295-0x296'?
Comment 15 Jean Delvare 2005-01-20 01:09:52 UTC
It possibly could, but how would it help? The 0x295-0x296 range is precisely
what PNPACPI reserved, unsurprisingly.
Comment 16 Shaohua 2005-01-20 01:12:21 UTC
PNPACPI mark the resource as unbusy, so a driver actually can reserve it if 
the resource len <= PNPACPI reserved.
Comment 17 Jean Delvare 2005-01-20 01:28:42 UTC
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.
Comment 18 Shaohua 2005-01-20 01:33:33 UTC
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.
Comment 19 Jean Delvare 2005-01-20 04:19:18 UTC
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.
Comment 20 Shaohua 2005-01-21 00:41:42 UTC
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.
Comment 21 Jean Delvare 2005-01-21 01:48:11 UTC
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

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.
Comment 22 Greg Kroah-Hartman 2005-03-08 09:26:39 UTC
*** Bug 4224 has been marked as a duplicate of this bug. ***
Comment 23 Jeff Norman 2005-04-08 13:34:24 UTC
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?
Comment 24 Salah Coronya 2005-06-30 14:49:31 UTC
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.
Comment 25 Petr Vandrovec 2005-09-07 12:48:19 UTC
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.
Comment 26 Jean Delvare 2005-10-04 00:47:21 UTC
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.
Comment 27 Jean Delvare 2005-10-17 03:30:18 UTC
2.6.14-rc4-mm1 has Petr's fix and should work.
Comment 28 Jean Delvare 2005-11-15 10:10:21 UTC
The fix is in 2.6.15-rc1, I'm closing this bug.

Note You need to log in before you can comment on or make changes to this bug.