Re: ukbd attachment and root mount
- From: Jeremy Chadwick <koitsu@xxxxxxxxxxx>
- Date: Wed, 5 Nov 2008 08:01:59 -0800
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 |
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: ukbd attachment and root mount
- From: Andriy Gapon
- Re: ukbd attachment and root mount
- References:
- ukbd attachment and root mount
- From: Andriy Gapon
- ukbd attachment and root mount
- Prev by Date: Using r/o root with amd(8)-mounted file systems
- Next by Date: Re: Atheros AR5141
- Previous by thread: ukbd attachment and root mount
- Next by thread: Re: ukbd attachment and root mount
- Index(es):
Relevant Pages
|
