Track down EHCI and companion errors on rk3xxx systems

Track down EHCI and companion errors on rk3xxx systems

[Alan Stern]

[Changed the Subject: line and started a new email thread]

On Sat, Jan 03, 2026 at 12:00:13PM +0100, Diederik de Haas wrote:
> Hi Alan,
> 
> On Wed Dec 31, 2025 at 7:09 PM CET, Alan Stern wrote:
> > I can't say anything specific about your systems without a lot more 
> > information.  However, I suspect that any problems you are running into 
> > are not related to that warning.
> 
> What kind of information do you need? I have quite a few schematics and
> TRMs (which are also publicly available). Also happy to run various
> tests if that helps. I just need to know which.

We can start with the output from "lsusb -t" as well as the dmesg log 
from a boot in which something (a USB-2 port, for example) didn't work.  
If the log shows something going wrong when you plugged in a device 
after boot, explain what you did, what happened, and what was wrong.

For now, concentrate on just a single system.  It will be much too 
confusing to try handling all this material one seven different 
computers, all at once.

Alan Stern

PS: Always use Reply-to-All so that your messages get sent to the 
mailing list as well as to me.

Re: Track down EHCI and companion errors on rk3xxx systems

[Diederik de Haas]

On Sat Jan 3, 2026 at 5:52 PM CET, Alan Stern wrote:
> On Sat, Jan 03, 2026 at 12:00:13PM +0100, Diederik de Haas wrote:
>> On Wed Dec 31, 2025 at 7:09 PM CET, Alan Stern wrote:
>> > I can't say anything specific about your systems without a lot more 
>> > information.  However, I suspect that any problems you are running into 
>> > are not related to that warning.
>> 
>> What kind of information do you need?
>
> We can start with the output from "lsusb -t" as well as the dmesg log 
> from a boot in which something (a USB-2 port, for example) didn't work.  
> If the log shows something going wrong when you plugged in a device 
> after boot, explain what you did, what happened, and what was wrong.
>
> For now, concentrate on just a single system.

I was almost ready to declare 'issue fixed' when I actually did notice
the issue on a Quartz64-B (RK3566). For 'reasons', that may not be the
best test subject. Then I was preparing to test some media patches and
prepared my Quartz64-A (also RK3566), which is usually online 24/7.

Plugged in my keyboard adapter in the top USB2 port and that worked.
Installed some packages to make the graphical environment match that of
my other test devices and rebooted.
Got my (gtkgreet) login screen and plugged in my keyboard adapter in the
*bottom* USB2 port ... and that did NOT work.

Logged in via SSH and noticed it was indeed not listed in ``lsusb``.
Checked ``lsmod`` and ``dmesg | tail`` ... and noticed the kernel *did*
notice plugging in the keyboard adapter, so did ``lsusb`` *again* and
then it *did* list my keyboard adapter.
I did NOT employ my usual 'workaround' by plugging it into a USB3 port.

So it may be that it would have always worked ... eventually ... if I
had just waited long enough?
While 'dmesg' seems to suggest it took little over 0.5 seconds, I'm
really not that fast ;-P (or that impatient)

Full log:
https://paste.sr.ht/~diederik/34847f5c6873f1fc8d32eeb79f2bf2ff9dd4570c

Cheers,
  Diederik

Re: Track down EHCI and companion errors on rk3xxx systems

[Alan Stern]

On Tue, Jan 13, 2026 at 02:35:21PM +0100, Diederik de Haas wrote:
> Got my (gtkgreet) login screen and plugged in my keyboard adapter in the
> *bottom* USB2 port ... and that did NOT work.
> 
> Logged in via SSH and noticed it was indeed not listed in ``lsusb``.
> Checked ``lsmod`` and ``dmesg | tail`` ... and noticed the kernel *did*
> notice plugging in the keyboard adapter, so did ``lsusb`` *again* and
> then it *did* list my keyboard adapter.
> I did NOT employ my usual 'workaround' by plugging it into a USB3 port.
> 
> So it may be that it would have always worked ... eventually ... if I
> had just waited long enough?
> While 'dmesg' seems to suggest it took little over 0.5 seconds, I'm
> really not that fast ;-P (or that impatient)

