Is this something like what you wanted?  Here's my dmesg output:

In scsi_eh_times_out()!
usb-storage: command_abort() called
usb-storage: command_abort() called from an interrupt!!! BAD!!! BAD!! BAD!!

The first line is generated by the following code from scsi_eh_times_out()
which I modified:

void scsi_eh_times_out(Scsi_Cmnd * SCpnt)
{
        unsigned long flags;
        int rtn = FAILED;

        SCpnt->eh_state = SCSI_STATE_TIMEOUT;
        SCpnt->owner = SCSI_OWNER_LOWLEVEL;

        printk(KERN_ERR "In scsi_eh_times_out()!\n");

        /*
         * As far as the low level driver is concerned, this command is
         * still
         * active, so we must give the low level driver a chance to abort
         * it. (DB)
         */
.....

After this, the function is just the same.  The only alteration is the
printk() to indicate where the code is.

On a related note... I notice that this code grabs the io_request_lock
before doing anything.  I thought the lock was held from the point where
the command was queued until I explicitly dropped it (which I don't,
unfortunately)?  Or am I mistaken?

Matt

On Sun, Aug 13, 2000 at 09:47:34PM -0400, Eric Youngdale wrote:
> 
>     I looked at the sources - it looks like the bug is in
> scsi_eh_times_out().  Could you instrument this with some printk()
> statements and verify that this is the case?
> 
>     In the mean time I will think about what it would take to fix this -
> essentially move the relevant code back to the error handler thread.
> 
> -Eric
> 
> ----- Original Message -----
> From: "Matthew Dharm" <[EMAIL PROTECTED]>
> To: "Linux SCSI list" <[EMAIL PROTECTED]>
> Sent: Sunday, August 13, 2000 4:18 PM
> Subject: Re: URGENT 2.4.0 BUG! command abort function called in interrupt!
> 
> 
> > Oh, one more thing I forgot... this test was on 2.4.0-test6 with a patch
> to
> > the latest usb-storage code from the CVS archive.  Anyone who wants to
> > look at that code can get it from
> >
> > cvs -d:pserver:cvs.linux-usb.sourceforge.net:/cvsroot/linux-usb co storage
> >
> > The in_interrupt() test in the command_abort() function is not in the
> stock
> > 2.4.0-test6 kernel -- it's only in the CVS archive.
> >
> > Matt
> >
> > On Sun, Aug 13, 2000 at 01:07:22PM -0700, Matthew Dharm wrote:
> > > I've confirmed the presence of (what I consider to be) an urgent 2.4.0
> bug
> > > in the scsi error handling code.  For a long time I thought this was a
> bug
> > > in the usb-storage code, but it's now clearly a SCSI layer bug.
> > >
> > > The following comes from 2.4.0-test6.
> > >
> > > This is what appears on the console:
> > > -----------------------------------
> > > usb-storage: command_abort() called from an interrupt!!! BAD!!! ...
> > > usb-storage: bus_reset() requested but not implemented
> > > usb-storage: bus_reset() requested but not implemented
> > > usb-storage: host_reset() requested but not implemented
> > >
> > > Note that the first line comes from the usb-storage command abort
> function,
> > > and is a test to see if(in_interrupt()) -- this is the primary
> indication
> > > of the bug.  This function is supposed to be called from a thread
> context
> > > only, and is not IRQ context safe.  But, it's not supposed to have to be
> > > IRQ safe.
> > >
> > > Matt Dharm
> > >
> > > --
> > > Matthew Dharm                              Home:
> [EMAIL PROTECTED]
> > > Senior Engineer, QCP Inc.                            Work:
> [EMAIL PROTECTED]
> > >
> > > Department of Justice agent.  I have come to purify the flock.
> > > -- DOJ agent
> > > User Friendly, 5/22/1998
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > > the body of a message to [EMAIL PROTECTED]
> >
> > --
> > Matthew Dharm                              Home: [EMAIL PROTECTED]
> > Senior Engineer, QCP Inc.                            Work: [EMAIL PROTECTED]
> >
> > Somebody call an exorcist!
> > -- Dust Puppy
> > User Friendly, 5/16/1998
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > the body of a message to [EMAIL PROTECTED]
> >

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Senior Engineer, QCP Inc.                            Work: [EMAIL PROTECTED]

M:  No, Windows doesn't have any nag screens.
C:  Then what are those blue and white screens I get every day?
                                        -- Mike and Cobb
User Friendly, 1/4/1999

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to