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:hsela...@freebsd.org] Sent: Wednesday, May 25, 2011 8:11 AM To: Andriy Gapon Cc: Shah, Vishal; freebsd-usb@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 _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"