Takashi and Clemens: It turns out that a bug in ehci-hcd was causing it to accept four Iso-IN URBs with an interval of 64 ms (audio sync URBs) when it should not have. When the bug is fixed, usbaudio fails because it can't submit all four sync URBs. And when _that_ is fixed, something else still goes wrong causing the EHCI controller to get a fatal error -- I don't yet know why. On Wed, 31 Mar 2010, Nate Case wrote: > Thanks for the patch. I tested this, and the behavior is quite > different now. I still get the "fatal error" / "HC died" *most* of the > time, but you are right that aplay is now failing. Now, aplay errors > out with "aplay: set_params:1041: Unable to install hw params:". > > On the kernel side, I see: > > ALSA sound/usb/usbaudio.c:872: cannot submit syncpipe for urb 3, error -27: internal error > ehci_hcd 0000:07:0c.1: fatal error > ehci_hcd 0000:07:0c.1: fatal command 010038 (park)=0 ithresh=1 Async Periodic period=256 HALT > ehci_hcd 0000:07:0c.1: fatal status c018 Async Periodic FATAL FLR > > The usbmon trace is now much shorter since aplay bails out: > > bfb0e700 107029874 S Co:1:004:0 s 01 0b 0001 0002 0000 0 > bfb0e700 107030073 C Co:1:004:0 0 0 > bfb0e700 107030110 S Ci:1:004:0 s 80 06 0302 0409 00ff 255 < > bfb0e700 107030318 C Ci:1:004:0 0 16 = 10035700 36003800 31003300 30003800 > bfb0e700 107030378 S Co:1:004:0 s 22 01 0100 0002 0003 3 = 80bb00 > bfb0e700 107030568 C Co:1:004:0 0 3 > > bfb0e700 107030579 S Ci:1:004:0 s a2 81 0100 0002 0003 3 < > bfb0e700 107030818 C Ci:1:004:0 0 3 = 000000 > bf13c540 107038689 S Zo:1:004:2 -115:1:0 1 -18:0:96 96 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > bf13c600 107038805 S Zo:1:004:2 -115:1:0 2 -18:0:96 -18:96:96 192 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > bf13c6c0 107038815 S Zi:1:004:6 -115:64:0 1 -18:0:3 4 < > bf13c780 107038824 S Zi:1:004:6 -115:64:0 1 -18:0:3 4 < > bf13c840 107038829 S Zi:1:004:6 -115:64:0 1 -18:0:3 4 < > bf13c900 107038834 S Zi:1:004:6 -115:64:0 1 -18:0:3 4 < > bf13c900 107038841 E Zi:1:004:6 -27 0 > bf13c540 107048196 C Zo:1:004:2 -104:1:74:0 1 0:0:96 96 > > bf13c6c0 107048443 C Zi:1:004:6 -104:64:74:0 1 0:0:3 3 = 00000c > bf13c600 107050194 C Zo:1:004:2 -104:1:75:0 2 0:0:96 0:96:96 192 > > bf13c780 107125058 C Zi:1:004:6 -104:64:138:0 1 0:0:0 0 > bf13c840 107125078 C Zi:1:004:6 -104:64:202:0 1 0:0:0 0 Hmm. These last two timestamps aren't what they should be. These two URBs should have completed almost exactly 64 and 128 ms after the preceding Iso-IN URB, i.e., near timestamps 107112443 and 107176443. Probably the controller died first -- I can't tell because there aren't any timestamps in your kernel log extract above. > bf0bcb80 107125096 C Ii:1:002:1 -108:2048 0 > bfb0e700 107128018 S Co:1:004:0 s 01 0b 0000 0002 0000 0 > bf0bcc00 107129794 C Ii:1:003:1 -108:2048 0 > bfb0e700 107129796 E Co:1:004:0 -108 0 > bf0bc800 107313541 C Ii:1:001:1 -2:2048 0 At least everything else makes sense. > > Incidentally, do you know exactly which USB audio driver is being used? > > The standard in-kernel sound/usb/usbaudio.c driver. For fun, I > redefined SYNC_URBS from 4 to 3 (admittedly not understanding what I'm > doing), but that still had problems. Exactly what happened? Most likely we will have to make that redefinition permanent. Also, what happens if you eliminate the sync URBs completely (set attr to 0 in set_format() instead of using the USB_ENDPOINT_SYNCTYPE mask)? I'm trying to determine whether the fatal error is caused by the sync URBs or by the data URBs. And what about recording instead of playing? Does recording also cause the EHCI controller to crash? 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
