linux-kernel - Re: [regression] usb: sometimes dead keyboard after boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 30 Aug 2008 16:40:20 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Kernel development list <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>
Subject: Re: [regression] usb: sometimes dead keyboard after boot

On Saturday 30 August 2008, Alan Stern wrote:
> On Fri, 29 Aug 2008, Alan Stern wrote:
> > > Does this sound at all logical and feasible?
> >
> > The first proposal is feasible; I can write a patch to implement it.
> > How much it will end up helping anything isn't clear, though.
>
> Here's the promised patch.  Be warned, I haven't tested it at all.

The patch seems to do exactly what I was looking for! Details further 
down, but first some other comments.

My first boot with your patch was with brltty still enabled. The log 
showed the right result, but I wanted to get a cleaner log without all 
the USB suspend/resume noise caused by brltty. So I disabled brltty's 
init script and rebooted.

This gave a totally unexpected result: ehci now got loaded and initialized 
_before_ uhci which of course avoids the problem altogether (see attached 
log: dmesg_ehci-first). So apparently brltty's init script was 
responsible not only for the suspend/resume noise, but also influenced 
the load order of the two USB drivers.
And apparently when things are left alone ehci _will_ be loaded before 
uhci, but that does not match what you described in earlier mails as it 
means the PCI bus order isn't followed. Confusing...

Anyway, this meant that to test your patch I had to try to get uhci to 
load first again. This turned out to be simple: just adding uhci_hcd 
in /etc/modules did the trick. The result is in dmesg_uhci-first.

That log shows what was desired, at least 3-1 and 4-1 get disconnected 
cleanly and I get no error messages to the console. Yay!

I added two extra printk's around the usb_wait_for_khubd_idle call to show 
the exact effect of the wait (look for "khubd_idle" in two messages). 
These seem to show what was wanted: both keyboard and mouse are detected 
during the wait.

But it also shows a few events on bus 3 and 4 that happen after I get 
khubd_idle that seem to indicate the probe on that bus is not completely 
finished and that could maybe still cause "problems". But maybe I'm just 
reading it wrong and those events are part of the lead up to the 
disconnects for the hand-off.

Anyway, I'm quite happy with the result, so:
Tested-by: Frans Pop <elendil@...net.nl>

Last note FYI. I had another case of "dead keyboard" this morning, again 
with the "reset low speed USB device" message in the log. Unfortunately 
this was before I enabled USB debugging (and obviously before I had 
applied the patch).
I will now revert the patch and keep USB debugging enabled to see if I can 
catch this bug properly. I'll send the debug log when I do.

Cheers,
FJP

View attachment "dmesg_ehci-first" of type "text/plain" (42833 bytes)

View attachment "dmesg_uhci-first" of type "text/plain" (46527 bytes)