Bug 13939 - lm_sensors fails after 2.6.31-rc5
Summary: lm_sensors fails after 2.6.31-rc5
Status: CLOSED DOCUMENTED
Alias: None
Product: Drivers
Classification: Unclassified
Component: Hardware Monitoring (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jean Delvare
URL:
Keywords:
: 14132 14161 14173 14188 14192 (view as bug list)
Depends on:
Blocks: 56331
  Show dependency tree
 
Reported: 2009-08-09 18:48 UTC by Duncan
Modified: 2013-04-09 06:23 UTC (History)
11 users (show)

See Also:
Kernel Version: 2.6.31-rc5
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
.config (43.78 KB, text/plain)
2009-08-09 18:48 UTC, Duncan
Details
bisect.log (1.60 KB, text/plain)
2009-08-09 18:52 UTC, Duncan
Details

Description Duncan 2009-08-09 18:48:05 UTC
Created attachment 22649 [details]
.config

The bug this is related to is filed as ACPI, but I had no idea what components, etc to file this under there, and it's hardware monitoring related for me, so that's how I'm filing it.

With 2.6.31-rc5 and before, I get normal lm_sensors output, using the I2C AMD756/8111 drivers (I2C_AMD756 and I2C_AMD8111), the AMD Opteron temp sensor (SENSORS_K8TEMP), and the LM85/compatibles and Winbond W83627HF drivers (SENSORS_LM85 and SENSORS_W83627HF).

Shortly after rc5 (bisect says RIGHT after... umm... rc4... see below), the LM85/compatible and W83627HF sensors ceased functioning.  I only get the k8temp sensor reports still working.

The git bisect result is puzzling to me, but hopefully it makes sense to you guys.  Maybe it's because the one commit comment says it's a revert of another.  Anyway, I'll attach the bisect log and my .config.  

The mobo is a Tyan s2885.  I'm running the lm_sensors.conf file Tyan supplied, with one update to a sensor type after an lm_sensors update awhile back.  Gentoo/~amd64, gcc-4.4.1.  If you guys need more info on my hardware or software, check my other bugs for this cycle.  If you need dmesg or the like, holler.
Comment 1 Duncan 2009-08-09 18:52:00 UTC
Created attachment 22650 [details]
bisect.log
Comment 2 Duncan 2009-08-09 19:44:32 UTC
I don't know why bisect ended at a merge, but...

I can confirm that reverting commit 7cb7f45c7feef43c8f71f5cfedfc0b19be2142f77cb7f45c7feef43c8f71f5cfedfc0b19be2142f7 gives me back my sensors. =:^)

That commit is of course a reversion itself...
Comment 3 Rafael J. Wysocki 2009-08-09 20:18:52 UTC
Does the thing work with 2.6.30?
Comment 4 Duncan 2009-08-09 21:43:34 UTC
Yes, it has worked for ages... as Tyan had the sensors.conf file for it back in 2003 when I got the board and the specific Linux support including that file was one of the reasons I got that board... over the MSI with their much worse Linux support at the time.

It's just past 2.6.31-rc5, with that commit, that it quit working.
Comment 5 Florian Mickler 2009-08-27 18:56:28 UTC
have a look at :
bug #13967 

it seems, it is a feature, that lm_sensors isn't working anymore.
(the lm_sensors module fiddles with the hardware directly causing bad side-effects)
Comment 6 Zhang Rui 2009-08-31 06:53:30 UTC
right.
IMO, this is a duplicate of bug #13967
Comment 7 Jean Delvare 2009-09-06 14:46:18 UTC
*** Bug 14132 has been marked as a duplicate of this bug. ***
Comment 8 Jean Delvare 2009-09-06 14:52:21 UTC
Please see:
http://hansdegoede.livejournal.com/7932.html

If you are unhappy about the situation, blame it on the ACPI specification people, or the BIOS developers. The former have totally neglected to standardize on hardware monitoring for the last 10 years, the latter reserve I/O ports for ACPI and then in many cases don't use them, preventing native OS drivers from supporting hardware monitoring.

For now, just boot with acpi_enforce_resources=lax, and if your system breaks, you're on your own.
Comment 9 Andrew Morton 2009-09-09 06:16:10 UTC
This is a bit user-hostile.

Could we at least arrange for the kernel to emit a printk which will help the user find out what went wrong and what they can do about it?
Comment 10 Jean Delvare 2009-09-11 07:07:06 UTC
Andrew, this is being discussed on the linux-acpi list at the moment:

http://marc.info/?l=linux-acpi&m=125163998528138&w=2
http://marc.info/?l=linux-acpi&m=125241671017656&w=2

