System hang in USB umass module while processing panic

[Shah, Vishal]

Hi Hans Petter,

Thanks for looking into this.
The command is not hanging on a USB device. The issue is, command never
reaches the USB device. As I understand it, after receiving the command
from the upper layers, umass layer will just enqueue the xfer at the
USBD layer. And then usb_proc process is supposed to take the xfer from
the queue and give it to the EHCI layer. When the system panics and gets
into the uni-processor environment, the current process issues a
SYNCHRONIZE_CACHE command keeps polling the umass layer for the
completion of that xfer, and won't leave the single running CPU. For
this reason, the usb_proc is never scheduled after that and the xfer
never reaches the USB device. 

Thanks,
Vishal

-----Original Message-----
From: Hans Petter Selasky [mailto:hselasky at freebsd.org] 
Sent: Wednesday, May 25, 2011 8:11 AM
To: Andriy Gapon
Cc: Shah, Vishal; freebsd-usb at FreeBSD.org; Ranaweera, Samantha; Faylor,
Christopher
Subject: Re: System hang in USB umass module while processing panic

On Wednesday 25 May 2011 17:01:24 Andriy Gapon wrote:
> on 19/05/2011 22:27 Shah, Vishal said the following:
> > In FreeBSD 8 USB driver, commands are asynchronously sent from umass
> > layer onto the wire, in other words, multiple threads are involved
> > before the command is sent from the umass layer all the way to the
wire.
> > Since the usb_proc is not scheduled current process keeps waiting
for
> > the command to complete, hence the hang. Is this a known issue? If
yes,
> > is there a fix available? Are there any plans of adding a
synchronous
> > path to send the command to the device? Any information regarding
this
> > issue is much appreciated.
> 
> From your description this sounds like a problem in USB driver.
> I am not an expert in USB code, looks like some polling prodding would
have
> to be added there (if it's not there yet).  Hans Petter may be a
better
> contact for this issue.
> I am not sure if I can help you more.

Hi,

The umass driver is being polled during panic. If some command is
hanging on a 
USB device then USB cannot do anything about it. Only the CAM layer can
abort 
the SCSI command, because the USB layer doesn't know if it is the dump
device 
or not? Sometimes the command timeouts are rather longs so waiting until
the 
command times out might work to get a core dump.

--HPS