Hans, I found an issue with the driver. It seems to have put something in the uguru part of BIOS, which makes my BIOS hang when I enter Abit uGuru temperature monitor screen in the BIOS. No keys work and only way for me at that point is to give it the three finger salute. The peculiar thing I noticed was that somehow it modified the shutdown and beep CPU temperatures to 245C and 235C while I had them set at 65C and 75C. As soon as the temp monitor displays 245C in CPU row, it just hangs. The next values to be displayed are the enable bit for these temps, I think. I never used the driver to write anything to BIOS, so how did it end up updating those values? Thanks, -Sunil On 7/31/06, Hans de Goede <j.w.r.degoede at hhs.nl> wrote: > > Sunil Kumar wrote: > > but how do you account for the HZ. > > I don't, the system you've been running on has a HZ of 1000 I assume? > That means that they delays we have found are them minimal ones needed > to mkae things work, sleeping longer with lower HZ is unfortunate but > not harmfull. Lower HZ has been taken into account in that we try not to > sleep much, because otherwise delays for the calling up would become > unacceptable. But besides that I do not take HZ into account. Remember > we are dealing with an error / exception path here. It doesn't have to > be beautifull or very efficient it just has to work and not suck. > > > I will give the 1:3 a run. > > > Thanks, In combination with a TIMEOUT of 100 I assume? > > Regards, > > Hans > > > > > With msleep(1), one system will sleep > > for 20ms while other will sleep only 2ms for the last try. We need to > > either 1. make it msleep(20), so all systems sleep for 20ms per read OR > > 2. have a conditional based on HZ to do msleep(1) for 100 and do > > multiple msleep(1) for HZ 1000 OR 3. have it as a configured parameter. > > 1st option means that 1000HZ folks will suffer delays which they could > > have avoided because they can sleep finer, but without option 2, they > > will just sleep for 2ms which may not be sufficient. 2nd and 3rd options > > work but 3rd works better because its simple and makes a lot of sense > > for the variety of hardware and BIOSes that you could be dealing with. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060805/b2c7951f/attachment.html
