On Mon, 28 Feb 2005, Gerd v. Egidy wrote: > > The kernel is a moving target... And those patches were written for the > > USB development kernel, which isn't exactly the same as 2.6.11-rc5. If > > the patches need updating I'll compare my version with yours. > > It wasn't the kernel but the patches among themselves. It seems like the > new reset code wasn't written with the scsi struct stuff in mind, it e.g. > had some us->host stuff in it which I had to replace.
Yes, the new reset patch was written before the other stuff that changed us->host. It needs updating, but I'm still waiting for those other patches to be accepted. > Here are the logs with CONFIG_USB_DEBUG: > > a "regular" reset: <...> > usb-storage: -- transfer cancelled > usb-storage: Bulk status result = 4 > usb-storage: -- command was aborted > ehci_hcd 0000:00:0a.2: port 4 high speed > ehci_hcd 0000:00:0a.2: GetStatus port 4 status 001005 POWER sig=se0 PE > CONNECT > usb 1-4: reset high speed USB device using ehci_hcd and address 2 > ehci_hcd 0000:00:0a.2: port 4 high speed > ehci_hcd 0000:00:0a.2: GetStatus port 4 status 001005 POWER sig=se0 PE > CONNECT > usb-storage: usb_reset_device returns 0 Notice the "PE CONNECT" on the lines from ehci_hcd. That means the device's USB port is enabled and the device is connected. > and a failed reset with disconnect: <...> > usb-storage: Bulk status result = 4 > usb-storage: -- transport indicates error, resetting > ehci_hcd 0000:00:0a.2: GetStatus port 4 status 001000 POWER sig=se0 > ehci_hcd 0000:00:0a.2: GetStatus port 4 status 001000 POWER sig=se0 > hub 1-0:1.0: logical disconnect on port 4 Notice that here ehci_hcd does not report PE or CONNECTED, so the device really has been disconnected from the USB bus. It's not clear whether this was done by the device itself or by the Linux hub driver (which is what the latest patch is supposed to prevent). The fact that there are no lines from ehci_hcd reporting "CSC" -- Connect Status Change -- indicates that maybe the hub driver was responsible. > This patch seems to go in the right direction. The backup is running for > about an hour now (usually the disconnect came at least after 15 min). > > What I've seen is that now it sometimes takes a bit longer than usual > for the reset: > Feb 28 01:43:38 fire kernel: usb-storage: -- short read transfer > Feb 28 01:43:38 fire kernel: usb-storage: Bulk data transfer result 0x1 > Feb 28 01:43:38 fire kernel: usb-storage: Attempting to get CSW... > Feb 28 01:43:38 fire kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 > bytes > >>>>>>>>>>> 30 seconds gap > Feb 28 01:44:08 fire kernel: usb-storage: command_abort called > Feb 28 01:44:08 fire kernel: usb-storage: usb_stor_stop_transport called > Feb 28 01:44:08 fire kernel: usb-storage: -- cancelling URB > Feb 28 01:44:08 fire kernel: usb-storage: Status code -104; transferred 0/13 > Feb 28 01:44:08 fire kernel: usb-storage: -- transfer cancelled > Feb 28 01:44:08 fire kernel: usb-storage: Bulk status result = 4 > Feb 28 01:44:08 fire kernel: usb-storage: -- command was aborted > > But that is seldom, usually the reset is done in a few secs. Maybe these > are the cases that previously caused the disconnects? I don't think so. This looks just like the working-reset case you posted earlier except for the length of the delay. That timeout is set by the SCSI drivers, not by usb-storage, so its length doesn't mean much. By contrast, the failed-reset case involved a slighly different failure mechanism including possible interference from the hub driver. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
