From: Brian King <brking@charter.net>
To: James Stevenson <james@stev.org>
Cc: Andrey Borzenkov <arvidjaar@mail.ru>, linux-kernel@vger.kernel.org
Subject: Re: OOPS in idescsi_end_request
Date: Fri, 24 Jan 2003 07:39:48 -0600 [thread overview]
Message-ID: <3E314224.3030405@charter.net> (raw)
In-Reply-To: <00b601c2c387$ebc51c00$0cfea8c0@ezdsp.com>
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...
next prev parent reply other threads:[~2003-01-24 13:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-23 8:52 OOPS in idescsi_end_request Andrey Borzenkov
2003-01-23 9:19 ` Strong kernel lock with linux-2.5.59 : futex in Huge Pages dada1
2003-01-23 9:41 ` Andrew Morton
2003-01-24 3:15 ` OOPS in idescsi_end_request Brian King
2003-01-24 6:21 ` Re[2]: " Andrey Borzenkov
2003-01-24 9:06 ` James Stevenson
2003-01-24 13:39 ` Brian King [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-22 3:41 Brian King
2003-01-22 21:49 ` James Stevenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E314224.3030405@charter.net \
--to=brking@charter.net \
--cc=arvidjaar@mail.ru \
--cc=james@stev.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.