On Tue, 18 Sep 2007, Rene Herman wrote:
Second, schedule_timeout() returns immediately unless you have set the task state to TASK_UNINTERRUPTIBLE or TASK_INTERRUPTIBLE. I don't see anywhere where this is done, so the 250ms delay is in fact a busy loop. The call to schedule_timeout() appears to be quite pointless.
That mce_down code was changed over the last week by Krzysztof, myself and Takashi so not sure what version you've been looking at, but the (original)
I originally wrote that email in response to the email I replied to, and with respect to the code that was in it: http://article.gmane.org/gmane.linux.alsa.devel/48528
There were more patches before I actually sent the email, so I based my patch on what was in ALSA Hg at the time.
version that the quoted patch was against didn't use schedule_timeout, but a timeout based sleeping loop for cs4231 and schedule_timeout_interruptible() for ad1848 which sets the state itself.
You can see the version in Hg after your patch was applied, and it uses schedule_timeout() http://hg.alsa-project.org/alsa-kernel/file/f3f37d068eae/isa/ad1848/ad1848_l...
It wasn't until changeset 3675ae62becf, 7 days later (and after I wrote that email), that it was changed.
Here is a patch to fix all these problems and simplify the code in the process.
I looked at it, but am not sure what version it is against. It seems to
Current Hg.
msleep(3) still under lock. As you said, the minimal fix right now is to
I seem to have deleted the necessary unlock call before I sent the patch. One of the tests is inverted too. Here is a new version which fixes all that. The other problem you pointed at out in the current code about mistaken timeouts is fixed as well.