Created attachment 22649 [details]
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.
Created attachment 22650 [details]
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...
Does the thing work with 2.6.30?
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.
have a look at :
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)
IMO, this is a duplicate of bug #13967
*** Bug 14132 has been marked as a duplicate of this bug. ***
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.
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?
Andrew, this is being discussed on the linux-acpi list at the moment:
Maybe my proposed message can be clarified further.
*** Bug 14161 has been marked as a duplicate of this bug. ***
*** Bug 14173 has been marked as a duplicate of this bug. ***
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.
Unfortunately, right now the answer is no, see:
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.
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.
There're some ATK0110 fan control stuff from asus_laptop:
*** Bug 14188 has been marked as a duplicate of this bug. ***
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:
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.
*** Bug 14192 has been marked as a duplicate of this bug. ***
(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.
>I add this to the GRUB, for my kernel:
>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
Obviously, it's a temporary hack until the non-laptop ATK* driver will be extended with supporting PWM* control.
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.
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.
(In reply to comment #23)
> Zenith88: We guys gave you a complete OS kernel for free. If you don't like
> 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.
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.