Date: Wed, 25 May 2011 13:37:01 -0400 From: "Shah, Vishal" <Vishal.Shah@netapp.com> To: "Hans Petter Selasky" <hselasky@freebsd.org>, "Andriy Gapon" <avg@freebsd.org> Cc: "Ranaweera, Samantha" <Samantha.Ranaweera@netapp.com>, "Faylor, Christopher" <Christopher.Faylor@netapp.com>, "freebsd-usb@FreeBSD.org" <freebsd-usb@freebsd.org> Subject: RE: System hang in USB umass module while processing panic Message-ID: <86FB7D63AF95574BB762C0C3E1F269150D986E24@RTPMVEXC1-PRD.hq.netapp.com> In-Reply-To: <201105251711.09594.hselasky@freebsd.org> References: <86FB7D63AF95574BB762C0C3E1F269150D8B14AB@RTPMVEXC1-PRD.hq.netapp.com> <4DDD19C4.6090705@FreeBSD.org> <201105251711.09594.hselasky@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.=20 Thanks, Vishal -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@freebsd.org]=20 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. >=20 > 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=20 USB device then USB cannot do anything about it. Only the CAM layer can abort=20 the SCSI command, because the USB layer doesn't know if it is the dump device=20 or not? Sometimes the command timeouts are rather longs so waiting until the=20 command times out might work to get a core dump. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86FB7D63AF95574BB762C0C3E1F269150D986E24>