Bug 133989 - [usb8] [ukbd] USB keyboard dead at mountroot> prompt
Summary: [usb8] [ukbd] USB keyboard dead at mountroot> prompt
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-25 09:10 UTC by emikulic
Modified: 2018-05-28 19:49 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description emikulic 2009-04-25 09:10:02 UTC
At boot time, if I get dropped to the mountroot> prompt due to e.g.
screwing up vfs.root.mountfrom, my USB keyboard doesn't respond at all,
and I can't do anything but hard-reset my computer.

emax's r191164 makes no difference ("Prevent atkbd(4) interrupt handler
from calling keyboard callback function when polled mode is enabled.")
Kernels before and after that patch behave the same.

Removing kbdmux also has no effect.

Removing all of USB2 from the kernel config makes the keyboard work at
the mountroot> prompt (BIOS emulation?)

In a healthy boot, ukbd0 doesn't get recognized until -after- the root
FS is mounted and /sbin/init starts.  At Hans Petter Selasky's
suggestion, I added a pause() to cngetc():

--- a/sys/kern/kern_cons.c
+++ b/sys/kern/kern_cons.c
@@ -353,7 +353,7 @@ cngetc(void)
        if (cn_mute)
                return (-1);
        while ((c = cncheckc()) == -1)
-               ;
+               pause("WAIT", hz/10);
        if (c == '\r')
                c = '\n';               /* console input is always ICRNL */
        return (c);

With this change, a few seconds after the mountroot> prompt is
displayed, the USB keyboard is detected (and added to kbdmux) and I can
hit scroll lock and scroll up and down, and even hit Ctrl+PrtScr to
break into debugger (which then gets into an infinite loop of panics),
but I can't get keypresses through to the mountroot> prompt.

Giant is picked up in start_init() and I'm pretty sure is held in
cngetc().  I've tried dropping it around the pause() above but that made
no difference.

How-To-Repeat: On a system with only a USB keyboard, at the /boot/loader prompt,
set vfs.root.mountfrom="ufs:something/silly" and boot.
Comment 1 Andriy Gapon 2009-05-28 16:22:29 UTC
"Me too" here.
I have a "legacy-free" system with no PS/2 ports, so I have no choice but use USB
keyboard and mouse. And because of this issue I am afraid that I could into a
situation where I'd be stuck at mountroot prompt with no input capability. LiveCD
would help, but...

What's interesting is that with stable/7 my mouse is detected way before mountroot
prompt. This happens during "cold explore" phase, I think. But the keyboard is
usually found after mountroot phase, but sometimes, very infrequently, it happens
before.
Typical dmesg:
[various stuff]
[more usb messages]
usb5: <UHCI (generic) USB controller> on uhci4
usb5: USB revision 1.0
uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
uhub5: 2 ports with 2 removable, self powered
uhci5: <UHCI (generic) USB controller> port 0x2040-0x205f irq 18 at device 29.2 on
pci0
uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040
uhci5: [GIANT-LOCKED]
uhci5: [ITHREAD]
usb6: <UHCI (generic) USB controller> on uhci5
usb6: USB revision 1.0
uhub6: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
uhub6: 2 ports with 2 removable, self powered
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xe0425800-0xe0425bff irq 23 at
device 29.7 on pci0
ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0425800
ehci1: [GIANT-LOCKED]
ehci1: [ITHREAD]
usb7: EHCI version 1.0
usb7: companion controllers, 2 ports each: usb4 usb5 usb6
usb7: <EHCI (generic) USB 2.0 controller> on ehci1
usb7: USB revision 2.0
uhub7: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb7
uhub7: 6 ports with 6 removable, self powered
...
[more stuff]
isa_probe_children: probing PnP devices
ums0: <Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/24.30, addr 2> on uhub2
ums0: 8 buttons and Z dir.
...
[more stuff]
Trying to mount root from zfs:tank/root
ukbd0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 2> on uhub6
kbd1 at ukbd0
kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000
uhid0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 2> on uhub6

