[lkml]   [2003]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Any hope for ide-scsi (error handling)?
On 2003.03.15 15:23 Zwane Mwaikambo wrote:
> On Sat, 15 Mar 2003, dan carpenter wrote:
> > > Apart from the schedule with the ide_lock held, what is that code actually
> > > doing?
> > >
> > > Zwane
> >
> > Hm... Good question. I have no idea what the while loop is for.
> I suppose the magik is in the comments;
> /* first null the handler for the drive and let any process
> * doing IO (on another CPU) run to (partial) completion
> * the lock prevents processing new requests */
Indeed. If you get there, the command in progress is hung.
To be able to restart the device, the old command needs to be
aborted. But that is an inherently racy undertaking.

Nominally, I just want to set HWGROUP(drive)->handler = NULL.
But there is a small chance, that there is actually (interrupt)
activity going on for the command, which would result in a new
entry in HWGROUP(drive)->handler popping up after it is cleared.

The loop as programmed significantly increases the odds that
the old command is really aborted.

It may not be elegant to schedule(1) with the lock taken, but it
does work.

However, my latest patch doesn't seem to be applied, since in my
version I have a set_current_state(TASK_INTERRUPTIBLE); before
the schedule.

Regards, Willem Riede.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.054 / U:2.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site