[BUG] [hwmon] linux 2.6.31-rc6 regression

[BUG] [hwmon] linux 2.6.31-rc6 regression

[Zeev Tarantov]

Since upgrading from vanilla 2.6.31-rc5 to vanilla 2.6.31-rc6, my
onboard temp/fan/voltage sensors stopped working.
The motherboard is an asus p5k-e with a w83627ehf sensors chip.

In the new dmesg it says:

[    3.276720] w83627ehf: Found W83627DHG chip at 0x290
[    3.276894] ACPI: I/O resource w83627ehf [0x295-0x296] conflicts
with ACPI region HWRE [0x290-0x299]
[    3.277171] ACPI: Device needs an ACPI driver

I can provide more data, perform tests, whatever you need.

I am not setup for git bisect (I compile tarballs), but if no one can
figure it out I'll do that too, it is easy to reproduce.

I am not subscribed to the list, please cc: me. In any case I'll
follow this thread on archives.

I'm using the nvidia binary blob, but this happens before it is loaded
and so I will not even bother to reproduce without it.

-Zeev

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Markus Trippelsdorf]

On Sat, Aug 15, 2009 at 01:29:48PM +0300, Zeev Tarantov wrote:
> Since upgrading from vanilla 2.6.31-rc5 to vanilla 2.6.31-rc6, my
> onboard temp/fan/voltage sensors stopped working.
> The motherboard is an asus p5k-e with a w83627ehf sensors chip.
> 
> In the new dmesg it says:
> 
> [    3.276720] w83627ehf: Found W83627DHG chip at 0x290
> [    3.276894] ACPI: I/O resource w83627ehf [0x295-0x296] conflicts
> with ACPI region HWRE [0x290-0x299]
> [    3.277171] ACPI: Device needs an ACPI driver
> 
> I can provide more data, perform tests, whatever you need.
> 
Yeah, I have the same problem here, see:
http://bugzilla.kernel.org/show_bug.cgi?id=13967

-- 
Markus

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Matthew Garrett]

On Sat, Aug 15, 2009 at 01:29:48PM +0300, Zeev Tarantov wrote:

> [    3.276720] w83627ehf: Found W83627DHG chip at 0x290
> [    3.276894] ACPI: I/O resource w83627ehf [0x295-0x296] conflicts
> with ACPI region HWRE [0x290-0x299]
> [    3.277171] ACPI: Device needs an ACPI driver

The hwmon driver is attempting to allocate a region that's also used by 
your ACPI firmware. There's no way to synchronise access between the 
kernel and the firmware, so allowing both is potentially racy - we've 
seen numerous cases where the combination results in the system 
incorrectly generating critical temperatuer shutdowns, for instance, 
when some other indexed access gets interpreted as the temperature or 
when the hwmon chip's state machine is confused. The failure of hwmon to 
bind is a feature here, not a bug. You can override it with 
acpi_enforce_resources=no on the kernel command line.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Markus Trippelsdorf]

On Sun, Aug 16, 2009 at 02:03:03AM +0100, Matthew Garrett wrote:
> On Sat, Aug 15, 2009 at 01:29:48PM +0300, Zeev Tarantov wrote:
> 
> > [    3.276720] w83627ehf: Found W83627DHG chip at 0x290
> > [    3.276894] ACPI: I/O resource w83627ehf [0x295-0x296] conflicts
> > with ACPI region HWRE [0x290-0x299]
> > [    3.277171] ACPI: Device needs an ACPI driver
> 
> The hwmon driver is attempting to allocate a region that's also used by 
> your ACPI firmware. There's no way to synchronise access between the 
> kernel and the firmware, so allowing both is potentially racy - we've 
> seen numerous cases where the combination results in the system 
> incorrectly generating critical temperatuer shutdowns, for instance, 
> when some other indexed access gets interpreted as the temperature or 
> when the hwmon chip's state machine is confused. The failure of hwmon to 
> bind is a feature here, not a bug. You can override it with 
> acpi_enforce_resources=no on the kernel command line.

But we don't introduce »features« that break hardware monitoring on
numerous machines in rc6 normally, IIRC.
If this so important and critical to you, than just add a »hyperstrict«
parameter to acpi_enforce_resources or make »lax« the default.
-- 
Markus

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Matthew Garrett]

