On Thu, 4 Jul 2013, James Stone wrote: > > Can you post the part of the trace showing where the audio-in Zi lines > > first appear? > > > > I think this is the start of the Zi lines: > > ffff8800b3585f00 3572683229 C Ci:1:004:0 0 4 = 44ac0000 > ffff8800a4976200 3572683283 S Zi:1:004:2 -115:1:1680 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < > ffff8800a4976e00 3572683325 S Zi:1:004:2 -115:1:1688 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < > ffff8800a4976600 3572683330 S Zi:1:004:2 -115:1:1632 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < > ffff8800a4977a00 3572683331 S Zi:1:004:2 -115:1:1640 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < > ffff8800a4977c00 3572683334 S Zi:1:004:2 -115:1:1648 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < > ffff8800a4977e00 3572683336 S Zi:1:004:2 -115:1:1656 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < > ffff8800a4976400 3572683338 S Zi:1:004:2 -115:1:1664 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < > ffff8800a4976a00 3572683342 S Zi:1:004:2 -115:1:1672 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < Yep, that looks right. It shows 8 URBs being submitted, where each URB contains 8 packets at intervals of 1 microframe. Clemens's patch did exactly what it was supposed to. > ffff8800a49dc000 3572683863 C Zi:1:004:1 0:8:735:0 1 0:0:4 4 = 08830500 > ffff8800a49dc000 3572683870 S Zi:1:004:1 -115:8:735 1 -18:0:4 4 < > ffff8800a4977400 3572683875 C Zo:1:004:1 0:1:729:0 8 0:0:96 0:96:80 > 0:176:96 0:272:80 0:352:96 704 > > ffff8800a4977400 3572683882 S Zo:1:004:1 -115:1:729 8 -18:0:80 > -18:80:96 -18:176:80 -18:256:96 -18:352:80 704 = 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800a49dc600 3572684861 C Zi:1:004:1 0:8:743:0 1 0:0:4 4 = 08830500 > ffff8800a49dc600 3572684868 S Zi:1:004:1 -115:8:743 1 -18:0:4 4 < > ffff8800a4977800 3572684872 C Zo:1:004:1 0:1:737:0 7 0:0:96 0:96:96 > 0:192:80 0:272:96 0:368:80 624 > > ffff8800a4977800 3572684878 S Zo:1:004:1 -115:1:737 7 -18:0:80 > -18:80:96 -18:176:80 -18:256:96 -18:352:80 608 = 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800a49dcd00 3572685859 C Zi:1:004:1 0:8:751:0 1 0:0:4 4 = 08830500 > ffff8800a49dcd00 3572685865 S Zi:1:004:1 -115:8:751 1 -18:0:4 4 < > ffff8800a4977000 3572685869 C Zo:1:004:1 0:1:744:0 8 0:0:96 0:96:80 > 0:176:96 0:272:80 0:352:96 704 > > ffff8800a4977000 3572685874 S Zo:1:004:1 -115:1:744 8 -18:0:96 > -18:96:80 -18:176:96 -18:272:80 -18:352:96 720 = 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800a49dca00 3572686736 C Zi:1:004:1 0:8:759:0 1 0:0:4 4 = 08830500 > ffff8800a49dca00 3572686742 S Zi:1:004:1 -115:8:759 1 -18:0:4 4 < > ffff8800a4976800 3572686746 C Zo:1:004:1 0:1:752:0 7 0:0:96 0:96:80 > 0:176:96 0:272:80 0:352:96 624 > > ffff8800a4976800 3572686758 S Zo:1:004:1 -115:1:752 1 -18:0:80 80 = > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 > ffff8800a49dc000 3572687737 C Zi:1:004:1 0:8:767:0 1 0:0:4 4 = 08830500 > ffff8800a49dc000 3572687743 S Zi:1:004:1 -115:8:767 1 -18:0:4 4 < > ffff8800a4977400 3572687747 C Zo:1:004:1 0:1:759:0 8 0:0:80 0:80:96 > 0:176:80 0:256:96 0:352:80 704 > > ffff8800a4977400 3572687753 S Zo:1:004:1 -115:1:759 8 -18:0:96 > -18:96:80 -18:176:96 -18:272:80 -18:352:96 704 = 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800a4977800 3572688612 C Zo:1:004:1 0:1:767:0 7 0:0:80 0:80:96 > 0:176:80 0:256:96 0:352:80 608 > > ffff8800a4977800 3572688623 S Zo:1:004:1 -115:1:767 7 -18:0:96 > -18:96:80 -18:176:96 -18:272:80 -18:352:96 624 = 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800a4976200 3572688861 C Zi:1:004:2 0:1:768:0 8 0:0:40 0:63:40 > 0:126:40 0:189:40 0:252:40 504 = 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 00000000 This shows the completion of the first audio-in URB. It looks normal, except perhaps for the fact that the data values are 0. But there's no doubt that these 0 values were actually sent to the computer by the device. > ffff8800a4976200 3572688872 S Zi:1:004:2 -115:1:768 8 -18:0:63 > -18:63:63 -18:126:63 -18:189:63 -18:252:63 504 < > ffff8800a49dc600 3572688879 C Zi:1:004:1 0:8:775:0 1 0:0:4 4 = 08830500 > ffff8800a49dc600 3572688880 S Zi:1:004:1 -115:8:775 1 -18:0:4 4 < > ffff8800a4977000 3572689612 C Zo:1:004:1 0:1:774:0 8 0:0:96 0:96:80 > 0:176:96 0:272:80 0:352:96 720 > > ffff8800a4977000 3572689646 S Zo:1:004:1 -115:1:774 8 -18:0:80 > -18:80:96 -18:176:80 -18:256:96 -18:352:80 704 = 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 > ffff8800a4976800 3572689657 C Zo:1:004:1 -104:1:782:0 1 0:0:80 80 > Again, this shows no errors or any other problems. It looks perfect. The fact that there are no "unable to submit urb" messages confirms this; the original bug is now gone. But this isn't getting us anywhere. Evidently what we need to see is the part of the trace where the new problem first shows up. Unfortunately, I don't know how it will show up in the trace. One possibility is a "C Zi" line that contains a negative status value -- if you look through the above, you'll see that none of the "C Zi" lines contain a "-" sign. 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
