# lm_sensors and acpi conflict for hardware monitoring

## musv

Hi there, 

Google finds a lot to this problem but still lacks of a solution. Ok, the story: 

I'm using an Athlon X2. My sensor chips are k8temp and w83627ehf. Until 2.6.30 everything worked fine. Since 2.6.31 I get this error:

```

modprobe w83627ehf

FATAL: Error inserting w83627ehf (/lib/modules/2.6.34-gentoo-r1/kernel/drivers/hwmon/w83627ehf.ko): Device or resource busy

```

And get this message in /var/log/messages:

 */var/log/messages wrote:*   

> 
> 
> Jun 17 20:05:20 faultier kernel: w83627ehf: Found W83627DHG chip at 0x290
> 
> Jun 17 20:05:20 faultier kernel: ACPI: resource w83627ehf [io  0x0295-0x0296] conflicts with ACPI region SEN1 [io  0x0295-0x0296 window disabled]
> ...

 

So far so good. The FAQ section of lm_sensors explains:

 *http://www.lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31 wrote:*   

> 
> 
> With previous kernels hwmon drivers used to drive IO ranges which were potentially used by the ACPI code in your BIOS (which is active not only during but also after boot), we now explicitly check for this and if the ACPI code claims the IO-ports used by the hwmon chip, we no longer allow the hwmon driver to load.
> 
> Banging IO-ports of a chip from 2 different drivers, the Linux hwmon driver and the ACPI code is a really bad idea and can cause all sort of issues (including things like changing CPU / RAM voltage or clock speed). So the old behaviour was a really bad idea.
> ...

 

Ok, I'm a good guy and don't want the old behaviour back. But what's the alternative? In every "nice" forum they explain how I can restore the old behaviour but doesn't seem to be a single explanation how to use a new driver. 

The kernel lists the two sections:

native drivers (what we shouldn't use anymore)

acpi drivers (with asus_atk0110 and SENSORS_LIS3LV02D)

I can load asus_atk0110 but nothing happens. So how can I get it working again? Motherboard is an A-N68SV(MCP68S) (Abit with nvidia chipset).

----------

## depontius

The real issue here is that sensors_detect needs to be enhanced to point us to the right drivers.  (I just checked, and on my Asus A8N it still finds IT87 instead of the ACPI driver - incidentally it's 3.1.2 - presumably new enough to know.)  Either that, or we need a translation table to tell us what the correct driver, given the "old" driver.

I just had my second motherboard hit this problem - 2 now running acpi/lax.  (The second one took this long because it's running hardened, and they only recently jumped from 2.6.29 to 2.6.32.)

----------

## musv

Means, the kernel developers "broke" the existing (bad) system in order to enforce the development of the existing lm_sensors project. Hmm, nice...

----------

## depontius

I'm not unhappy with what has happened.  I just wish the information to fix the problem were more generally available - and by generally I mean for more than Asus motherboards, or does this only affect Asus motherboards?  (One of my servers got hit by this, except it came from a flea market, so I have no real idea what brand it is.)

----------

## Tony0945

I know this is an old thread, but I would like to answer the last question.  It also affects Biostar. This is exactly what's happening to my Biostar 6100-m9 mobo.

kernel is :Linux gentoo 2.6.34-gentoo-r12 #1 SMP PREEMPT x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

lm_sensors is: lm_sensors-3.1.2

Both are the latest stable amd64 ebuilds.

Dmesg reports:

 *Quote:*   

> 
> 
> it87: Found IT8712F chip at 0x290, revision 7
> 
> it87: in3 is VCC (+5V)
> ...

 

Are there unstable versions that work better? That seems like an oxymoron. Also, how would I found out if an ACPI driver is available?

----------

## tomtom69

Hi,

 *musv wrote:*   

> 
> 
> I can load asus_atk0110 but nothing happens. So how can I get it working again? Motherboard is an A-N68SV(MCP68S) (Abit with nvidia chipset).

 

On a PC that uses it87 driver the boot option "acpi_enforce_resources=lax" helped to resolve the resource conflict.

Perhaps it's worth a try...

tomtom69

----------

## Tony0945

Well acpi_enforce_resources=lax works, but the notice "may damage your hardware" is disconcerting. Is this a "don't sue me if something goes wrong" disclaimer or is there a known chance of damage?  I suppose a new driver for these old mobos will not be built.

----------

## BitJam

I believe the damage is of a more theoretical nature (but please don't sue me!).

Someone found some conflicts with how some drivers talked with the hardware.  I believe the problem was that more than one driver was talking to the same device.  They thought this was very bad (and maybe they were right) so they made it so you couldn't use the existing "bad" drivers without that boot option.

The problem is that AFAIK, the preferred driver(s) for my mobo, ASUS M4A78 PLUS, does not give you access to the pcm fan inputs so I can't control my fans.  This is a big deal for me because 90% of the time the fans can be off or inaudible but when I'm doing emerges, then they need to be up full.

We've been using the "bad" drivers for years, most of that time without knowing they were "bad".  I haven't heard of anyone actually suffering hardware damage.  If someone did then I would think that would be well advertised by the people or person who made these changes to the kernel.

I'd be glad to migrate to drivers that are not "bad" but I'm not willing to give up fan control in order to do that.   I guess the person who made the changes felt the danger of hardware damage justified causing all this breakage instead of just issuing warnings.  IMO issuing warnings instead of breaking things may have actually resulted in getting the changes they wanted quicker because a lot of people would have been a lot less pissed off.  I still don't get why they wanted to force people to use drivers that don't yet exist.

I can assure you that losing fan control was a much greater threat to my hardware then the ACPI conflict they were worried about.

----------

## Tony0945

Thanks Bitjam.  In my case, it's the server in my basement so I always have the fan on full speed. It only takes a couple of watts and there's no one around to be bothered. But I want to monitor the speed so I can know when the fan is failing as it did recently. The only hint was the increasing frequency of crashes that went away after replacing the fan (it finally got so loud that you could hear it on the next floor). A little "whoosh" is OK even right next to me, but loud "coffee grinder" sounds are not.

----------

## BitJam

Remember, don't sue me!   :Smile: 

----------

## Tony0945

 :Very Happy:   Nah! I'm a programmer, not a lawyer!

----------

## cjubon

 *musv wrote:*   

> Ok, I'm a good guy and don't want the old behaviour back. But what's the alternative?

 

 *tomtom69 wrote:*   

> On a PC that uses it87 driver the boot option "acpi_enforce_resources=lax" helped to resolve the resource conflict. 
> 
> Perhaps it's worth a try... 

 

 *Tony0945 wrote:*   

> Well acpi_enforce_resources=lax works, but the notice "may damage your hardware" is disconcerting.

 

Easy solution:

Make sure you have CONFIG_SENSORS_ATK0110 set to y or m in your kernel's config.

Manually edit your /etc/conf.d/lm_sensors and replace each "it87" with "asus_atk0110", then restart lm_sensors.

Why this is not done by sensors-config, is something I don't understand, however.

----------