On Sun, Aug 16, 2009 at 07:37:35AM +0200, Markus Trippelsdorf wrote:
> On Sun, Aug 16, 2009 at 02:03:03AM +0100, Matthew Garrett wrote:
> > The hwmon driver is attempting to allocate a region that's also used by 
> > your ACPI firmware. There's no way to synchronise access between the 
> > kernel and the firmware, so allowing both is potentially racy - we've 
> > seen numerous cases where the combination results in the system 
> > incorrectly generating critical temperatuer shutdowns, for instance, 
> > when some other indexed access gets interpreted as the temperature or 
> > when the hwmon chip's state machine is confused. The failure of hwmon to 
> > bind is a feature here, not a bug. You can override it with 
> > acpi_enforce_resources=no on the kernel command line.
> 
> But we don't introduce »features« that break hardware monitoring on
> numerous machines in rc6 normally, IIRC.
> If this so important and critical to you, than just add a »hyperstrict«
> parameter to acpi_enforce_resources or make »lax« the default.

It's not - 2.6.29 had this behaviour, and it got broken in 2.6.30. This 
restores the status quo.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Stefan Richter]

Matthew Garrett wrote:
> On Sun, Aug 16, 2009 at 07:37:35AM +0200, Markus Trippelsdorf wrote:
>> On Sun, Aug 16, 2009 at 02:03:03AM +0100, Matthew Garrett wrote:
>>> The hwmon driver is attempting to allocate a region that's also used by 
>>> your ACPI firmware. There's no way to synchronise access between the 
>>> kernel and the firmware, so allowing both is potentially racy - we've 
>>> seen numerous cases where the combination results in the system 
>>> incorrectly generating critical temperatuer shutdowns, for instance, 
>>> when some other indexed access gets interpreted as the temperature or 
>>> when the hwmon chip's state machine is confused. The failure of hwmon to 
>>> bind is a feature here, not a bug. You can override it with 
>>> acpi_enforce_resources=no on the kernel command line.
>> But we don't introduce »features« that break hardware monitoring on
>> numerous machines in rc6 normally, IIRC.
>> If this so important and critical to you, than just add a »hyperstrict«
>> parameter to acpi_enforce_resources or make »lax« the default.
> 
> It's not - 2.6.29 had this behaviour, and it got broken in 2.6.30. This 
> restores the status quo.

Then why did my 2.6.29 did _not_ have this behavior?
(here: ASUS M3A78-EM, it87 driver)
-- 
Stefan Richter
-=====-==--= =--- =----
http://arcgraph.de/sr/

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Matthew Garrett]

On Sun, Aug 16, 2009 at 04:39:35PM +0200, Stefan Richter wrote:
> Matthew Garrett wrote:
>> On Sun, Aug 16, 2009 at 07:37:35AM +0200, Markus Trippelsdorf wrote:
>>> On Sun, Aug 16, 2009 at 02:03:03AM +0100, Matthew Garrett wrote:
>>>> The hwmon driver is attempting to allocate a region that's also 
>>>> used by your ACPI firmware. There's no way to synchronise access 
>>>> between the kernel and the firmware, so allowing both is 
>>>> potentially racy - we've seen numerous cases where the combination 
>>>> results in the system incorrectly generating critical temperatuer 
>>>> shutdowns, for instance, when some other indexed access gets 
>>>> interpreted as the temperature or when the hwmon chip's state 
>>>> machine is confused. The failure of hwmon to bind is a feature 
>>>> here, not a bug. You can override it with  
>>>> acpi_enforce_resources=no on the kernel command line.
>>> But we don't introduce »features« that break hardware monitoring on
>>> numerous machines in rc6 normally, IIRC.
>>> If this so important and critical to you, than just add a »hyperstrict«
>>> parameter to acpi_enforce_resources or make »lax« the default.
>>
>> It's not - 2.6.29 had this behaviour, and it got broken in 2.6.30. This 
>> restores the status quo.
>
> Then why did my 2.6.29 did _not_ have this behavior?
> (here: ASUS M3A78-EM, it87 driver)

Some other bug?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Alan Cox]

> > The hwmon driver is attempting to allocate a region that's also used by 
> > your ACPI firmware. There's no way to synchronise access between the 
> > kernel and the firmware, so allowing both is potentially racy - we've 
> > seen numerous cases where the combination results in the system 
> > incorrectly generating critical temperatuer shutdowns, for instance, 
> > when some other indexed access gets interpreted as the temperature or 
> > when the hwmon chip's state machine is confused. The failure of hwmon to 
> > bind is a feature here, not a bug. You can override it with 
> > acpi_enforce_resources=no on the kernel command line.
> 
> But we don't introduce »features« that break hardware monitoring on
> numerous machines in rc6 normally, IIRC.
> If this so important and critical to you, than just add a »hyperstrict«
> parameter to acpi_enforce_resources or make »lax« the default.