Is this repeatable?

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

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.

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.

Alan Stern

Re: Track down EHCI and companion errors on rk3xxx systems

[Diederik de Haas]

On Tue Jan 13, 2026 at 4:47 PM CET, Alan Stern wrote:
> On Tue, Jan 13, 2026 at 02:35:21PM +0100, Diederik de Haas wrote:
>> Got my (gtkgreet) login screen and plugged in my keyboard adapter in the
>> *bottom* USB2 port ... and that did NOT work.
>> 
>> Logged in via SSH and noticed it was indeed not listed in ``lsusb``.
>> Checked ``lsmod`` and ``dmesg | tail`` ... and noticed the kernel *did*
>> notice plugging in the keyboard adapter, so did ``lsusb`` *again* and
>> then it *did* list my keyboard adapter.
>> I did NOT employ my usual 'workaround' by plugging it into a USB3 port.
>> 
>> So it may be that it would have always worked ... eventually ... if I
>> had just waited long enough?
>> While 'dmesg' seems to suggest it took little over 0.5 seconds, I'm
>> really not that fast ;-P (or that impatient)
>
> 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?

> 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).

> 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.

Cheers,
  Diederik

Re: 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

Re: Track down EHCI and companion errors on rk3xxx systems

[Diederik de Haas]

On Tue Jan 13, 2026 at 5:22 PM CET, Alan Stern wrote:
> 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
>> >
>> > 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.
>> 
>> 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.

I'm now wondering if there's something wrong with the Quartz64-A ...
I already thought that it took way too long before I got a login prompt.

In my first attempt I noticed I did NOT have the "Warning! ehci_hcd
should always be loaded before uhci_hcd and ohci_hcd, not after"
It took so long I forgot to keep counting, but most of all I forgot the
dynamic debug command, so I tried again ...

This time I did the dynamic debug command and the above "Warning!" was
present. Plugged in the keyboard adapter, started a stopwatch on my
phone and monitored the ``dmesg -W`` for any changes ...

It took slightly more then a MINUTE for anything to appear in dmesg :-O

