On 16.08.2025 5:04 AM, Alan Stern wrote:
You gave me directions where I should look for, because I didn't know how to
start debugging without the logic analyzer.
Usbmon captures only USB communication packets and some of USB HUB
controlling packets (such as TT related), but does not include
device-controlling MMIO registers, which was the case here.
I'll add debug prints to everything related to MMIO and take a look what
could be improved. Thanks!
Good luck!
If you have other ideas I could try right away, please share them!
You might compare the usbmon traces for your patched OHCI against a UHCI
system. They should run at approximately the same speed, so it's not
clear why the printer would work with one but not the other.
Alan, Greg, I found the reason for 1 ms delay: it is artificial, added
in v2.5.21 as a possible race condition fix:
/* SF interrupt might get delayed; record the frame counter value that
* indicates when the HC isn't looking at it, so concurrent unlinks
* behave. frame_no wraps every 2^16 msec, and changes right before
* SF is triggered.
*/
ed->tick = le16_to_cpu (ohci->hcca->frame_no) + 1;
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/drivers/usb/host/ohci-q.c?id=9a53bdfbe26329e78f43485fc43f5fab5f27cbbc
ED it just not getting processed at all until the time (counted by
frame_no) is reached, apparently there is/was no other way to ensure HC
is finished with this ED.
/* only take off EDs that the HC isn't using, accounting for
* frame counter wraps. completion callbacks might prepend
* EDs to the list, they'll be checked next irq.
*/
if (tick_before (tick, ed->tick)) {
last = &ed->ed_rm_list;
continue;
}
I removed "+ 1" and it removed that 1ms delay. Doesn't seem to break
anything in my setup. UHCI code doesn't seem to have any similar delays.
Could it be relevant only for hardware of its era? If I add "no +1" code
quirk as a module option, disabled by default, does it sounds sane to you?
