lkml.org 
[lkml]   [2003]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Any hope for ide-scsi (error handling)?
On Sat, 15 Mar 2003, bert hubert wrote:

> A construct like this was suggested for use in swsusp too to make sure that
> only *one* request is outstanding for a controler. This was also mentioned
> to be the unclean way and that there are taskfile interfaces which are
> cleaner.

hmm..

cpu0:

do_IRQ();
handle_IRQ_event();
...
static ide_startstop_t read_intr (ide_drive_t *drive)
{
msect = drive->mult_count; /* let msect = 0 */
...

if (i > 0) {
if (msect)
goto read_next;
if (HWGROUP(drive)->handler != NULL) <- [1]
BUG();
ide_set_handler(drive, &read_intr, WAIT_CMD, NULL); <- [2]
return ide_started;
}

}

cpu1:
swsusp code;
...
spin_lock_irqsave(&ide_lock, flags);
while (HWGROUP(drive)->handler) {
HWGROUP(drive)->handler = NULL; <- [1]
schedule_timeout(1);
}
<- [2]
...

Ok so at event [1] we have a ->handler set on cpu0 so we pass that check.
Then cpu1 acquires ide_lock and NULLs it out. cpu0 blocks on the lock in
ide_set_handler and when cpu1 releases it it re-assigns ->handler. What
happens then?

Zwane

-
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/

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