```
root@quartz64a:~# dmesg -W
[  357.343890] usb usb4: usb wakeup-resume
[  357.343970] usb usb4: usb auto-resume
[  357.344023] hub 4-0:1.0: hub_resume
[  357.344243] usb usb4-port1: status 0501 change 0001
[  357.446845] hub 4-0:1.0: state 7 ports 1 chg 0002 evt 0000
[  357.447094] usb usb4-port1: status 0501, change 0000, 480 Mb/s
[  357.510889] hub 4-0:1.0: port_wait_reset: err = -16
[  357.510909] usb usb2: usb wakeup-resume
[  357.510956] usb usb4-port1: not enabled, trying reset again...
[  357.510980] usb usb2: usb auto-resume
[  357.586708] hub 2-0:1.0: hub_resume
[  357.586936] usb usb2-port1: status 0101 change 0001
[  357.690841] hub 2-0:1.0: state 7 ports 1 chg 0002 evt 0000
[  357.691090] usb usb2-port1: status 0101, change 0000, 12 Mb/s
[  357.714843] usb usb4-port1: not reset yet, waiting 200ms
[  357.874717] usb 2-1: new full-speed USB device number 2 using ohci-platform
[  357.918838] usb usb4-port1: not reset yet, waiting 200ms
[  358.082679] usb 2-1: ep0 maxpacket = 32
[  358.087855] usb 2-1: skipped 1 descriptor after interface
[  358.087926] usb 2-1: skipped 1 descriptor after interface
[  358.089798] usb 2-1: default language 0x0409
[  358.093839] usb 2-1: udev 2, busnum 2, minor = 129
[  358.093904] usb 2-1: New USB device found, idVendor=1997, idProduct=2433, bcdDevice= 1.06
[  358.094803] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  358.095481] usb 2-1: Product: mini keyboard
[  358.095889] usb 2-1: Manufacturer:
[  358.097629] usb 2-1: usb_probe_device
[  358.097691] usb 2-1: configuration #1 chosen from 1 choice
[  358.099335] usb 2-1: adding 2-1:1.0 (config #1, interface 0)
[  358.100603] usb 2-1: adding 2-1:1.1 (config #1, interface 1)
[  358.101371] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
[  358.126129] usb usb4-port1: not reset yet, waiting 200ms
[  358.203797] hid: raw HID events driver (C) Jiri Kosina
[  358.227055] usbhid 2-1:1.0: usb_probe_interface
[  358.227080] usbhid 2-1:1.0: usb_probe_interface - got id
[  358.231307] usbhid 2-1:1.1: usb_probe_interface
[  358.231331] usbhid 2-1:1.1: usb_probe_interface - got id
[  358.236333] usbcore: registered new interface driver usbhid
[  358.236850] usbhid: USB HID core driver
[  358.267050] input:   mini keyboard as /devices/platform/fd8c0000.usb/usb2/2-1/2-1:1.0/0003:1997:2433.0001/input/input2
[  358.326722] usb usb4-port1: not reset yet, waiting 200ms
[  358.326992] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002
[  358.327125] usb usb4-port1: status 0100, change 0001, 12 Mb/s
[  358.368453] hid-generic 0003:1997:2433.0001: input,hidraw0: USB HID v1.01 Keyboard [  mini keyboard] on usb-fd8c0000.usb-1/input0
[  358.372573] input:   mini keyboard Mouse as /devices/platform/fd8c0000.usb/usb2/2-1/2-1:1.1/0003:1997:2433.0002/input/input3
[  358.376787] input:   mini keyboard System Control as /devices/platform/fd8c0000.usb/usb2/2-1/2-1:1.1/0003:1997:2433.0002/input/input4
[  358.432171] input:   mini keyboard Consumer Control as /devices/platform/fd8c0000.usb/usb2/2-1/2-1:1.1/0003:1997:2433.0002/input/input5
[  358.434480] hid-generic 0003:1997:2433.0002: input,hidraw1: USB HID v1.01 Mouse [  mini keyboard] on usb-fd8c0000.usb-1/input1
[  358.455095] usb usb4-port1: debounce total 100ms stable 100ms status 0x100
[  358.455209] hub 4-0:1.0: hub_suspend
[  358.455285] usb usb4: bus auto-suspend, wakeup 1
^C
root@quartz64a:~# lsusb -tv
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ohci-platform/1p, 12M
    ID 1d6b:0001 Linux Foundation 1.1 root hub
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ohci-platform/1p, 12M
    ID 1d6b:0001 Linux Foundation 1.1 root hub
    |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        ID 1997:2433 Shenzhen Riitek Technology Co., Ltd wireless mini keyboard with touchpad
    |__ Port 001: Dev 002, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        ID 1997:2433 Shenzhen Riitek Technology Co., Ltd wireless mini keyboard with touchpad
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-platform/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-platform/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
```

HTH,
  Diederik

Re: Track down EHCI and companion errors on rk3xxx systems

[Alan Stern]

