[haiku-development] Re: USB stack and mouse freezing
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 05 Mar 2012 11:45:32 +0100
On 05.03.2012 11:13, Julian Harnath wrote:
... and normally a USB mouse
should use isochronous transfer mode and thus be handled by the higher-
priority thread.. right?
No, what makes you think so? Isochronous transfers are used for a
different kind of situation, namely for streaming audio/video at a
constant rate. Input devices don't usually stream, they only provide
input as soon as something is triggered. Hence they use the appropriate
interrupt transfer type.
However, when I plug my mouse directly into one of the computer's ports,
without the USB hub, the freezing goes away completely, without having
to adjust priorities by hand. Now it's correctly handled by the
isochronous mode thread. That pretty much leaves two options: either
the USB hub is somehow broken or Haiku's USB stack has a bug...
The difference between the two situations is that when you have a hub
involved, the EHCI controller is the one doing the work. When you plug
the device into a root port, since it most likely is a low speed device,
the device will be handed to UHCI/OHCI. Exactly for the situation you
describe, the finisher thread of UHCI/OHCI run at urgent display priority.
Boosting the priority of these finisher threads is kind of a compromise.
They only do heavy work on inbound data intensive situations (reading
lots of data from a USB stick for example). Since usually these more
heavy devices are handled by EHCI and traditionally input devices were
handled by the companion host controllers, the priority was adjusted the
way it is now, i.e. boosted for UHCI/OHCI and normal for EHCI. Since
this breaks down with hubs, and by now new hardware just comes with
builtin hubs and drops the companion host controller completely, this
will have to be adjusted.
Basically it would be fine to just adjust the priority of the EHCI
finisher thread to the same level as for UHCI/OHCI. In principle the
priority could be adjusted based on the priority of the calling threads
that enqueue transfers, this doesn't necessarily work though. Even if
you'd only boost the thread priority if there is a high priority
interrupt transfer pending, you'd end up having the thread boosted for
pretty much all the time. This is due to the fact that the HID driver
always keeps such an interrupt transfer enqueued, as that is how
interrupt transfers are supposed to work (you queue them and they sit
there until the "interrupt" is triggered).
The only thing this on-demand priority boost would help with is that it
wouldn't necessarily boost the threads of all EHCI controllers if there
are multiple. Since one EHCI controller can hold a lot of ports compared
to the traditional 2 on UHCI, this situation isn't too common though and
therefore probably not worth the effort...
Regards
Michael
Other related posts:
