Google
  Web www.spinics.net

Re: USB Mass Storage devices continually reenumerate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, 5 Nov 2007, Mike Nuss wrote:

> Alan,
> 
> On 11/2/07, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Fri, 2 Nov 2007, Mike Nuss wrote:
> >
> > Note, however, the a reset is different from a disconnect.  What you
> > see on the scope is a reset and not a disconnect.
> 
> I was under the impression that resetting the port was more or less
> the same as forcing a disconnect condition (SE0 for some minimum
> amount of time) and then releasing it.

It is.  But the host controller treats a reset differently from a 
disconnect.  During a reset the controller _knows_ that it is 
responsible for the SE0, so it doesn't set the port's 
Connect-Status-Change bit.

> I put a 10 second delay before the return of
> usb_stor_bulk_transfer_sglist to test that theory and the results were
> interesting:
> 
> Nov  5 14:50:02 usb-storage: Status code -62; transferred 192/65536
> Nov  5 14:50:02 usb-storage: -- unknown error
> Nov  5 14:50:02 End usb_stor_bulk_transfer_sglist: Wait 10s
> Nov  5 14:50:02 hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0004
> Nov  5 14:50:02 ohci_hcd 0000:00:13.0: GetStatus roothub.portstatus
> [1] = 0x00030101 PESC CSC PPS CCS

Aha!  So the controller thinks the device really did signal a 
disconnect condition (CSC is set).

> Nov  5 14:50:02 hub 1-0:1.0: port 2, status 0101, change 0003, 12 Mb/s
> Nov  5 14:50:02 usb 1-2: unregistering device
> Nov  5 14:50:02 usb 1-2: usb_disable_device nuking all URBs
> Nov  5 14:50:02 usb 1-2: unregistering interface 1-2:1.0
> Nov  5 14:50:02 usb_endpoint usbdev1.37_ep81: ep_device_release called
> for usbdev1.37_ep81
> Nov  5 14:50:02 usb_endpoint usbdev1.37_ep01: ep_device_release called
> for usbdev1.37_ep01
> Nov  5 14:50:02 usb-storage: storage_disconnect() called
> Nov  5 14:50:02 usb-storage: usb_stor_stop_transport called
> Nov  5 14:50:11 usb-storage: Bulk data transfer result 0x4
> Nov  5 14:50:11 usb-storage: -- transport indicates error, resetting
> Nov  5 14:50:11 usb-storage: -- not issuing reset
> Nov  5 14:50:11 usb-storage: scsi cmd done, result=0x70000
> Nov  5 14:50:11 usb-storage: *** thread sleeping.
> Nov  5 14:50:11 usb-storage: -- usb_stor_release_resources
> Nov  5 14:50:11 usb-storage: -- sending exit command to thread
> Nov  5 14:50:11 usb-storage: *** thread awakened.
> Nov  5 14:50:11 usb-storage: -- exiting
> Nov  5 14:50:11 usb-storage: -- dissociate_dev
> Nov  5 14:50:11 usb 1-2:1.0: uevent
> Nov  5 14:50:11 usb 1-2:1.0: uevent
> Nov  5 14:50:11 usb_endpoint usbdev1.37_ep00: ep_device_release called
> for usbdev1.37_ep00
> Nov  5 14:50:11 usb 1-2: uevent
> Nov  5 14:50:11 hub 1-0:1.0: debounce: port 2: total 100ms stable
> 100ms status 0x101
> Nov  5 14:50:11 DO ROOT PORT RESET
> Nov  5 14:50:11 ohci_hcd 0000:00:13.0: GetStatus roothub.portstatus
> [1] = 0x00100103 PRSC PPS PES CCS
> 
> I don't see the reset in the scope or on the analyzer until 14:50:11
> (presumably coinciding with my DO ROOT PORT RESET message). It looks
> like the HC has disabled the port before the driver has had a chance
> to react - notice the PESC and lack of PES in the first status change
> message. And the spec says that HCD-initiated actions do not set PESC.

Right.  Would your scope show a brief disconnect signal?  According to 
the spec, disconnect can occur after as little as 2 us of SE0.

> It's not clear to me exactly what would have caused PES to be cleared.
> The OHCI spec says: "The Root Hub may clear this bit when an
> overcurrent condition, disconnect event, switched-off power, or
> operational bus error such as babble is detected."  There should be no
> overcurrent since PPS is still set. There is no disconnect because CCS
> is set.

No.  There was a disconnect because CSC is set.  The fact that CCS
(Current-Connect-Status) is also set means that later on there was a
reconnect.

> If the power to the port were switched off, I believe I should
> have seen a disconnect event on the bus analyzer. That leaves the
> possibility of a bus error, except that there were no protocol errors
> that the bus analyzer could detect. The cable connecting to the host
> is very short - could there be a signal integrity issue so close to
> the host, past the point where the analyzer would see it?

Possibly, although perhaps not very likely.  After all, there are USB 
dongles that effectively have no cable at all.  On the other hand, an 
improper capacitance or impedance somewhere on the cable could cause 
signals to spread out or echo, thereby fooling the controller or the 
analyzer.

> Electrically what does it mean for the port to be 'disabled' anyway?

It means that packets won't be sent (or received) through the port.  
Not even SOF packets.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Home]     [Video for Linux]     [Photo]     [Yosemite Forum]     [Yosemite Photos]    [Video Projectors]     [PDAs]     [Hacking TiVo]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Big List of Linux Books]     [Free Dating]

  Powered by Linux