On Sun, 15 Nov 2009, Javier Kohen wrote: > 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. Just the items mentioned above: Verify that a kernel with the patch installed fails, then revert the patch manually and verify that the resulting kernel succeeds. Get a usbmon trace with the offending patch present but not the two further patches. Verify that this kernel fails. 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