Maybe my proposed message can be clarified further.
Comment 11 Zhang Rui 2009-09-14 05:26:45 UTC
*** Bug 14161 has been marked as a duplicate of this bug. ***
Comment 12 Zhang Rui 2009-09-14 05:27:02 UTC
*** Bug 14173 has been marked as a duplicate of this bug. ***
Comment 13 IvankoB 2009-09-14 18:29:49 UTC
The newest lmsensors/libsensors knows the "atk0110" sensors but only provide read-only interface to its FAN speeds. But there's no "pwm* hooks for "fancontrol" in SYSFS ("pwmconfig" doesn't see any usable chip). 
Can the kernel matters be arranged in such manner that writting to PWM ports ( direct access to w83267 chip ?) be safely combined with reading speeds from "atk0110" ? 
The solution "to rely on BIOS's QFan feature fully" is far from ideal - it's unable to adopt/learn the BIOS to a specific fan. 
For instance - "Igloo 5610 PWM" is always kept rotating at 1750 if QFan Silent is activated, so at full CPU load (gaming, rendering,..) this speed is insufficient to cool the CPU properly.
Comment 14 Jean Delvare 2009-09-14 19:03:08 UTC
Unfortunately, right now the answer is no, see:
https://bugzilla.novell.com/show_bug.cgi?id=529018#c22
I hope it improves in the future somehow.

If Q-Fan is insufficiently configurable, I suggest you ask the motherboard vendor, Asus, to improve it.
Comment 15 IvankoB 2009-09-14 20:37:29 UTC
If Q-Fan is insufficiently configurable,
==========================================
BTW, it seems to be disablable ( safe mode as to accessing PWM controls ?) or switchable to the manual mode.
Comment 16 IvankoB 2009-09-14 20:41:13 UTC
There're some ATK0110 fan control stuff from asus_laptop:

http://www.mail-archive.com/acpi4asus-user@lists.sourceforge.net/msg00065.html
Comment 17 Zhang Rui 2009-09-18 02:17:37 UTC
*** Bug 14188 has been marked as a duplicate of this bug. ***
Comment 18 Stoner.Di 2009-09-19 05:21:53 UTC
Thaks!!!!!

For my PC:
motherboard: msi dka790gx platynum
procesor: amd phenom 9950
ram 2x2gb  Kingmax KLEE88F-B8KO600000

I add this to the GRUB, for my kernel:

add acpi_enforce_resources=lax

and kernel working fine. 
lm_sensors working fine too.

I wish this problem to solve because many ordinary users of linux will be difficult. Thanks to all who work actively to the stability and development of linux.
Comment 19 Zhang Rui 2009-09-21 01:26:37 UTC
*** Bug 14192 has been marked as a duplicate of this bug. ***
Comment 20 Jean Delvare 2009-09-21 07:41:17 UTC
(In reply to comment #9)
> This is a bit user-hostile.
> 
> Could we at least arrange for the kernel to emit a printk which will help the
> user find out what went wrong and what they can do about it?

We've added a news item on the front page on www.lm-sensors.org as well as an entry in the FAQ. This should help a bit.

I've also sent a patch to Len to improve the wording of the resource conflict message, but it's still pending.
Comment 21 IvankoB 2009-09-21 20:52:18 UTC
>I add this to the GRUB, for my kernel:
>add acpi_enforce_resources=lax
>
>and kernel working fine. 
>lm_sensors working fine too.
>
>I wish this problem to solve because many ordinary users of linux will be
>difficult. Thanks to all who work actively to the stability and development of
>linux.

Obviously, it's a temporary hack until the non-laptop ATK* driver will be extended with supporting PWM* control.
Comment 22 Zenith88 2009-11-25 15:43:33 UTC
You guys broke perfect good working functionality for the sake of 'common good'. Did you have any justification, like numerous cries for help from users, whose systems had problems from old sensor access method?

I would instead take a very conservative approach: if it ain't broken - don't fix it. You sacrificed those who need temp info, like many of us who overclock the CPUs. Is that sacrifice justified - I doubt that.

Researching bugzilla I found this: http://bugzilla.kernel.org/show_bug.cgi?id=10245

One single laptop user caused temp sensors to be broken for the whole world.
Comment 23 Jean Delvare 2009-11-25 15:48:34 UTC
Zenith88: We guys gave you a complete OS kernel for free. If you don't like it, don't use it. And please, stop making claims on a topic you obviously don't grasp at all.
Comment 24 Zenith88 2009-11-25 23:05:24 UTC
(In reply to comment #23)
> Zenith88: We guys gave you a complete OS kernel for free. If you don't like
> it,
> don't use it. And please, stop making claims on a topic you obviously don't
> grasp at all.

That was emotional, but did not address the core of the issue. You've left thousands of users w/o information of how hot their CPUs are running and you did it after one complained about his obscure laptop. By the way, why is XT MFM support still in the kernel? We are on SATA now. Com-pa-ti-bi-li-ty.
Comment 25 IvankoB 2009-11-26 04:37:12 UTC
Ok, but - the Linux team & the lm-sensors team, please explain for ASUS (ATK* sensor chips) 
mobo users what they should do to have fully operational:
1) CPU/mobo temperature sensors;
2) access to HDD SMART temperature;
3) FAN-control both of PWM & analog controlled coolers of mobo.

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