On Tue, 1 Apr 2014, Dennis New wrote: > I was able to capture usbmon output during the event (via a > continuously rotating set of log files over a few days :p) from: > /sys/kernel/debug/usb/usbmon/3u Were you using a kernel with the patch that I sent you? Did you have CONFIG_USB_DEBUG enabled? Did any of the debugging information show up in the kernel log? > Here's the last few lines: > > ffff88000264f200 2922333551 C Zo:3:005:3 0:1:54363:0 6 0:0:192 > 0:192:192 0:384:192 0:576:192 0:768:192 1152 > > > ffff88000264f200 2922333567 S Zo:3:005:3 -115:1:54363 5 -18:0:192 > -18:192:192 -18:384:192 -18:576:192 -18:768:192 960 = f1fff1ff f8fff8ff > fdfffdff 01000100 0a000a00 12001200 17001700 1b001b00 > > ffff88004c22da00 2922338536 C Zo:3:005:3 0:1:54369:0 5 0:0:192 > 0:192:192 0:384:192 0:576:192 0:768:192 960 > > > ffff88004c22da00 2922338547 S Zo:3:005:3 -115:1:54369 5 -18:0:192 > -18:192:192 -18:384:192 -18:576:192 -18:768:192 960 = 09000900 eeffeeff > d5ffd5ff c0ffc0ff b5ffb5ff b7ffb7ff c1ffc1ff d0ffd0ff > > ffff880026f96e40 2970768646 S Co:3:005:0 s 22 01 0100 0003 0003 3 = > 80bb00 > > ffff88004dd99b40 2989531895 C Ii:3:001:1 0:128 1 = 02 > > ffff88004dd99b40 2989531904 S Ii:3:001:1 -115:128 2 < > > ffff88002a29dd80 2989531961 S Ci:3:001:0 s a3 00 0000 0001 0004 4 < > > ffff88002a29dd80 2989531974 C Ci:3:001:0 0 4 = 00010300 > > ffff88002a29dd80 2989531982 S Co:3:001:0 s 23 01 0010 0001 0000 0 > > ffff88002a29dd80 2989531989 C Co:3:001:0 0 0 > > ffff88002a29dd80 2989531995 S Co:3:001:0 s 23 01 0011 0001 0000 0 > > ffff88002a29dd80 2989532002 C Co:3:001:0 0 0 This indicates that the OHCI host controller just stopped working. Then about a minute later, the audio device disconnected. > Here's the diff (days before the crash, and right after) of the stuff > in /sys/kernel/debug/usb/ohci/0000:00:13.1/* : > > registers: > > < cmdstatus 0x00000 SOC=0 > < intrstatus 0x00000024 FNO SF > < intrenable 0x8000005a MIE RHSC UE RD WDH > < ed_controlhead 470140a0 > < hcca frame 0xdf9b > --- > > cmdstatus 0x00002 SOC=0 CLF > > intrstatus 0x00000020 FNO > > intrenable 0x8000005e MIE RHSC UE RD SF WDH > > ed_periodcurrent 47014140 > > ed_controlhead 47014050 > > hcca frame 0xd466 After the crash, did you notice whether the hcca frame value was changing over time? > < fmremaining 0x80001162 FRT FR=0x1162 > --- > > fmremaining 0x800017a0 FRT FR=0x17a0 > > < roothub.portstatus [0] 0x00000103 PPS PES CCS > --- > > roothub.portstatus [0] 0x00000100 PPS This indicates that the device disconnected, and it strongly suggests that the controller isn't behaving properly: The SF bit is set in intrenable; that bit generally remains set for no more than a few milliseconds. Also, the CLF bit shouldn't be set in cmdstatus if no devices are connected to any ports. I don't know that much can be done to prevent the controller from crashing, or to recover from such a crash. Maybe resetting the controller would work, maybe not. But at least it should be possible to insure that a controller malfunction doesn't bring down the entire USB stack with it. I will work on a patch for this, but I'm going to be quite busy with other matters for the next few days. It may take some time to get the patch ready for you to test. Alan Stern -- 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