On Tue, Jan 13, 2026 at 10:15:59PM +0100, Diederik de Haas wrote:
> I'm now wondering if there's something wrong with the Quartz64-A ...
> I already thought that it took way too long before I got a login prompt.
> 
> In my first attempt I noticed I did NOT have the "Warning! ehci_hcd
> should always be loaded before uhci_hcd and ohci_hcd, not after"
> It took so long I forgot to keep counting, but most of all I forgot the
> dynamic debug command, so I tried again ...
> 
> This time I did the dynamic debug command and the above "Warning!" was
> present. Plugged in the keyboard adapter, started a stopwatch on my
> phone and monitored the ``dmesg -W`` for any changes ...
> 
> It took slightly more then a MINUTE for anything to appear in dmesg :-O
> 
> ```
> root@quartz64a:~# dmesg -W
> [  357.343890] usb usb4: usb wakeup-resume
> [  357.343970] usb usb4: usb auto-resume
> [  357.344023] hub 4-0:1.0: hub_resume
> [  357.344243] usb usb4-port1: status 0501 change 0001
> [  357.446845] hub 4-0:1.0: state 7 ports 1 chg 0002 evt 0000
> [  357.447094] usb usb4-port1: status 0501, change 0000, 480 Mb/s

That's the EHCI controller detecting the new connection.  If this took 
more than a minute to happen then something is wrong with the EHCI 
controller or its associated hardware.  Or possibly with the way the 
computer handles wakeup signals.

> [  357.510889] hub 4-0:1.0: port_wait_reset: err = -16
> [  357.510909] usb usb2: usb wakeup-resume
> [  357.510956] usb usb4-port1: not enabled, trying reset again...
> [  357.510980] usb usb2: usb auto-resume
> [  357.586708] hub 2-0:1.0: hub_resume
> [  357.586936] usb usb2-port1: status 0101 change 0001
> [  357.690841] hub 2-0:1.0: state 7 ports 1 chg 0002 evt 0000
> [  357.691090] usb usb2-port1: status 0101, change 0000, 12 Mb/s
> [  357.714843] usb usb4-port1: not reset yet, waiting 200ms
> [  357.874717] usb 2-1: new full-speed USB device number 2 using ohci-platform

This usb2 stuff is the OHCI controller reacting to the new connection, 
after the connection was switched from the EHCI controller to OHCI.

> [  357.918838] usb usb4-port1: not reset yet, waiting 200ms

These messages aren't supposed to occur.  The EHCI controller is 
supposed to realize that there is no device connected to it any more, 
now that the connection has been switched over to the OHCI controller.

> [  358.082679] usb 2-1: ep0 maxpacket = 32
> [  358.087855] usb 2-1: skipped 1 descriptor after interface
> [  358.087926] usb 2-1: skipped 1 descriptor after interface
> [  358.089798] usb 2-1: default language 0x0409
> [  358.093839] usb 2-1: udev 2, busnum 2, minor = 129
> [  358.093904] usb 2-1: New USB device found, idVendor=1997, idProduct=2433, bcdDevice= 1.06
> [  358.094803] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [  358.095481] usb 2-1: Product: mini keyboard
> [  358.095889] usb 2-1: Manufacturer:
> [  358.097629] usb 2-1: usb_probe_device
> [  358.097691] usb 2-1: configuration #1 chosen from 1 choice
> [  358.099335] usb 2-1: adding 2-1:1.0 (config #1, interface 0)
> [  358.100603] usb 2-1: adding 2-1:1.1 (config #1, interface 1)
> [  358.101371] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
> [  358.126129] usb usb4-port1: not reset yet, waiting 200ms
> [  358.203797] hid: raw HID events driver (C) Jiri Kosina
> [  358.227055] usbhid 2-1:1.0: usb_probe_interface
> [  358.227080] usbhid 2-1:1.0: usb_probe_interface - got id
> [  358.231307] usbhid 2-1:1.1: usb_probe_interface
> [  358.231331] usbhid 2-1:1.1: usb_probe_interface - got id
> [  358.236333] usbcore: registered new interface driver usbhid
> [  358.236850] usbhid: USB HID core driver
> [  358.267050] input:   mini keyboard as /devices/platform/fd8c0000.usb/usb2/2-1/2-1:1.0/0003:1997:2433.0001/input/input2
> [  358.326722] usb usb4-port1: not reset yet, waiting 200ms
> [  358.326992] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002
> [  358.327125] usb usb4-port1: status 0100, change 0001, 12 Mb/s

And here is where the EHCI controller finally reported that nothing was 
connected.

It certainly looks like the EHCI controller isn't working right.  Just 
as a test, you can try unloading the ehci-hcd module, together with any 
modules depending on it, before you plug in the keyboard adapter.  It 
would be interesting to see if that makes any difference.

Another thing to try is to see if disabling EHCI runtime suspend changes 
anything.  To do this, don't remove any modules.  Instead, before 
plugging in the keyboard adapter, do:

	echo on >/sys/bus/usb/devices/usb4/power/control

Alan Stern

Re: Track down EHCI and companion errors on rk3xxx systems

[Diederik de Haas]

On Wed Jan 14, 2026 at 4:20 AM CET, Alan Stern wrote:
> On Tue, Jan 13, 2026 at 10:15:59PM +0100, Diederik de Haas wrote:
>> I'm now wondering if there's something wrong with the Quartz64-A ...
>> I already thought that it took way too long before I got a login prompt.
>> 
>> In my first attempt I noticed I did NOT have the "Warning! ehci_hcd
>> should always be loaded before uhci_hcd and ohci_hcd, not after"
>> It took so long I forgot to keep counting, but most of all I forgot the
>> dynamic debug command, so I tried again ...

I know it didn't result in the requested dmesg log, but isn't it
significant I had the problem *without* the warning? IOW: the connection
(correlation or causation) I thought there was, (possibly) isn't there?
 
>> This time I did the dynamic debug command and the above "Warning!" was
>> present. Plugged in the keyboard adapter, started a stopwatch on my
>> phone and monitored the ``dmesg -W`` for any changes ...
>> 
>> It took slightly more then a MINUTE for anything to appear in dmesg :-O
>> 
>> ```
>> root@quartz64a:~# dmesg -W
>> [  357.343890] usb usb4: usb wakeup-resume
>> [  357.343970] usb usb4: usb auto-resume
>> [  357.344023] hub 4-0:1.0: hub_resume
>> [  357.344243] usb usb4-port1: status 0501 change 0001
>> [  357.446845] hub 4-0:1.0: state 7 ports 1 chg 0002 evt 0000
>> [  357.447094] usb usb4-port1: status 0501, change 0000, 480 Mb/s
>
> That's the EHCI controller detecting the new connection.  If this took 
> more than a minute to happen then something is wrong with the EHCI 
> controller or its associated hardware.  Or possibly with the way the 
> computer handles wakeup signals.

