On Sun, Nov 15, 2009 at 04:24, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 15 Nov 2009, Javier Kohen wrote: > >> > Two later patches, 914b701280a76f96890ad63eb0fa99bf204b961c and >> > 7a0f0d951273eee889c2441846842348ebc00a2a, actually caused the callback >> > to be used. So as long as neither of them is installed, I wouldn't >> > expect the first one to make any difference. >> > >> >> I don't know what to tell you. The bisect is clear. I know bisect is not >> perfect for troubleshooting, but unless I messed up really bad in the exact >> wrong moment, it identifies this patch as the culprit. > > Hmm. If necessary, we can try experimenting with this patch to see > what happens. But I can't see how it would cause any difference in > behavior at all. Really, all it does is rename a few items and add a > callback that never gets used. > > Not being a big git user myself, I don't always trust the results of > its bisection searches. Have you tried manually verifying that > reverting this patch from a non-working kernel -- with no other > changes! -- causes it to start working? > >> > Can you provide an equivalent trace with the offending patch reverted? >> > >> > >> Sure thing, it's attached to this mail. I've logged it on Debian kernel >> 2.6.30-5, which is based off 2.6.30.4. From what I see, the main (only?) >> difference is that the broken version talks to device 5 just when this >> breaks, while the other doesn't talk to device 5 at all. Device 5 seems to >> be an internal component of the hub, though I know nothing about USB >> internals. In a previous e-mail I've included the lsusb output hoping that >> it could give you more information about this device 5. > > The "hub" is actually two hubs ganged in series. The first (device 3) > has only two ports, one of which is permanently connected to the second > (device 5), which has four ports. The audio device is plugged into one > of them. > > Just out of curiosity, what does a usbmon trace show when you run the > earliest kernel in the bisection to evoke the problem? That is, a > kernel with the patch you identified but not the two follow-on patches. > I would expect it to be exactly the same as the "working" trace, since > the patch doesn't cause any extra Clear-TT-Buffer requests to be sent. > > For what it's worth, the two usbmon traces don't show any particular > evidence of any problem at all. The "working" trace shows a lack of > messages to device 5 (the hub), as you noticed. Those messages are > Clear-TT-Buffer requests, and they are supposed to get sent whenever an > error occurs in an async transfer to a full- or low-speed device behind > a high-speed hub (the Clear-TT-Buffer gets sent to the hub; the TT, or > Transaction Translator, is the component in the hub responsible for > converting between full speed and high speed). > > The errors were the lines like these: > > ffff880072773d80 2958351933 S Ci:1:007:0 s a1 83 0200 0300 0002 2 < > ffff880072773d80 2958352055 C Ci:1:007:0 -32 0 > > I don't know what "a1 83 0200 0300 0002" means -- some sort of audio > class-specific request. At any rate, the device didn't recognize or > didn't respond to the request (the -32 error code), and that's the > reason for sending the Clear-TT-Buffer requests. > > Thus, the "non-working" trace is actually correct and the "working" > trace is actually wrong! But aside from the lack of Clear-TT-Buffer's, > I didn't notice any particular difference between them. In particular, > the audio data continued to be sent. Whether the device received it is > another question; with isochronous transfers there's no way to know > since they aren't acknowledged by the recipient. > > Maybe the problem is in the hub, not the in audio device. That is, > perhaps it couldn't handle the Clear-TT-Buffer's and stopped relaying > the audio data. Have you tried using a different high-speed hub? I see. That's a likely explanation. However, I don't have any other USB hubs. I'll see if I can borrow one from work and report back. Thanks for your time. If there is anything else you'd like me to try in the meantime, just let me know. Cheers, -- 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
