Date: Wed, 5 Nov 2008 08:01:59 -0800 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: ukbd attachment and root mount Message-ID: <20081105160159.GA14488@icarus.home.lan> In-Reply-To: <4911BA93.9030006@icyb.net.ua> References: <4911BA93.9030006@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 05, 2008 at 05:24:03PM +0200, Andriy Gapon wrote: > System is FreeBSD 7.1-BETA2 amd64. > > Looking through my dmesg I see that relative order of ukbd attachment > and root mounting is not deterministic. Sometime keyboard is attached > first, sometimes root filesystem is mounted first. Quite more often root > is mounted first, though. > Example (with GENERIC kernel): > Nov 3 15:40:54 kernel: Trying to mount root from ufs:/dev/mirror/bootgm > Nov 3 15:40:54 kernel: GEOM_LABEL: Label ufs/bootfs removed. > Nov 3 15:40:54 kernel: GEOM_LABEL: Label for provider mirror/bootgm is > ufs/bootfs. > Nov 3 15:40:54 kernel: GEOM_LABEL: Label ufs/bootfs removed. > Nov 3 15:40:54 kernel: ukbd0: <CHESEN USB Keyboard, class 0/0, rev > 1.10/1.10, addr 3> on uhub2 > Nov 3 15:40:54 kernel: kbd2 at ukbd0 > Nov 3 15:40:54 kernel: uhid0: <CHESEN USB Keyboard, class 0/0, rev > 1.10/1.10, addr 3> on uhub2 > > Another (with custom kernel, zfs root): > Nov 4 17:54:03 odyssey kernel: Trying to mount root from zfs:tank/root > Nov 4 17:54:03 odyssey kernel: ukbd0: <CHESEN USB Keyboard, class 0/0, > rev 1.10/1.10, addr 3> on uhub2 > Nov 4 17:54:03 odyssey kernel: kbd2 at ukbd0 > Nov 4 17:54:03 odyssey kernel: kbd2: ukbd0, generic (0), config:0x0, > flags:0x3d0000 > Nov 4 17:54:03 odyssey kernel: uhid0: <CHESEN USB Keyboard, class 0/0, > rev 1.10/1.10, addr 3> on uhub2 I'm not understanding why the "order" matters per se, but I believe you might explain how it impacts you below. > I have a legacy-free system (no PS/2 ports, only USB) and I wanted to > try a kernel without atkbd and psm (with ums, ukbd, kbdmux), but was > bitten hard when I made a mistake and kernel could not find/mount root > filesystem. > > So I stuck at mountroot prompt without a keyboard to enter anything. > This was repeatable about 10 times after which I resorted to live cd. I've seen this problem myself many times. In fact, on my FreeBSD box at home, I ran into this last night. That system uses a USB keyboard, but has PS/2 ports if need be. This motherboard has PS/2 emulation for USB devices (often called "USB Legacy" in BIOSes), and that option was enabled; this, of course, allows me to use the USB keyboard in MS-DOS, boot0, and boot2/loader. I also had kbdmux(4) disabled via hint.kbdmux.0.disable="1" in loader.conf, but left atkbd/atkbdc in my kernel. (The reason I disabled kbdmux was because of the known 2-or-3-second-delay problem when switching virtual consoles) I encountered a situation last night where I needed to specify the root filesystem at the mountroot prompt, but typing didn't work. I was forced to plug in a PS/2 keyboard. I could reproduce this problem every time. I found that by re-enabling kbdmux (removing the "hint" entry), and instead disabling atkbd/atkbdc via a "hint" entry, solved this problem. So, let's recap the scenario, because people might be confused by what I'm describing: Configuration A --------------- * USB Legacy enabled in BIOS * Kernel config -- includes atkbd, atkbdc, kbdmux, and USB * loader.conf -- hint.kbdmux.0.disable="1" * Able to type in MS-DOS, boot0, boot2/loader * Able to type in multi-user mode * No delays when switching virtual consoles in multi-user mode * Unable to type at mountroot prompt Configuration B --------------- * USB Legacy enabled in BIOS * Kernel config -- includes atkbd, atkbdc, kbdmux, and USB * loader.conf -- hint.atkbd.0.disable="1" * loader.conf -- hint.atkbdc.0.disable="1" * Able to type in MS-DOS, boot0, boot2/loader * Able to type in multi-user mode * No delays when switching virtual consoles in multi-user mode * Able to type at mountroot prompt Draw your own conclusions. (NOTE: I have no idea if hint.atkbdc.0.disabled="1" actually does anything, but I assume hint.atkbd.0.disabled="1" does in fact do what I expect) > Since then I put back atkbdc into my kernel. I guess BIOS or USB > hardware emulate AT or PS/2 keyboard, so the USB keyboard works before > the driver attaches. Correct; "USB Legacy" will do this. "USB Legacy" will work properly up until the point the kernel loads (but BEFORE the USB stack loads). Once the USB stack loads, ukbd or kbdmux takes over. > I guess I need such emulation e.g. for loader or boot0 configuration. > But I guess I don't have to have atkbd driver in kernel. I would recommend not messing with the kernel at all for this. You can disable atkbd and kbdmux via loader.conf "hint" lines. The same goes for psm, AFAIK. > I wonder why behavior is non-deterministic, why ukbd is "99%" attached > after mount root, and what can be done about this. I'm not sure what to say here. But I will say that this situation is quite common, and makes doing *any* sort of administration on FreeBSD difficult -- look at my above situation. Had my motherboard lacked PS/2 ports, I would've been forced to hard reset the system. This is simply unacceptable. I don't know how to solve the problem, I don't know how to contribute code or fixes to help, and I don't know what users can do about it. The only thing I've found that "helps" is what I provided above. I want to help more, but I can't due to lack of knowledge -- and most users will be in this boat. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081105160159.GA14488>