kern/56097: ntpdate breaks ums(4)

[dholland%NetBSD.org@localhost]

>Number:         56097
>Category:       kern
>Synopsis:       ntpdate breaks ums(4)
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 08 01:30:00 +0000 2021
>Originator:     David A. Holland
>Release:        NetBSD 9.99.49 (lost track of exactly when from)
>Organization:
>Environment:
System: NetBSD valkyrie 9.99.49 NetBSD 9.99.49 (VALKYRIE) #0: Fri Oct  2 15:00:22 EDT 2020 dholland@valkyrie:/y/objects/usrobj-amd64/sys/arch/amd64/compile/VALKYRIE amd64
Architecture: x86_64
Machine: amd64
>Description:

I ran ntpdate to fix my clock (which had drifted a couple minutes and
had started breaking websites) and a couple minutes thereafter the
mouse pointer quit moving. The kernel printed "ums_disable: not
enabled"; this was roughly four minutes after the clock change.

49 seconds after that the mouse detached itself (it does that when it
feels lonely, there's an old PR on the issue I don't want to go look
up just now since I have no mouse) and on reattach I got

   ehci2: handing over low speed device on port 3 to ohci3
   uhub2: device problem, disabling port 3

Unplugging the mouse and plugging it into a different port produced
the same result twice, once with different ehci/ohci/uhub instances,
and from past experiences with this state I know it will never work
again without a reboot.

It is possible that it's a coincidence (since I have seen this broken
state before, meaning in the relatively recent past since the time usb
stuff broke left and right if you looked at it funny, but never had
any clear picture of what might trigger it) but it seems unlikely.

>How-To-Repeat:

Maybe setting the time explicitly will repeat it. Might give that a
try. Note that running ntpdate to do it will probably only have the
undesired effect if the clock's drifted enough that it steps the clock
rather than adjusts.

I'm not sure what direction the clock was off in; ntpdate printed
"offset 149.7... seconds" but it's not obvious how to interpret the
sign in that. I think the clock had been slow, but I'm not sure.

>Fix:

My guess is that something in ums or usb is not using (the equivalent
of) CLOCK_MONOTONIC when it should be.