This is a bug fix not a feature - clashing hwmon and ACPI can seriously
screw up a system, cause it to do things like shutdown randomly and the
like.

Alan

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Calvin Walton]

On Sun, 2009-08-16 at 07:37 +0200, Markus Trippelsdorf wrote:
> On Sun, Aug 16, 2009 at 02:03:03AM +0100, Matthew Garrett wrote:
> > On Sat, Aug 15, 2009 at 01:29:48PM +0300, Zeev Tarantov wrote:
> > 
> > > [    3.276720] w83627ehf: Found W83627DHG chip at 0x290
> > > [    3.276894] ACPI: I/O resource w83627ehf [0x295-0x296] conflicts
> > > with ACPI region HWRE [0x290-0x299]
> > > [    3.277171] ACPI: Device needs an ACPI driver
> > 
> > The hwmon driver is attempting to allocate a region that's also used by 
> > your ACPI firmware. There's no way to synchronise access between the 
> > kernel and the firmware, so allowing both is potentially racy - we've 
> > seen numerous cases where the combination results in the system 
> > incorrectly generating critical temperatuer shutdowns, for instance, 
> > when some other indexed access gets interpreted as the temperature or 
> > when the hwmon chip's state machine is confused. The failure of hwmon to 
> > bind is a feature here, not a bug. You can override it with 
> > acpi_enforce_resources=no on the kernel command line.
> 
> But we don't introduce »features« that break hardware monitoring on
> numerous machines in rc6 normally, IIRC.
> If this so important and critical to you, than just add a »hyperstrict«
> parameter to acpi_enforce_resources or make »lax« the default.

Note that, as this is an ASUS board, there is actually an ACPI firmware
driver available that will let you do hardware monitoring in a way that
doesn't conflict with the firmware - give the "ASUS ATK0110 ACPI hwmon"
driver a try.

-- 
Calvin Walton <calvin.walton@gmail.com>

Re: [BUG] [hwmon] linux 2.6.31-rc6 regression

[Markus Trippelsdorf]

On Sun, Aug 16, 2009 at 10:28:13AM -0400, Calvin Walton wrote:
> On Sun, 2009-08-16 at 07:37 +0200, Markus Trippelsdorf wrote:
> > On Sun, Aug 16, 2009 at 02:03:03AM +0100, Matthew Garrett wrote:
> > > On Sat, Aug 15, 2009 at 01:29:48PM +0300, Zeev Tarantov wrote:
> > > 
> > > > [    3.276720] w83627ehf: Found W83627DHG chip at 0x290
> > > > [    3.276894] ACPI: I/O resource w83627ehf [0x295-0x296] conflicts
> > > > with ACPI region HWRE [0x290-0x299]
> > > > [    3.277171] ACPI: Device needs an ACPI driver
> > > 
> > > The hwmon driver is attempting to allocate a region that's also used by 
> > > your ACPI firmware. There's no way to synchronise access between the 
> > > kernel and the firmware, so allowing both is potentially racy - we've 
> > > seen numerous cases where the combination results in the system 
> > > incorrectly generating critical temperatuer shutdowns, for instance, 
> > > when some other indexed access gets interpreted as the temperature or 
> > > when the hwmon chip's state machine is confused. The failure of hwmon to 
> > > bind is a feature here, not a bug. You can override it with 
> > > acpi_enforce_resources=no on the kernel command line.
> > 
> > But we don't introduce »features« that break hardware monitoring on
> > numerous machines in rc6 normally, IIRC.
> > If this so important and critical to you, than just add a »hyperstrict«
> > parameter to acpi_enforce_resources or make »lax« the default.
> 
> Note that, as this is an ASUS board, there is actually an ACPI firmware
> driver available that will let you do hardware monitoring in a way that
> doesn't conflict with the firmware - give the "ASUS ATK0110 ACPI hwmon"
> driver a try.

Thanks for the hint. I had to patch lm_sensors, but now everything is
working fine. The output of sensors is also much nicer.

(http://lists.lm-sensors.org/pipermail/lm-sensors/2008-June/023606.html)

-- 
Markus