From owner-freebsd-usb@FreeBSD.ORG Wed May 25 17:37:07 2011 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4246106564A; Wed, 25 May 2011 17:37:06 +0000 (UTC) (envelope-from Vishal.Shah@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id B68B98FC08; Wed, 25 May 2011 17:37:06 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.65,268,1304319600"; d="scan'208";a="550727477" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 25 May 2011 10:37:06 -0700 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p4PHb6WS014129; Wed, 25 May 2011 10:37:06 -0700 (PDT) Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 May 2011 10:37:06 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.112]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 May 2011 13:37:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2011 13:37:01 -0400 Message-ID: <86FB7D63AF95574BB762C0C3E1F269150D986E24@RTPMVEXC1-PRD.hq.netapp.com> In-Reply-To: <201105251711.09594.hselasky@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: System hang in USB umass module while processing panic Thread-Index: Acwa7jbrK8VCBUzkSRGAWPHQOAiyCQAEjr6w References: <86FB7D63AF95574BB762C0C3E1F269150D8B14AB@RTPMVEXC1-PRD.hq.netapp.com> <4DDD19C4.6090705@FreeBSD.org> <201105251711.09594.hselasky@freebsd.org> From: "Shah, Vishal" To: "Hans Petter Selasky" , "Andriy Gapon" X-OriginalArrivalTime: 25 May 2011 17:37:04.0922 (UTC) FILETIME=[5CE3CFA0:01CC1B02] Cc: "Ranaweera, Samantha" , "Faylor, Christopher" , "freebsd-usb@FreeBSD.org" Subject: RE: System hang in USB umass module while processing panic X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:37:07 -0000 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