Bug 306801

This not an lm_sensors issue, but rather an kernel issue. Changing component to
match. This might be caused by acpi code and the w83627hf driver both trying to
access the w83627hf at the same time, in which case the only solution is not
using the w83627hf driver. Have you tried disabling your lm_sensors startup
service, and not loading the w83627hf module later on in anyway?

Anyways this is best handled upstream, please try if disabling the w83627hf
driver helps and send a detailed report to lm-sensors, where all
lm-sensors development (including the kernel part) gets discussed.

OK, thats all good. I've disabled lm_sensors completely temporarily to see if
life improves, I'll keep a log of errors. Thanks.

Incidentally, how can i determine this for myself (if at all possible) so I dont
post these bugs incorrectly to the wrong package?

(In reply to comment #2)
> Incidentally, how can i determine this for myself (if at all possible) so I dont
> post these bugs incorrectly to the wrong package?

Choosing exactly the right component can be hard, so don't worry about it, you
were pretty close on, and provided a reasonable level of detail in the bug
report, which is really all we ask for.

I see no evidence that the w83627hf driver has anything to do with the crash.
The fact that the last open sysfs file at the time of the crash is
/devices/platform/w83627hf.656/temp2_input simply suggests that you have some
monitoring application (ksensors?) repeatedly polling temperature values, this
does not mean that the w83627hf driver is causing the crash.

Just try running without the w83627hf driver loaded and I guess that your system
will still freeze randomly. The backtraces in the logs suggest a network or
filesystem issue. Maybe a bug in NFS?

This bug should be reopened (for some reason I cannot do that myself.) There's
nothing that can be done "upstream" until we know for sure which "upstream" it is.

Reopening per comment #4.

Been running flawlessly for several hours, while using the NFS mount and amarok,
with ksensor removed and lm_ service stopped. I'll reload lm_ and not ksensor
and see how it get on?

(In reply to comment #6)
> Been running flawlessly for several hours, while using the NFS mount and amarok,
> with ksensor removed and lm_ service stopped. I'll reload lm_ and not ksensor
> and see how it get on?

Thats of little use, as hwmon (lm_sensors) drivers do little (nothing actually)
unless an application is using them.

Please keep testing without the w83627hf driver. It is possible that the bug
you're hitting triggers faster when sysfs is stressed, without the w83627hf
driver being directly responsible.

One way to test this would be to write a simple shell script repeatedly polling
arbitrary sysfs files. Something like:

--- 8< ---
#!/bin/sh

while [ 1 ]
do
        cat /sys/class/net/eth0/statistics/* > /dev/null
        sleep 2
done
--- 8< ---

Adjust the sleep value to match what you had in ksensors. Let this script run in
the background and see if the bug triggers again.

OK I've set the script up and its running the background - I'll continue to work
as normal with all other apps etc. I'll keep you updated...

Created attachment 209231 [details]
Latest log from /var/log/messages

Occurred about 1hr after terminating the above script, I was just about to save
a document and X crashed, hard-locking the system again. This is the log from
after the event.

Do you confirm that the w83627hf driver was not loaded when the last crash
happened? That would mean that the problem is definitely not related to
lm-sensors at all.

That is correct, no lm_sensors or ksensors in use and had also stopped polling
the sys files too. Recent failures have not listed the w83627hf driver. Its
failed twice this morning, I've switched back to the last known good kernel to
try to prevent data corruption.

OK, can either you or Hans change the summary line to no longer point at
lm-sensors then? Thanks.

Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

I was never able to cure this problem and eventually gave up and installed F8.
This appeared to cure the file damage problems but then I had a catastrophic RAM
failure, ive not had the problem since but have not used the system more than
twice either so dont feel qualified to say "its cured" or whether or not the RAM
was the original fault.

Sorry to hear it. As you're no longer able to troubleshoot this machine I'll
take the liberty of closing it INSUFFICIENT_DATA but thanks very much for taking
the time to file the original bug report - it is appreciated.

Cheers
Chris