This was with a 6.19-rc5 based kernel (with mostly media patches added
on top) and on a Rock64 (rk3328) I got a whole bunch of these warnings:

WARNING: drivers/gpio/gpiolib.c:3523 at gpiod_get_value+0x64/0x98, CPU#0: swapper/0/0

log of a few of them:
https://paste.sr.ht/~diederik/154c5023a3a50d77f1da2195e7bb9a96f6a88555

and I suspect (but don't KNOW!) this commit is relevant:
20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")

So I'll switch to a 6.19-rc4 based kernel, which is mostly the same,
but doesn't have that commit.

FWIW: I'd expect to see sth in dmesg within a second of me plugging sth
in, so I was surprised by you calling '30 secs' a short period.

I'll re-do the test and the addional tests you requested, but right now
I need to focus on some other things, so may take a few days.

Cheers,
  Diederik

>> [  357.510889] hub 4-0:1.0: port_wait_reset: err = -16
>> [  357.510909] usb usb2: usb wakeup-resume
>> [  357.510956] usb usb4-port1: not enabled, trying reset again...
>> [  357.510980] usb usb2: usb auto-resume
>> [  357.586708] hub 2-0:1.0: hub_resume
>> [  357.586936] usb usb2-port1: status 0101 change 0001
>> [  357.690841] hub 2-0:1.0: state 7 ports 1 chg 0002 evt 0000
>> [  357.691090] usb usb2-port1: status 0101, change 0000, 12 Mb/s
>> [  357.714843] usb usb4-port1: not reset yet, waiting 200ms
>> [  357.874717] usb 2-1: new full-speed USB device number 2 using ohci-platform
>
> This usb2 stuff is the OHCI controller reacting to the new connection, 
> after the connection was switched from the EHCI controller to OHCI.
>
>> [  357.918838] usb usb4-port1: not reset yet, waiting 200ms
>
> These messages aren't supposed to occur.  The EHCI controller is 
> supposed to realize that there is no device connected to it any more, 
> now that the connection has been switched over to the OHCI controller.
>
>> [  358.082679] usb 2-1: ep0 maxpacket = 32
>> [  358.087855] usb 2-1: skipped 1 descriptor after interface
>> [  358.087926] usb 2-1: skipped 1 descriptor after interface
>> [  358.089798] usb 2-1: default language 0x0409
>> [  358.093839] usb 2-1: udev 2, busnum 2, minor = 129
>> [  358.093904] usb 2-1: New USB device found, idVendor=1997, idProduct=2433, bcdDevice= 1.06
>> [  358.094803] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>> [  358.095481] usb 2-1: Product: mini keyboard
>> [  358.095889] usb 2-1: Manufacturer:
>> [  358.097629] usb 2-1: usb_probe_device
>> [  358.097691] usb 2-1: configuration #1 chosen from 1 choice
>> [  358.099335] usb 2-1: adding 2-1:1.0 (config #1, interface 0)
>> [  358.100603] usb 2-1: adding 2-1:1.1 (config #1, interface 1)
>> [  358.101371] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
>> [  358.126129] usb usb4-port1: not reset yet, waiting 200ms
>> [  358.203797] hid: raw HID events driver (C) Jiri Kosina
>> [  358.227055] usbhid 2-1:1.0: usb_probe_interface
>> [  358.227080] usbhid 2-1:1.0: usb_probe_interface - got id
>> [  358.231307] usbhid 2-1:1.1: usb_probe_interface
>> [  358.231331] usbhid 2-1:1.1: usb_probe_interface - got id
>> [  358.236333] usbcore: registered new interface driver usbhid
>> [  358.236850] usbhid: USB HID core driver
>> [  358.267050] input:   mini keyboard as /devices/platform/fd8c0000.usb/usb2/2-1/2-1:1.0/0003:1997:2433.0001/input/input2
>> [  358.326722] usb usb4-port1: not reset yet, waiting 200ms
>> [  358.326992] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002
>> [  358.327125] usb usb4-port1: status 0100, change 0001, 12 Mb/s
>
> And here is where the EHCI controller finally reported that nothing was 
> connected.
>
> It certainly looks like the EHCI controller isn't working right.  Just 
> as a test, you can try unloading the ehci-hcd module, together with any 
> modules depending on it, before you plug in the keyboard adapter.  It 
> would be interesting to see if that makes any difference.
>
> Another thing to try is to see if disabling EHCI runtime suspend changes 
> anything.  To do this, don't remove any modules.  Instead, before 
> plugging in the keyboard adapter, do:
>
> 	echo on >/sys/bus/usb/devices/usb4/power/control
>
> Alan Stern
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: Track down EHCI and companion errors on rk3xxx systems

[Alan Stern]

On Wed, Jan 14, 2026 at 03:59:28PM +0100, Diederik de Haas wrote:
> On Wed Jan 14, 2026 at 4:20 AM CET, Alan Stern wrote:
> > On Tue, Jan 13, 2026 at 10:15:59PM +0100, Diederik de Haas wrote:
> >> I'm now wondering if there's something wrong with the Quartz64-A ...
> >> I already thought that it took way too long before I got a login prompt.
> >> 
> >> In my first attempt I noticed I did NOT have the "Warning! ehci_hcd
> >> should always be loaded before uhci_hcd and ohci_hcd, not after"
> >> It took so long I forgot to keep counting, but most of all I forgot the
> >> dynamic debug command, so I tried again ...
> 
> I know it didn't result in the requested dmesg log, but isn't it
> significant I had the problem *without* the warning? IOW: the connection
> (correlation or causation) I thought there was, (possibly) isn't there?

I told you much earlier in this discussion that the warning message was 
unlikely to be connected with the problem you were seeing.

> This was with a 6.19-rc5 based kernel (with mostly media patches added
> on top) and on a Rock64 (rk3328) I got a whole bunch of these warnings:
> 
> WARNING: drivers/gpio/gpiolib.c:3523 at gpiod_get_value+0x64/0x98, CPU#0: swapper/0/0
> 
> log of a few of them:
> https://paste.sr.ht/~diederik/154c5023a3a50d77f1da2195e7bb9a96f6a88555
> 
> and I suspect (but don't KNOW!) this commit is relevant:
> 20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")
> 
> So I'll switch to a 6.19-rc4 based kernel, which is mostly the same,
> but doesn't have that commit.

It's very hard to tell whether this is at all connected to your problem.  
It could easily be a totally separate issue.

> FWIW: I'd expect to see sth in dmesg within a second of me plugging sth
> in, so I was surprised by you calling '30 secs' a short period.

30 seconds was a generous estimate on my part; 5 seconds probably would 
have been enough.  However, the USB subsystem does include some timeouts 
that are 2 seconds long and others that are 5 seconds long, and some of 
these timeouts are inside retry loops.  So a 30-second wait isn't 
unreasonable.

Alan Stern

Re: Track down EHCI and companion errors on rk3xxx systems

[Diederik de Haas]

On Wed Jan 14, 2026 at 4:19 PM CET, Alan Stern wrote:
> On Wed, Jan 14, 2026 at 03:59:28PM +0100, Diederik de Haas wrote:
>> On Wed Jan 14, 2026 at 4:20 AM CET, Alan Stern wrote:
>> > On Tue, Jan 13, 2026 at 10:15:59PM +0100, Diederik de Haas wrote:
>> >> I'm now wondering if there's something wrong with the Quartz64-A ...
>> >> I already thought that it took way too long before I got a login prompt.
>> >> 
>> >> In my first attempt I noticed I did NOT have the "Warning! ehci_hcd
>> >> should always be loaded before uhci_hcd and ohci_hcd, not after"
>> >> It took so long I forgot to keep counting, but most of all I forgot the
>> >> dynamic debug command, so I tried again ...
>> 
>> I know it didn't result in the requested dmesg log, but isn't it
>> significant I had the problem *without* the warning? IOW: the connection
>> (correlation or causation) I thought there was, (possibly) isn't there?
>
> I told you much earlier in this discussion that the warning message was 
> unlikely to be connected with the problem you were seeing.

Yep, you did :-)
For me, this was the first time I actively noticed *this* combo.
And I know far less (about this subject) then you do, so things may take
more time to land with me and/or I don't recognize the significance of
certain messages, which may be obvious to you.

>> This was with a 6.19-rc5 based kernel (with mostly media patches added
>> on top) and on a Rock64 (rk3328) I got a whole bunch of these warnings:
>> 
>> WARNING: drivers/gpio/gpiolib.c:3523 at gpiod_get_value+0x64/0x98, CPU#0: swapper/0/0
>> 
>> log of a few of them:
>> https://paste.sr.ht/~diederik/154c5023a3a50d77f1da2195e7bb9a96f6a88555
>> 
>> and I suspect (but don't KNOW!) this commit is relevant:
>> 20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")
>> 
>> So I'll switch to a 6.19-rc4 based kernel, which is mostly the same,
>> but doesn't have that commit.
>
> It's very hard to tell whether this is at all connected to your problem.  
> It could easily be a totally separate issue.

True and it may just be in my head. But I'd rather exclude a *possible*
factor then having the possibility that it may have an/some effect.
AFA*I*K, all the RK33xx/RK35xx devices uses the same USB2 'stuff', so
while I didn't see it with the Q64-A, I'd rather not take the chance.

>> FWIW: I'd expect to see sth in dmesg within a second of me plugging sth
>> in, so I was surprised by you calling '30 secs' a short period.
>
> 30 seconds was a generous estimate on my part; 5 seconds probably would 
> have been enough.  However, the USB subsystem does include some timeouts 
> that are 2 seconds long and others that are 5 seconds long, and some of 
> these timeouts are inside retry loops.  So a 30-second wait isn't 
> unreasonable.

But that's all processing times *after* it detected a USB device?
The thing that really surprised me that it took the kernel a minute to
detect anything had happened at all. If that had taken 30 secs, that
would've surprised me too. If it then took some time to make the device
fully available and operational, sure, fine.

Cheers,
  Diederik

Re: Track down EHCI and companion errors on rk3xxx systems

[Alan Stern]

On Wed, Jan 14, 2026 at 04:41:13PM +0100, Diederik de Haas wrote:
> On Wed Jan 14, 2026 at 4:19 PM CET, Alan Stern wrote:
> > 30 seconds was a generous estimate on my part; 5 seconds probably would 
> > have been enough.  However, the USB subsystem does include some timeouts 
> > that are 2 seconds long and others that are 5 seconds long, and some of 
> > these timeouts are inside retry loops.  So a 30-second wait isn't 
> > unreasonable.
> 
> But that's all processing times *after* it detected a USB device?
> The thing that really surprised me that it took the kernel a minute to
> detect anything had happened at all. If that had taken 30 secs, that
> would've surprised me too. If it then took some time to make the device
> fully available and operational, sure, fine.

Well yes, I wanted you to wait long enough for all the initial 
processing (making the device fully available and operational) to finish 
up.

However, I agree: 30 seconds is _much_ longer than it should take to 
detect a newly plugged-in device.  It should take less than one second.  
One possibility is that something involved in waking up the EHCI host 
controller from its runtime suspend may have caused the delay -- that's 
why I asked you to try turning off the controller's runtime suspend. 

Also, I'm not at all familiar with the particular hardware used by your 
platform for receiving wakeup signals.  It's possible that a GPIO 
responsible for this wasn't working right and that's why you were 
getting all those warning messages.  Another reason for wanting to know 
what will happen if you take suspends and wakeups out of the picture.

Alan Stern

Re: Track down EHCI and companion errors on rk3xxx systems

[Diederik de Haas]

On Wed Jan 14, 2026 at 5:07 PM CET, Alan Stern wrote:
> However, I agree: 30 seconds is _much_ longer than it should take to 
> detect a newly plugged-in device.  It should take less than one second.  
> One possibility is that something involved in waking up the EHCI host 
> controller from its runtime suspend may have caused the delay -- that's 
> why I asked you to try turning off the controller's runtime suspend. 

It may be completely natural, but I was surprised runtime suspend was
involved at all. So I'll definitely do a test by turning it off.

> Also, I'm not at all familiar with the particular hardware used by your 
> platform for receiving wakeup signals.  It's possible that a GPIO 
> responsible for this wasn't working right and that's why you were 
> getting all those warning messages.  Another reason for wanting to know 
> what will happen if you take suspends and wakeups out of the picture.

I think GPIO is involved with wakeup signals ... sometimes at least.
I added the linux-rockchip ML precisely because I (strongly) suspect
there is Rockchip specific part to all this.

Cheers,
  Diederik

PS: I very much appreciate you taking the time for this 'debugging'
session :-)