Bug 4014

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.