Date: Wed, 25 May 2011 19:44:43 +0200 From: Hans Petter Selasky <hselasky@freebsd.org> To: freebsd-usb@freebsd.org Cc: "Shah, Vishal" <Vishal.Shah@netapp.com>, "Ranaweera, Samantha" <Samantha.Ranaweera@netapp.com>, "Faylor, Christopher" <Christopher.Faylor@netapp.com>, Andriy Gapon <avg@freebsd.org> Subject: Re: System hang in USB umass module while processing panic Message-ID: <201105251944.43080.hselasky@freebsd.org> In-Reply-To: <86FB7D63AF95574BB762C0C3E1F269150D986E24@RTPMVEXC1-PRD.hq.netapp.com> References: <86FB7D63AF95574BB762C0C3E1F269150D8B14AB@RTPMVEXC1-PRD.hq.netapp.com> <201105251711.09594.hselasky@freebsd.org> <86FB7D63AF95574BB762C0C3E1F269150D986E24@RTPMVEXC1-PRD.hq.netapp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 25 May 2011 19:37:01 Shah, Vishal wrote:
> 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
Hi,
In UNI processor mode the following function will be called, which will poll
the transfers (at the side of the USB processes):
static void
umass_cam_poll(struct cam_sim *sim)
{
struct umass_softc *sc = (struct umass_softc *)sim->softc;
if (sc == UMASS_GONE)
return;
DPRINTF(sc, UDMASS_SCSI, "CAM poll\n");
usbd_transfer_poll(sc->sc_xfer, UMASS_T_MAX);
}
If the umass_cam_poll() is not called, then any pending SCSI commands will not
complete.
However, if the panic triggers inside the USB stack, this might not work like
expected.
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201105251944.43080.hselasky>