https://bugzilla.kernel.org/show_bug.cgi?id=218544 --- Comment #10 from Ian Malone (ibmalone@xxxxxxxxx) --- Created attachment 305965 --> https://bugzilla.kernel.org/attachment.cgi?id=305965&action=edit /sys/kernel/debug/usb/devices other devices and hid disabled You are of course right, the patch can't be easily adapted to apply against the current driver and there are too many incompatibilities with memory management and the rest of the USB system for it to be trivial to drop in the whole 2.6.18 host controller. I'm not sure it was ever really submitted, which is a pity as it looks like it implemented FSTN handling that never otherwise got added. I might fiddle with it a bit more to see if it can be built just to see if it would have helped. Meanwhile, I've tried disabling the HID as well, /sys/kernel/debug/usb/devices attached. This still doesn't work (same "cannot submit urb 0, error -28: not enough bandwidth"). It does puzzle me a bit, we're now down to a single FS device on the hub, while I can understand the scheduling for LS/FS onto HS is complicated I'd have thought this issue would have popped up frequently enough when these laptops were common that it would have been addressed back then. Is there any other information I can extract to find out what's going on with the scheduler? The following are the FS/LS portion of /sys/kernel/debug/usb/ehci/0000:00:1a.0/bandwidth for a good device in out, in and duplex and the problematic device: good device out TT 2-1 port 0 FS/LS bandwidth allocation (us per frame) 482 482 482 482 482 482 482 482 FS/LS budget (us per microframe) 0: 24 0 125 125 125 83 0 0 8: 24 0 125 125 125 83 0 0 16: 24 0 125 125 125 83 0 0 24: 24 0 125 125 125 83 0 0 32: 24 0 125 125 125 83 0 0 40: 24 0 125 125 125 83 0 0 48: 24 0 125 125 125 83 0 0 56: 24 0 125 125 125 83 0 0 2-1.1 ep 82: 24 @ 0.0+1 mask 1c01 2-1.1 ep 01: 458 @ 0.2+1 mask 003c good device in good TT 2-1 port 0 FS/LS bandwidth allocation (us per frame) 109 109 109 109 109 109 109 109 FS/LS budget (us per microframe) 0: 24 0 0 85 0 0 0 0 8: 24 0 0 85 0 0 0 0 16: 24 0 0 85 0 0 0 0 24: 24 0 0 85 0 0 0 0 32: 24 0 0 85 0 0 0 0 40: 24 0 0 85 0 0 0 0 48: 24 0 0 85 0 0 0 0 56: 24 0 0 85 0 0 0 0 2-1.1 ep 82: 24 @ 0.0+1 mask 1c01 2-1.1 ep 81: 85 @ 0.3+1 mask e008 good device duplex TT 2-1 port 0 FS/LS bandwidth allocation (us per frame) 567 567 567 567 567 567 567 567 FS/LS budget (us per microframe) 0: 24 85 125 125 125 83 0 0 8: 24 85 125 125 125 83 0 0 16: 24 85 125 125 125 83 0 0 24: 24 85 125 125 125 83 0 0 32: 24 85 125 125 125 83 0 0 40: 24 85 125 125 125 83 0 0 48: 24 85 125 125 125 83 0 0 56: 24 85 125 125 125 83 0 0 2-1.1 ep 82: 24 @ 0.0+1 mask 1c01 2-1.1 ep 01: 458 @ 0.2+1 mask 003c 2-1.1 ep 81: 85 @ 0.1+1 mask 3802 bad device in TT 2-1 port 0 FS/LS bandwidth allocation (us per frame) 273 273 273 273 273 273 273 273 FS/LS budget (us per microframe) 0: 39 0 125 109 0 0 0 0 8: 39 0 125 109 0 0 0 0 16: 39 0 125 109 0 0 0 0 24: 39 0 125 109 0 0 0 0 32: 39 0 125 109 0 0 0 0 40: 39 0 125 109 0 0 0 0 48: 39 0 125 109 0 0 0 0 56: 39 0 125 109 0 0 0 0 2-1.1 ep 84: 39 @ 0.0+1 mask 1c01 2-1.1 ep 81: 234 @ 0.2+1 mask f004 bad device out TT 2-1 port 0 FS/LS bandwidth allocation (us per frame) 497 497 497 497 497 497 497 497 FS/LS budget (us per microframe) 0: 39 0 125 125 125 83 0 0 8: 39 0 125 125 125 83 0 0 16: 39 0 125 125 125 83 0 0 24: 39 0 125 125 125 83 0 0 32: 39 0 125 125 125 83 0 0 40: 39 0 125 125 125 83 0 0 48: 39 0 125 125 125 83 0 0 56: 39 0 125 125 125 83 0 0 2-1.1 ep 84: 39 @ 0.0+1 mask 1c01 2-1.1 ep 01: 458 @ 0.2+1 mask 003c bad device duplex TT 2-1 port 0 FS/LS bandwidth allocation (us per frame) 497 497 497 497 497 497 497 497 FS/LS budget (us per microframe) 0: 39 0 125 125 125 83 0 0 8: 39 0 125 125 125 83 0 0 16: 39 0 125 125 125 83 0 0 24: 39 0 125 125 125 83 0 0 32: 39 0 125 125 125 83 0 0 40: 39 0 125 125 125 83 0 0 48: 39 0 125 125 125 83 0 0 56: 39 0 125 125 125 83 0 0 2-1.1 ep 84: 39 @ 0.0+1 mask 1c01 2-1.1 ep 01: 458 @ 0.2+1 mask 003c It looks like there's an extra 234us to accommodate for input to work, I'm guessing there are restrictions on where that can go. Is it plausible that if a lower bandwidth mode is requested from the device it would work? That's essentially what I was wondering about with respect to the snd-usb-audio module before this was moved over to usb. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
