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


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)

        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 

However, if the panic triggers inside the USB stack, this might not work like 

freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to