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