Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Thu, Aug 9, 2012 at 10:29 PM, Alan Stern st...@rowland.harvard.edu wrote: In theory a similar quirk could be written to fix your problem. An easy way to test this, if you can automatically detect the hung condition, would be to set ohci-ed_to_check to the unkillable ed. I used a very stupid/simplistic logic I already had for debugging, to detect the condition: at the fourth (since its normally just one) pass over the SF interrupt clear without being it cleared, I assume it is stuck, and if ed_rm_list is the only one element long, I put it in ed_to_check. This seems to work, but its very odd: in my first test, after the first instance of the occurrence, every 5 second this condition kept popping up, 6 times, until the communication died definitely with -EPIPE: But neither the USB stack or app froze, just plug unplug the device and good to go again. The second test, the highlander ed condition popped up, this time twice, also with a 5 second between them, but no further problems for quite a while after this, and no communication errors. Then three more events 5 sec. apart, and -EPIPE again. It seems this condition comes in a cluster, or the simplistic logic of detection of this condition is not very well suited. -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Wed, Aug 8, 2012 at 11:45 AM, Alan Stern st...@rowland.harvard.edu wrote: The only way for it not be executed is if the skip_ed case occurs. Therefore your next task is to determine what's going on. Does the tick_before() test succeed? Does we follow the goto skip_ed? Or is the list pointer messed up? OK, more info gathered: The skip when Highlander ed is unkillable, is entered from the skip_ed label jump, not from the tick_before() check. ed-ed_next is indeed NULL at that point. -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Tue, Aug 7, 2012 at 3:42 PM, Alan Stern st...@rowland.harvard.edu wrote: I don't have time today to look further into this, but I'll get back to you later. No hurries, in fact I was gathering a bit more info about this behavior. I dumped the ed_rm_list when it is hung, and we have only one element that's unkillable: [ 1108.841482] ohci_hcd :00:04.0: ed_rm_list, ed 8800c781f140 state 0x1 type bulk; next ed [ 1108.841489] ohci_hcd :00:04.0: info 08405103 MAX=64 DQ SKIP EP=2-IN DEV=3 [ 1108.841494] ohci_hcd :00:04.0: tds: head c78261e0 DATA0 tail c78261e0 (not listing) Also, there's only one non-empty ed_rm_list pass after the finish_unlinks between SR intr disables, when not hung. -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Mon, Aug 6, 2012 at 12:24 PM, Alan Stern st...@rowland.harvard.edu wrote: any lines in the dmesg log from boot-up about enabled Compaq ZFMicro chipset quirks? Nope, no quirks message at all in the boot log. Are you comfortable writing your own debugging patches, or would you Quite comfortable, I'll gather more info as soon as I get home from work. My guess is that ed_rm_list is non-NULL, but for some reason finish_unlinks() doesn't do anything -- in particular, it doesn't clear ed_rm_list. As a result the condition in the if statement fails and OHCI_INTR_SF doesn't get written to regs-intrdisable. I'll instrument-ate that area, thanks a lot for your input, Alan. -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Mon, Aug 6, 2012 at 12:24 PM, Alan Stern st...@rowland.harvard.edu wrote: any lines in the dmesg log from boot-up about enabled Compaq ZFMicro chipset quirks? BTW, I printk'ed the ohci-flags just to be sure what quirks were enabled, and only the do not trust power was enabled. My guess is that ed_rm_list is non-NULL, but for some reason finish_unlinks() doesn't do anything -- in particular, it doesn't clear ed_rm_list. As a result the condition in the if statement fails and OHCI_INTR_SF doesn't get written to regs-intrdisable. Ding, Ding, Ding!, we have a winner :-) I did an ugly check: if (ohci-ed_rm_list) finish_unlinks (ohci, ohci_frame_no(ohci)); if ((ints OHCI_INTR_SF) != 0 !ohci-ed_rm_list !ohci-ed_to_check ohci-rh_state == OHCI_RH_RUNNING) ohci_writel (ohci, OHCI_INTR_SF, regs-intrdisable); else if ((ints OHCI_INTR_SF) != 0 ohci-ed_rm_list !ohci-ed_to_check ohci-rh_state == OHCI_RH_RUNNING) ohci_warn(ohci,SF intr should have been disabled, but ed_rm_list is not empty\n); spin_unlock (ohci-lock); Result: The ed_rm_list definitely stays not null forever after the hang. This non-empty ed_rm_list condition is raised even when not hung at quite a rate, but after its hung, this lovely message does a while(1) dmesg benchmark :-) -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Continuous stream of small bulk transfers hangs on OHCI-based system
bytes bInterval 0 Bus 004 Device 003: ID 0666:0001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0666 idProduct 0x0001 bcdDevice1.50 iManufacturer 1 Tomas Sokorai iProduct2 ECM Buddy iSerial 3 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x3390 (Bus Powered) Bus 004 Device 002: ID 045e:001e Microsoft Corp. IntelliMouse Explorer Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x045e Microsoft Corp. idProduct 0x001e IntelliMouse Explorer bcdDevice1.07 iManufacturer 1 Microsoft iProduct2 Microsoft IntelliMouse® Explorer iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.00 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 72 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 10 Device Status: 0x (Bus Powered) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice3.05 iManufacturer 3 Linux 3.5.0-gentoo ehci_hcd iProduct2 EHCI Host Controller iSerial 1 :00:02.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType
Re: Continuous stream of small bulk transfers hangs on OHCI-based system
On Sun, Aug 5, 2012 at 5:36 PM, Alan Stern st...@rowland.harvard.edu wrote: Build a kernel with CONFIG_USB_DEBUG enabled (and also CONFIG_DEBUG_FS). When the hang occurs, go into the subdirectory of /sys/kernel/debug/usb/ohci/ corresponding to the bus the device is plugged into (:00:04.0 if your setup hasn't changed), and post copies of the registers and async files. Thanks for the input, Alan. Here's the registers, before plugging my device in: - bus pci, device :00:04.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead c781f000 hcca frame 0xcca2 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001500 FRT FR=0x1500 periodicstart 0x2a2f lsthresh 0x0700 hub poll timer off roothub.a 01001206 POTPGT=1 NOCP NPS NDP=6(6) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS roothub.portstatus [2] 0x0303 LSDA PPS PES CCS roothub.portstatus [3] 0x0100 PPS roothub.portstatus [4] 0x0100 PPS roothub.portstatus [5] 0x0100 PPS - Here's after plugging in, but before the hang: - bus pci, device :00:04.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead c781f0a0 hcca frame 0x0db6 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x8296 FRT FR=0x0296 periodicstart 0x2a2f lsthresh 0x0700 hub poll timer off roothub.a 01001206 POTPGT=1 NOCP NPS NDP=6(6) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0303 LSDA PPS PES CCS roothub.portstatus [3] 0x0100 PPS roothub.portstatus [4] 0x0100 PPS roothub.portstatus [5] 0x0100 PPS - And finally the one after the USB is hung: - bus pci, device :00:04.0 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0020 FNO intrenable 0x805e MIE RHSC UE RD SF WDH ed_controlhead c781f0a0 ed_bulkhead c781f140 hcca frame 0x2b5d fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x800024e2 FRT FR=0x24e2 periodicstart 0x2a2f lsthresh 0x0700 hub poll timer off roothub.a 01001206 POTPGT=1 NOCP NPS NDP=6(6) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0303 LSDA PPS PES CCS roothub.portstatus [3] 0x0100 PPS roothub.portstatus [4] 0x0100 PPS roothub.portstatus [5] 0x0100 PPS - The async pseudofile yields nothing, every time . -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
