> If anybody else was relying on the driver exceeding the > maximum allowed bandwidth, wouldn't they run across the same BUG as > you did? > > In which case there wouldn't be any downside to putting your patch in > the -stable kernels. > > Alan Stern > Hey, So it turns out, I wasn't completely right. I wanted to respond that nothing prevents somebody from connecting a low-speed keyboard and a modem like mine and using them. Keyboard driver is loaded earlier (initramfs) so it is the modem getting affected by the bug. Since ueagl_atm resubmits failed URBs after few seconds, the modem should work and the user would never see a crash because ueagle_atm never stops resubmitting its URBs. So I made a quick test to confirm this. It turned out that while the keyboard works just fine, the modem never receives any packets. Apparently, the code responsible for continuation of existing streams is *not* able to link "unwanted" streams into hardware queues. So how I managed to exceed the 90% limit? Well, from my previous mail: # Start X, HID resumes [ 97.953708] ohci-pci 0000:00:12.0: ERR -28, interval 8 msecs, load 92 # ENOSPC, mouse doesn't work this time, but ed->state became ED_OPER # Stop X, nothing happens # Start X, ed_schedule bypassed thanks to ED_OPER, mouse works # Stop X, we hit LIST_POISON on unlinking [ 143.457333] ohci-pci 0000:00:12.0: unlink ed ffff8800df04c070 branch0 [92us.], interval 8 [ 143.457548] list_del: ffff8800df04c070 dead000000000100 # Start X, previous unlink() decreased ohci->load so ed_schedule passes [ 162.648710] ohci-pci 0000:00:12.0: link ed ffff8800df04c070 branch 0 [92us.], interval 8 # Stop X [ 181.477893] ohci-pci 0000:00:12.0: unlink ed ffff8800df04c070 branch0 [92us.], interval 8 My comments here were *wrong*. Mouse indeed didn't work on this first attempt with ERR -28. But, it also didn't work on the second attempt, with missing call to ed_schedule() and periodic_link(). It only started working on the 3rd attempt, after this call to periodic_unlink() not preceeded by a matching periodic_link() decreased ohci->load, pulling some "free" bandwidth out of thin air. I was restarting X several times to check for any long-term effect of this bug and didn't notice when exactly the mouse started working. To be sure, I repeated this test now. It really only works on the 3rd try. Getting the modem to work is slightly trickier - it doesn't work if it's simply permanently connected, because ueagle_atm never stsopss submitting URBs and periodic_unlink() isn't called. But this can be "solved" by disconnecting it and connecting again. This is what I must have done at the time when I managed to get this modem and audio work together, doing more than 1ms worth of transactions per frame. Conclusions: On 3.14, it is possible to exceed bandwidth limit if the user and/or drivers are patient enough to try sufficiently many times. No crashes and other side effects observed, besides the obvious possibility of packet loss. Kernels with io_watchdog (3.18+) don't allow this because they crash, so I think it is safe to fix ed_schedule() in those versions. Regards, MP -- 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
