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.
> On a side note, I'll see if I find a way to investigate the problem with
> OHCI. Usbmon didn't help. Next time I'll run with a kernel with verbose ALSA
> debug.
Okay.
Alan Stern
Index: usb-2.6/drivers/usb/core/hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -447,7 +447,7 @@ resubmit:
static inline int
hub_clear_tt_buffer (struct usb_device *hdev, u16 devinfo, u16 tt)
{
- return usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
+ return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
HUB_CLEAR_TT_BUFFER, USB_RT_PORT, devinfo,
tt, NULL, 0, 1000);
}
--
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
