Messages in this thread | | | Date | Sat, 8 Oct 2005 10:29:22 +0200 | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: IDE issues with "choose_drive" |
| |
On 10/8/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > On Thu, 2005-10-06 at 11:02 +1000, Benjamin Herrenschmidt wrote: > > > The first one is the one I'm trying to fix, it's basically a hang on > > > wakeup from sleep. What happens is that both drives are blocked > > > (suspended, drive->blocked is set). Their IO queues contains some > > > requests that haven't been serviced yet. We receive the resume() > > > callback for one of them. We react by inserting a wakeup request at the > > > head of the queue and waiting for it to complete. However, when we reach > > > ide_do_request(), choose_drive() may return the other drive (the one > > > that is still sleeping). In this case, we hit the test for blocked queue > > > and just break out of the loop. We end up never servicing the other > > > drive queue which is the one we are trying to wakeup, thus we hang. > > > > Oh, and here's the ugly workaround beeing tested by the users who are > > having the problem so far. Not really a proper fix though... > > No reply ... it's a bit urgent as it may bite any system trying to > suspend with a slave IDE disk at least (not including the other possible > problems I've spotted with this code).
It is a old problem from what I understand. However it would still be nice to have it fixed for 2.6.14.
> I'm tempted to just send my workaround patch to Linus & Andrew (might > still make it into 2.6.14). That would at least fix the bug with resume > from sleep. What do you think ?
It seems we need internal ide_dev_do_request(ide_drive_t *, int) which will explicitly state which device we want to service as I see no sane way to fix the problem in choose_drive().
Your workaround is OK for 2.6.14 given that you will document it now and later fix it properly for 2.6.15.
Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |