Re: [lm-sensors] possible ACPI vs w83627hf conflict,

[James <j.buckle@btinternet.com>]

Jean Delvare wrote:
> On Wed, 26 Sep 2007 15:13:50 +0200, Hans de Goede wrote:
>   
>> James wrote:
>>     
>>> I'm having problems with what seems to be lm_sensors and the kernel 
>>> having an argument in fedora! Instead of re-writing the content of my 
>>> posts to fedora forum and bugzilla I will post the links here if that is 
>>> ok? If anyone could help me resolve this issue I'd appreciate it! 
>>> lm_sensors isnt vital for my system but it is handy!
>>>
>>> System:
>>> Fedora 7, (Linux JamesFedora 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:47:21 
>>> EDT 2007 i686 athlon i386 GNU/Linux)
>>>       
>
> Is there no newer kernel available? Upstream stable kernel is at
> 2.6.22.9 by now.
>   
Not that I'm aware of, I run the nightly update, but while im using the 
system to write an important documentation I havent been using test 
kernels etc.
>>> Original questions on:
>>> http://www.fedoraforum.org/forum/showthread.php?p‡1271#post871271
>>>
>>> Reported to bugzilla about lm_sensors but then moved as explained...
>>> https://bugzilla.redhat.com/show_bug.cgi?id06801
>>>
>>> Can I provide any more information to help the problem?
>>> I've temporarily disabled lm_sensors to try to prevent filesystem damage 
>>> while im work on an important document, in a week or so I can continue 
>>> testing it.
>>>       
>> Indeed there is no need to type your Fedora report again, but next time please 
>> copy and paste it for reader convenience (I've done that for you now):
>>
>> ---
>>
>> Description of problem:
>> System freezes completely. Scanning logs only turns up kernel null-pointer bugs
>> that appear to be linked in to the sensors files....see my post
>> http://www.fedoraforum.org/forum/showthread.php?p‡1271#post871271
>>
>> Version-Release number of selected component (if applicable):
>> lm_sensors-2.10.4-1.fc7
>>
>> How reproducible:
>> Random, but a couple of times per day. Causes file system damage when the system
>> has locked up and needs a hard reset.
>>
>> Steps to Reproduce:
>> 1.Impossible to tell, however usually doing something fairly intensive when it
>> occurs, but never in the same package. Always listening to music over and NFS
>> shared mount at the time.
>> 2.
>> 3.
>>
>> Actual results:
>> -
>>
>> Expected results:
>> -
>>
>> Additional info:
>> I'm not sure if this is an lm_sensors fault, but it seems that the last sys file
>> used every time is the hardware monitor file:
>> /devices/platform/w83627hf.656/....
>>     
>
> This can be explained easily if you have an application repeatedly
> polling the temperature values: the last read file will always be the
> same, but that doesn't mean that it has anything to do with the crash.
> ksensors is such an application.
>
> As I stated in bugzilla already, the backtraces in your forum post do
> not point at a hwmon driver problem, nor to ACPI. The few hwmon vs. ACPI
> issues we've seen lately had completely different symptoms. The
> backtraces seem to point to networking and/or filesystem issues. So for
> now I need to be convinced (with additional testing) that the w83627hf
> driver has anything to do with the crashes.
>
> I would be grateful if users could stop blaming hwmon and ACPI for
> being the cause of all bugs that happen in the kernel ;)
>
>   

I understand the problem more now, though as a mere mortal "user" im not 
really qualified to determine the differences lol Really this is a 
problem with open source software using lots of packages up and 
downstream - the error could lie anywhere and the user has bugger all 
chance of working out where the problem lies without input from the Gods :)

As per bugzilla instruction I've been running the script to poll the 
eth0 stats continuously, and disabled the lm_sensors process. I've been 
running it at ~3x the frequency of the ksensors update rate I had to try 
to "force" an early error, but its been rock solid so far all day - 
listening to my mp3s over the NFS all day, web browsing, 
emailing/skyping etc. I'll report back if the situation changes.

James

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors