On Fri, 31 Jan 2014 21:30:03 -0500 (EST), Alan Stern wrote: > On Thu, 30 Jan 2014, Dennis New wrote: > > > Indeed, "ohci_quirk_zfmicro" (as mentioned in that marc.info link) > > would crash my kernel/system (I think when some graphics switch > > would happen) :). So I tried "ohci_quirk_amd700", since there were > > already some PCI_VENDOR_ID_ATI quirks in ohci-pci.c that were using > > it, but alas, no luck. After about 6 days, the hang/crash happened > > again. I wasn't able to get debugging info this time around :s. > > > > The mystery continues. > > Hmmm. Looking again at the data you collected, it appears that those > quirks are not going to help. _Something_ has gone wrong, but it's > hard to tell what. At first I thought maybe the OHCI controller had > simply stopped generating interrupt requests, but that doesn't seem to > agree with the debugging output. > > I'll have to write a diagnostic patch to get more information. > Unfortunately the next few days are going to be pretty busy, so I > won't be able to get to it for a while. 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 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 Here's the last 1000 lines: http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/usbmon-debug1.gz 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 < fmremaining 0x80001162 FRT FR=0x1162 --- > fmremaining 0x800017a0 FRT FR=0x17a0 < roothub.portstatus [0] 0x00000103 PPS PES CCS --- > roothub.portstatus [0] 0x00000100 PPS periodic: < 0 [ 22]: ed1/ffff880047014050 (fs dev3 ep1in-int qlen 1 max 16 00101083) < 1 [ 22]: ed1/ffff880047014050 ... < 31 [ 22]: ed1/ffff880047014050 --- > 0 [ 22]: ed1/ffff8800470140a0 (fs dev5 ep1in-int qlen 1 max 16 00101085) > 1 [ 22]: ed1/ffff8800470140a0 > 31 [ 22]: ed1/ffff8800470140a0 -- 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
