[lm-sensors] new abituguru driver in mm kernel

Sunil Kumar devsku at gmail.com
Thu Jul 20 16:37:11 CEST 2006

I had been getting the problem on a clean boot as well as after a
suspend/resume cycle. I have now tested it with both reboots and
suspend/resume cycles multiple times and it seems to work. I agree that the
worst case delay of 38*50~=2000 msec is big but I don't think we will hit

anyway, I will give the attached a run and let you know.


On 7/20/06, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> Sunil Kumar wrote:
> > Ok, this patch seems to have made the messages go away for good (even
> with
> > suspend/resume cycle). Because this patch helps fix it, I suspect that
> > its a
> > race between setting the ready state and doing a read because the while
> > loop
> > executes really fast and the hardware is not really that fast to respond
> > when you expect it in ABIT_UGURU_STATUS_READ state in the abituguru_read
> > call.
> >
> Hi,
> 1) Thanks for all the testing and the patch
> 2) The while loop speed is not as fast as you think, since the while
>    test condition contains a inb_p which will do 2 isa reads, thus the
>    while loops speed is ISA bus bound, not CPU bound.
> 3) Normally I would object against the sleeping in the while since in
>    the normal (no suspend problem) case, the loops are intented to
>    execute pretty fast. In abituguru_update_device 38 read operations
>    are done, if every read op is going to take milliseconds this will
>    cause noticable stalls in sensors using applications.
> 4) However the 2 places where you've inserted the sleep are places where
>    normally the code succeeds on the first read (so it never enters the
>    while and thus never sleeps) the whole reason for the while was to
>    try to fix the problem you're experiencing and you've fixed the fix,
>    thanks!
> So the fix is most definitly going in, thanks! Could you try the
> attached version? I've also modified the suspend / resume code so that
> it no longer unconditionally marks the uguru not_ready as that seemed to
> make things worse, instead it now checks the uguru status and sets the
> ready flag depending on the status.
> Thanks,
> Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060720/c3923013/attachment.html>

More information about the lm-sensors mailing list