Re: USB Mass Storage devices continually reenumerate

"Mike Nuss" <[email protected]>
Newsgroups gmane.linux.usb.devel
Message-ID <[email protected]>
Alan,

On 11/2/07, Alan Stern <[email protected]> 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.

> I can explain part of it.  After failure to receive the CSW,
> usb-storage always calls for a device reset.  That explains why you see
> the reset signal on the bus.  Whether or not a "logical disconnect"
> then occurs will depend on how the device behaves following the reset.

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
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.

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. 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?

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

Mike

-------------------------------------------------------------------------
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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.