Track down EHCI and companion errors on rk3xxx systems

[Alan Stern]

On Tue, Jan 13, 2026 at 05:16:05PM +0100, Diederik de Haas wrote:
> On Tue Jan 13, 2026 at 4:47 PM CET, Alan Stern wrote:
> > Is this repeatable?
> 
> It doesn't happen every time, but it did actually happen another time.
> After that test, I shutdown the device and unplugged the keyboard
> adapter. Then I powered on the device and waited till it had completed
> the boot process.
> Logged in via SSH, retrieved my usual boot process data (what you saw in
> my 'paste' starting with ``uname -a``) and then did ``dmesg -W``.
> 
> Then I plugged in my keyboard adapter in the bottom port and noticed it
> didn't work (straight away). This time I waited, pressed various keys on
> my keyboard, turned the keyboard off and on again, pressed some more
> keys ... and after ~20 (or 30?) seconds, my keyboard started to work.
> When I then switched back to my SSH session, I saw dmesg had (then)
> printed messages indicating it saw the adapter plugged in and ``lsusb``
> did see the device.
> 
> But that ~20 seconds is key here. Normally I would conclude that "it
> doesn't work" after (say) >5 seconds of nothing happening.
> 
> > If it is, try doing the following.  After a fresh boot, log in via SSH 
> > and turn on dynamic debugging for USB:
> >
> > 	echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control
> >
> > and clear the kernel's log buffer:
> >
> > 	dmesg -C
> 
> Would ``dmesg -W`` also work?

The point is to get rid of the everything in the log from before the 
time you plug in the keyboard adapter.  If you want to use "dmesg -W" 
and edit out all the initial stuff by hand, that's fine.  I just don't 
want to see it, because it's not useful and will only make the report 
harder to figure out.

> > Then plug the keyboard adapter into the non-working bottom USB2 port and 
> > wait a short time (say, 30 seconds).
> >
> > Then get a copy of the dmesg output and post it here.  Also, check to 
> > see whether the keyboard is working.  In fact, you should check the 
> > keyboard during that 30-second wait, so you will know just how long the 
> > delay was before it started working.
> 
> Normally my SSH session is displayed on the same monitor as the desktop
> session of the Quartz64-A (I switch between HDMI-1 and HDMI-2 input
> sources of my monitor). This makes doing any kind of precise timing
> activity impossible. I'll try doing the SSH session via my laptop, which
> hopefully allows timings to be closer (but likely still not precise).

Exact timing isn't important.  An approximate number that can be 
compared with the log is what we want.

> > Another thing you can try is to force the necessary module(s) to load 
> > before plugging in the keyboard adapter.  For now, a simple modprobe 
> > issued over the SSH connection will do the job.  If this turns out to 
> > help, you can configure modprobe to load the module(s) automatically at 
> > boot time.
> 
> I was already planning to make it built-in as the chances of me not
> needing USB2 in some way, are quite slim. And they should (hopefully)
> prevent such issues and I'd have a warning less in dmesg.

Okay.

Alan Stern