On Fri, Feb 01, 2008 at 11:59:56AM -0500, Alan Stern wrote:
> On Fri, 1 Feb 2008, Matthew Dharm wrote:
> 
> > On Fri, Feb 01, 2008 at 10:17:24AM -0500, Alan Stern wrote:
> > > On Thu, 31 Jan 2008, David Brownell wrote:
> > > 
> > > > On Thursday 31 January 2008, Alan Stern wrote:
> > > > > The interesting difference lay in what Windows did when the 
> > > > > Get-Max-LUN 
> > > > > stalled.  It sent a Clear-Halt request to endpoint 0!
> > > > 
> > > > Yes that *is* strange!  Considering that ep0 wasn't stalling ...
> > > 
> > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro
> > > trace and that's what happened under Linux).  This was in response to
> > > the Bulk-only-transport class-specific Get-Max-LUN request.  Devices
> > > are permitted not to support that request if they have only one LUN.
> > > 
> > > Right now usb-storage responds to this stall by clearing the halt 
> > > feature from the bulk-in and bulk-out endpoints, not because the spec 
> > > says to do so but because one ancient device (a ZIP-100) requires it.  
> > > Now it looks as though we've found a device which can't handle it.  
> > > Time for another quirk?
> > 
> > Do we really need another quirk?  If the 'popular' OS does it, it's likely
> > safe to do for all deveices when GetMaxLUN fails...
> 
> You missed the point.  Windows does _not_ do it -- i.e., does not clear 
> a halt on either bulk endpoint.  Linux does so only because somebody 
> (either Pete Zaitcev or Pat Lavarre, I can't remember which) pointed 
> out that the ZIP-100 drive needs it.
> 
> The clear-halt for endpoint 0 probably isn't needed by anything; I
> don't know why Windows does it.

Anything except this device, that is.  I thought we had traces of Windows
issuing a clear-halt to endpoint 0 after a failed GetMaxLUN.  Or did I read
the thread wrong?

Matt

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

Somebody call an exorcist!
                                        -- Dust Puppy
User Friendly, 5/16/1998

Attachment: pgpakLrLf2mi6.pgp
Description: PGP signature

Reply via email to