lkml.org 
[lkml]   [2003]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Re[2]: OOPS in idescsi_end_request
Date
[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/

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