But in head (with new usb stack, of course) I see that USB mouse and keyboard are
discovered about the same time and so far it is always after mountroot phase:
Typical (verbose) dmesg:
[various stuff]
[more usb controllers]
usbus5: <Intel 82801I (ICH9) USB controller> on uhci4
uhci5: <Intel 82801I (ICH9) USB controller> port 0x2040-0x205f irq 18 at device
29.2 on pci0
uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040
uhci5: [MPSAFE]
uhci5: [ITHREAD]
uhci5: LegSup = 0x0f10
usbus6: <Intel 82801I (ICH9) USB controller> on uhci5
ehci1: <Intel 82801I (ICH9) USB 2.0 controller> mem 0xe0425800-0xe0425bff irq 23
at device 29.7 on pci0
ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0425800
ehci1: [MPSAFE]
ehci1: [ITHREAD]
usbus7: EHCI version 1.0
usbus7: <Intel 82801I (ICH9) USB 2.0 controller> on ehci1
...
[more stuff, interrupts enabled phase]
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 480Mbps High Speed USB v2.0
usbus4: 12Mbps Full Speed USB v1.0
usbus5: 12Mbps Full Speed USB v1.0
usbus6: 12Mbps Full Speed USB v1.0
usbus7: 480Mbps High Speed USB v2.0
ugen0.1: <Intel> at usbus0
uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <Intel> at usbus1
uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
ugen2.1: <Intel> at usbus2
uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
ugen3.1: <Intel> at usbus3
uhub3: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3
ugen4.1: <Intel> at usbus4
uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus4
ugen5.1: <Intel> at usbus5
uhub5: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus5
ugen6.1: <Intel> at usbus6
uhub6: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus6
ugen7.1: <Intel> at usbus7
uhub7: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus7
...
[more stuff]
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub4: 2 ports with 2 removable, self powered
uhub5: 2 ports with 2 removable, self powered
uhub6: 2 ports with 2 removable, self powered
uhub3: 6 ports with 6 removable, self powered
uhub7: 6 ports with 6 removable, self powered
...
SMP: AP CPU #1 Launched!
...
Trying to mount root from zfs:pond/ROOT/original
start_init: trying /sbin/init
ugen2.2: <Logitech> at usbus2
ugen6.2: <CHESEN> at usbus6
ukbd0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 2> on usbus6
kbd2 at ukbd0
kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000
ums0: <Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/24.30, addr 2> on usbus2
ums0: 8 buttons and [XYZ] coordinates ID=0
uhid0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 2> on usbus6

I can provide full dmesgs, output of any tools, etc.

P.S.
please also see this thread about my investigation of this issue in stable/7:
http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026832.html

-- 
Andriy Gapon
Comment 2 teerapap.c 2010-04-23 08:55:22 UTC
I found same problem but with a virtual CD via IPMI. cd0 is detected after
mount root process so the system cannot boot automatically.
I found a workaround for this problem.
By setting kern.cam.scsi_delay="50000" in loader.conf .    you may increase
or decrease this delay up to your problem.
I'm not sure if it works for your keyboard or not.

-------------------------------
Cheers,
Teerapap Changwichukarn
http://www.teerapap.net
http://teerapap.blogspot.com
Comment 3 Eugene M. Zheganin 2011-05-12 05:27:27 UTC
8.2-RELEASE.  still there.
furthermore, the number of usb-only server platform is increasing.
Comment 4 Benedict Reuschling freebsd_committer 2011-11-17 12:57:26 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The problem is still there on 9.0-RC1. I tried setting
kern.cam.scsi_delay as suggested in this thread:

http://freebsd.1045724.n5.nabble.com/USB-keyboard-problems-at-mountroot-td4676606.html

I used the following values: 5, 20, 100. Unfortunately, none had the
desired effect, the USB keyboard still does not work. I would be willing
to help test any patches that might help resolve this issue.

Cheers

Benedict Reuschling
FreeBSD Documentation Committer

The FreeBSD Documentation Project
FreeBSD German Documentation Project - https://doc.bsdgroup.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7FBLYACgkQTSZQLkqBk0gjYgCbBm3WfwYrG1jxKr8HaWJRcreu
c4UAn2lwOrGhEFyX17wu3ch3YO8gKQA1
=Z9Gl
-----END PGP SIGNATURE-----
Comment 5 fullermd 2012-08-18 14:24:36 UTC
One way to slide past it is that the mountroot prompt accepts a '.' to
spin around the kernel for a second or so to complete various
background tasks.  It's meant to allow finishing probing drives etc,
but on systems I've tried it also works for letting the USB stack pick
up the keyboard.

Of course, using this as a workaround is severely diluted by the fact
that you need a working keyboard to run the hack to get the keyboard
working   ;)  But something in the spirit of the original patch would
be a real nice plus; this bites me on a regular (rare, but still
regular) basis...


-- 
Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
Comment 6 Enji Cooper freebsd_committer 2014-07-28 08:34:59 UTC
+1. This is still an issue on my ASUS P6T WS-PRO motherboard (I don't have access to a PS/2 converter or keyboard).
Comment 7 Enji Cooper freebsd_committer 2014-07-28 08:35:52 UTC
(In reply to yaneurabeya from comment #6)
> +1. This is still an issue on my ASUS P6T WS-PRO motherboard (I don't have
> access to a PS/2 converter or keyboard).

Forgot to mention that this issue is occurring on 9.x (9.2-RELEASE-p10/9.3-RELEASE).
Comment 8 Enji Cooper freebsd_committer 2014-08-09 20:25:17 UTC
The real problem in my case (and in general probably) is that the SYSINIT/probe order for ukbd is too late. Setting the kern.cam.boot_delay tunable to 30000 (30 seconds) in loader gave ukbd enough time to probe and attach my USB keyboard before the system panicked at the mountroot prompt.
Comment 9 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:15 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.