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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
