Bug 133989
| Summary: | [usb8] [ukbd] USB keyboard dead at mountroot> prompt | ||
|---|---|---|---|
| Product: | Base System | Reporter: | emikulic |
| Component: | usb | Assignee: | Bugmeister <bugmeister> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | hps, ngie, pi |
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
"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 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 8.2-RELEASE. still there. furthermore, the number of usb-only server platform is increasing. -----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----- 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. +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). (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). 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. 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. ^Triage: I'm sorry that this PR did not get addressed in a timely fashion. By now, the version that it was created against is long out of support. Please re-open if it is still a problem on a supported version. |
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.