On Mon, Nov 16, 2009 at 16:45, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, 15 Nov 2009, Javier Kohen wrote: > > > Mea culpa. It seems I made an off by one error in the bisect. I just built a > > kernel at cb88a1b887bb8908f6e00ce29e893ea52b074940 again and it worked, as > > you expected. However, a kernel built at > > 914b701280a76f96890ad63eb0fa99bf204b961c, the next commit in the tree, > > triggers the bug. I could send the usbmon trace, but there is nothing new in > > it. > > Okay, that makes a lot more sense. > > > From your other mail it's not clear to me what is the next step. You explain > > that the new driver behavior is correct, even though now my sound card > > doesn't work anymore, after a year or so of higher-quality music listening > > experience. Assuming no bugs in the logic that triggers the clear-TT-buffer, > > what options are there? > > While looking again at the code, I did see one minor flaw. I doubt it > will make any difference but you might as well try out the patch below. > > At this point, the only other option is to test a different hub, under > the assumption that the monitor's internal hub is buggy. Unfortunately the patch didn't help. 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. -- 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
