sent too soon. I wanted to mention that the frequency of messages has reduced by manyfolds after this patch. On 7/20/06, Sunil Kumar <devsku at gmail.com> wrote: > > hold on to this patch please, because I just saw two messages appear again > after two hours of uptime after resume. This hasn't happened in my previous > tests where machine was up even longer. I think there is more to it than > just sleeping a few milliseconds. It may very well be an issue with my > particular board. > > > On 7/20/06, Sunil Kumar <devsku at gmail.com> wrote: > > > > 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/29abaf1b/attachment.html
