[LARGE SNIP]
> Would you agree to test the patch (possibly next week).
yeah sure.
> cheers
>
> -andrey
>
> > >
> > > If you can reliably reproduce the problem you could give it a try.
> > >
> > > Anybody sees yet another race condition here? :))
> > >
> > > -andrey
> > >
> > >
> > >>While burning a CD tonight I ended up taking an oops on my system. I
had
> > >>the lkcd patch applied to my 2.4.19 kernel, so I was able to look at
the
> > >> oops after my system rebooted. After digging into it a little and
> > >>looking at the ide-scsi code I think I found the problem but am not
> > >>sure. How can idescsi_reset simply return SCSI_RESET_SUCCESS to the
scsi
> > >>mid layer? I think what is happening is that a command times out,
> > >>idescsi_abort is called, which returns SCSI_ABORT_SNOOZE. Later on
> > >>idescsi_reset gets called, which returns SCSI_RESET_SUCCESS. At this
> > >>point the scsi mid-layer owns the scsi_cmnd and returns the failure
back
> > >>up the chain. Later on, the command gets run through
> > >>idescsi_end_request, which then tries to access the scsi_cmnd
structure
> > >>which is it no longer owns.
> > >>
> > >>Any help is appreciated. I have a complete lkcd dump of the failure if
> > >>anyone would like more information...
> > >>
-
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/
This archive was generated by hypermail 2b29 : Fri Jan 31 2003 - 22:00:11 EST