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 that. anyway, I will give the attached a run and let you know. Thanks, Sunil 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
