Messages in this thread | | | Date | Fri, 24 Jan 2003 07:39:48 -0600 | From | Brian King <> | Subject | Re: OOPS in idescsi_end_request |
| |
James Stevenson wrote: > [LARGE SNIP] > > >>Would you agree to test the patch (possibly next week). > > > yeah sure. >
I would be happy to test it as well.
-Brian
> > >>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... >>>>> > > > >
-- Some days it's just not worth chewing through the restraints...
- 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/
| |