CAM: delaying new commands during reset

1999-07-05 Thread Nick Hibma
The Iomega USB Zip drive is a bit slow when resetting (reset of the USB part of the drive). It takes 1s or more to reset. The reset is initiated because for example an illegal command was received (sync cache for example). umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) umass0: CBW

CAM: delaying new commands during reset

1999-07-05 Thread Nick Hibma
The Iomega USB Zip drive is a bit slow when resetting (reset of the USB part of the drive). It takes 1s or more to reset. The reset is initiated because for example an illegal command was received (sync cache for example). umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) umass0: CBW

Re: CAM: delaying new commands during reset

1999-07-05 Thread Matthew Jacob
I'm not sure what you mean by 'Busy' here, but it doesn't matter I believe- the cam_periph_async called with case AC_SENT_BDR: case AC_BUS_RESET: { cam_periph_bus_settle(periph, SCSI_DELAY); break; } should do bus settling for

Re: CAM: delaying new commands during reset

1999-07-06 Thread Nick Hibma
> I'm not sure what you mean by 'Busy' here, but it doesn't matter I > believe- the cam_periph_async called with CAM actions come in and initiate one or more USB transfers. When the action has completed or failed, xpt_done() is called to mark the ccb as completed. If the command has failed,

Re: CAM: delaying new commands during reset

1999-07-06 Thread Daniel Eischen
Nick Hibma wrote: > > I'm not sure what you mean by 'Busy' here, but it doesn't matter I > > believe- the cam_periph_async called with > > CAM actions come in and initiate one or more USB transfers. When the > action has completed or failed, xpt_done() is called to mark the ccb as > completed.

Re: CAM: delaying new commands during reset

1999-07-06 Thread Justin T. Gibbs
This stuff should really go to the SCSI list. I read that list much more frequently than this one. > The Iomega USB Zip drive is a bit slow when resetting (reset of the USB > part of the drive). It takes 1s or more to reset. The reset is initiated > because for example an illegal command was rec

Re: CAM: delaying new commands during reset

1999-07-05 Thread Matthew Jacob
I'm not sure what you mean by 'Busy' here, but it doesn't matter I believe- the cam_periph_async called with case AC_SENT_BDR: case AC_BUS_RESET: { cam_periph_bus_settle(periph, SCSI_DELAY); break; } should do bus settling for S

Re: CAM: delaying new commands during reset

1999-07-06 Thread Nick Hibma
> I'm not sure what you mean by 'Busy' here, but it doesn't matter I > believe- the cam_periph_async called with CAM actions come in and initiate one or more USB transfers. When the action has completed or failed, xpt_done() is called to mark the ccb as completed. If the command has failed, t

Re: CAM: delaying new commands during reset

1999-07-06 Thread Daniel Eischen
Nick Hibma wrote: > > I'm not sure what you mean by 'Busy' here, but it doesn't matter I > > believe- the cam_periph_async called with > > CAM actions come in and initiate one or more USB transfers. When the > action has completed or failed, xpt_done() is called to mark the ccb as > completed.

Re: CAM: delaying new commands during reset

1999-07-06 Thread Justin T. Gibbs
This stuff should really go to the SCSI list. I read that list much more frequently than this one. > The Iomega USB Zip drive is a bit slow when resetting (reset of the USB > part of the drive). It takes 1s or more to reset. The reset is initiated > because for example an illegal command was rece