On Mon, 16 Nov 2009, Javier Kohen wrote: > I'm trying to find another hub to test, with no luck so far. However, > even if the monitor's hub were buggy, I'm hoping there is a way to > workaround the problem in the kernel, since said problem didn't exist > a short time ago. That's not entirely accurate. The problem is that the hub stops sending isochronous packets when it gets a Clear-TT-Buffer. This problem _did_ exist a short time ago -- it just wasn't triggered because the kernel was erroneously failing to send Clear-TT-Buffer requests when it should have sent them. To tell the truth, I don't see any way to work around the problem at the moment. The Clear-TT-Buffer functionality is a fundamental part of the workings of any high-speed hub. If the hub doesn't implement it correctly, there's not much we can do. Of course, there's always the possibility of making the kernel stop sending Clear-TT-Buffer requests entirely. (Or at least, stop sending them in response to STALLs, which is what you are receiving.) But this would violate the USB 2.0 specification (*), so it's not something I would consider lightly. Alan Stern (*) The relevant sections are: Near the end of 11.17.1 (after Figure 11-51) where the text says If the host receives a STALL handshake, it performs endpoint halt processing and will not issue any more split transactions for this full-/low-speed endpoint until the halt condition is removed. and 11.17.5 where the text says When a bulk/control split transaction fails, it can leave the associated TT transaction buffer in a busy (ready/x) state. This buffer state will not allow the buffer to be reused for other bulk/control split transactions. Therefore, as part of endpoint halt processing for full-/low-speed endpoints connected via a TT, the host software must use the Clear_TT_Buffer request to the TT to ensure that the buffer is not in the busy state. Admittedly, I don't see how a STALL handshake could be consistent with a busy transaction buffer, so maybe the spec is wrong in this respect. I still hesitate to violate it. Besides, Clear-TT-Buffer is supposed to be harmless if the buffer isn't busy. It certainly shouldn't affect periodic transfers. -- 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