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? 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
