On 02/02/2013 11:39 AM, Alan Stern wrote:
Then the next step is to go into the appropriate subdirectory under
/sys/kernel/debug/usb/ohci/ (the one that corresponds to the controller
having problems) and see what the files in there say.
The following output is from /sys/kernel/debug/usb/ohci/0000:00:0f.4
when the OCHI bus appears to stop receiving data from the FTDI device,
but URB cleanup has not yet been attempted as there are still open
TTY's. Unfortunately the ports are already in a bad state at this point
so I do not know how useful it is.
/sys/kernel/debug/usb/ohci/0000:00:0f.4/periodic:
size = 32
0 [ 11]: ed32/dd5f9040 (fs dev2 ep1in-int qlen 1 max 1 00011082)
/sys/kernel/debug/usb/ohci/0000:00:0f.4/registers:
bus pci, device 0000:00:0f.4
OHCI Host Controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x2af RWC HCFS=operational BLE IE PLE CBSR=3
cmdstatus 0x00004 SOC=0 BLF
intrstatus 0x00000024 FNO SF
intrenable 0x8000005a MIE RHSC UE RD WDH
ed_controlhead 1d5f90c0
ed_bulkhead 1d5f9140
ed_bulkcurrent 1d5f9300
hcca frame 0x46d6
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x8000222a FRT FR=0x222a
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 03000204 POTPGT=3 NPS NDP=4(4)
roothub.b 00000000 PPCM=0000 DR=0000
roothub.status 00008000 DRWE
roothub.portstatus [0] 0x00000103 PPS PES CCS
roothub.portstatus [1] 0x00000103 PPS PES CCS
roothub.portstatus [2] 0x00000103 PPS PES CCS
roothub.portstatus [3] 0x00000103 PPS PES CCS
Here is the output from /sys/kernel/debug/usb/ohci/0000:00:0f.4 after
attempting to kill -9 the process holding the tty open, and subsequently
triggering the cleanup of the port (usb_kill_urb()).
/sys/kernel/debug/usb/ohci/0000:00:0f.4/periodic:
size = 32
0 [ 11]: ed32/dd5f9040 (fs dev2 ep1in-int qlen 1 max 1 00011082)
/sys/kernel/debug/usb/ohci/0000:00:0f.4/registers:
bus pci, device 0000:00:0f.4
OHCI Host Controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x2af RWC HCFS=operational BLE IE PLE CBSR=3
cmdstatus 0x00004 SOC=0 BLF
intrstatus 0x00000020 FNO
intrenable 0x8000005e MIE RHSC UE RD SF WDH
ed_controlhead 1d5f90c0
ed_bulkhead 1d5f9240
ed_bulkcurrent 1d5f9280
donehead 19ca4180
hcca frame 0xda2e
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x80001f0d FRT FR=0x1f0d
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 03000204 POTPGT=3 NPS NDP=4(4)
roothub.b 00000000 PPCM=0000 DR=0000
roothub.status 00008000 DRWE
roothub.portstatus [0] 0x00000103 PPS PES CCS
roothub.portstatus [1] 0x00000103 PPS PES CCS
roothub.portstatus [2] 0x00000103 PPS PES CCS
roothub.portstatus [3] 0x00000103 PPS PES CCS
It may also be possible to get useful information from usbmon, but
that's not easy to do if you don't have a good way to trigger the
problem.
Will try to find a way to continuously collect this data and see if we
can acquire some "before" and "after" information, and maybe get some
"during" in there as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
