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=871271#post871271 >>> >>> Reported to bugzilla about lm_sensors but then moved as explained... >>> https://bugzilla.redhat.com/show_bug.cgi?id=306801 >>> >>> 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=871271#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
