Re: ukbd attachment and root mount
Andriy Gapon
> 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 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.
>
> 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. 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.
This turned out not to be a complete solution as it seems that there are
some quirks about legacy USB here, sometimes keyboard stops working even
at loader prompt (this is described in a different thread).
ukbd attachment still puzzles me a lot.
I look at some older dmesg, e.g. this 7.0-RELEASE one:
http://www.mavetju.org/mail/view_message.php?list=freebsd-usb&id=2709973
and see that ukbd attaches along with ums before mountroot.
I look at newer dmesg and I see that ums attaches at about the same time
as before but ukbd consistently attaches after mountroot.
I wonder what might cause such behavior and how to fix it.
I definitely would like to see ukbd attach before mountroot, I can debug
this issue, but need some hints on where to start.
--
Andriy Gapon
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
Nate Eldredge
> on 05/11/2008 17:24 Andriy Gapon said the following:
[...]
>> 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.
>>
>> 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. 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.
>
> This turned out not to be a complete solution as it seems that there are
> some quirks about legacy USB here, sometimes keyboard stops working even
> at loader prompt (this is described in a different thread).
>
> ukbd attachment still puzzles me a lot.
> I look at some older dmesg, e.g. this 7.0-RELEASE one:
> http://www.mavetju.org/mail/view_message.php?list=freebsd-usb&id=2709973
> and see that ukbd attaches along with ums before mountroot.
>
> I look at newer dmesg and I see that ums attaches at about the same time
> as before but ukbd consistently attaches after mountroot.
> I wonder what might cause such behavior and how to fix it.
> I definitely would like to see ukbd attach before mountroot, I can debug
> this issue, but need some hints on where to start.
I haven't been following this thread, and I'm pretty sleepy right now, so
sorry if this is irrelevant, but I had a somewhat similar problem that was
fixed by adding
hint.atkbd.0.flags="0x1"
to /boot/device.hints .
--
Nate Eldredge
neld...@math.ucsd.edu
Andriy Gapon
I can try this, but I think this wouldn't help for two reasons:
1. I already tried kernel without atkb at all
2. if ukbd driver is not attached then I don't see any way USB keyboard
would work in non-legacy way
Anyway I will try this, thank you.
--
Andriy Gapon
Jeremy Chadwick
To those reading, the above setting enables the following option:
bit 0 (FAIL_IF_NO_KBD)
By default the atkbd driver will install even if a keyboard is not
actually connected to the system. This option prevents the driver
from being installed in this situation.
> I can try this, but I think this wouldn't help for two reasons:
> 1. I already tried kernel without atkb at all
> 2. if ukbd driver is not attached then I don't see any way USB keyboard
> would work in non-legacy way
Regarding #2: at which stage? boot0/boot2/loader require an AT or PS/2
keyboard to work. None of these stages use ukbd(4) or anything -- there
is no kernel loaded at this point!! Meaning: if you have a USB keyboard,
your BIOS will need to have a "USB Legacy" option to cause it to act as
a PS/2 keyboard, for typing in boot0/boot2/loader to work.
Device hints are for kernel drivers, once the kernel is loaded.
--
| 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 |
Andriy Gapon
> On Wed, Nov 12, 2008 at 01:58:58PM +0200, Andriy Gapon wrote:
>> 2. if ukbd driver is not attached then I don't see any way USB keyboard
>> would work in non-legacy way
>
> Regarding #2: at which stage? boot0/boot2/loader require an AT or PS/2
> keyboard to work. None of these stages use ukbd(4) or anything -- there
> is no kernel loaded at this point!! Meaning: if you have a USB keyboard,
> your BIOS will need to have a "USB Legacy" option to cause it to act as
> a PS/2 keyboard, for typing in boot0/boot2/loader to work.
>
> Device hints are for kernel drivers, once the kernel is loaded.
Jeremy,
I understand all of this.
In subject line and earlier messages I say that I am interested in
mountroot prompt - the prompt where kernel can ask about what device to
use for root filesystem.
Essentially I would like kernel to recognize USB keyboard (and disable
all the legacy stuff if needed) before it prompts for the root device.
--
Andriy Gapon
Jeremy Chadwick
> on 12/11/2008 14:14 Jeremy Chadwick said the following:
> > On Wed, Nov 12, 2008 at 01:58:58PM +0200, Andriy Gapon wrote:
> [snip]
> >> 2. if ukbd driver is not attached then I don't see any way USB keyboard
> >> would work in non-legacy way
> >
> > Regarding #2: at which stage? boot0/boot2/loader require an AT or PS/2
> > keyboard to work. None of these stages use ukbd(4) or anything -- there
> > is no kernel loaded at this point!! Meaning: if you have a USB keyboard,
> > your BIOS will need to have a "USB Legacy" option to cause it to act as
> > a PS/2 keyboard, for typing in boot0/boot2/loader to work.
> >
> > Device hints are for kernel drivers, once the kernel is loaded.
>
> Jeremy,
>
> I understand all of this.
> In subject line and earlier messages I say that I am interested in
> mountroot prompt - the prompt where kernel can ask about what device to
> use for root filesystem.
> Essentially I would like kernel to recognize USB keyboard (and disable
> all the legacy stuff if needed) before it prompts for the root device.
I fully understand that fact. However, I don't see the logic in that
statement. You should be able to remove and add a keyboard at any time
and be able to type immediately. Meaning: I don't see why when the
keyboard recognition is performed (e.g. before printing mountroot or
after) matters. It should not. I think this is a red herring.
I've seen the problem where I have a fully functional USB keyboard in
boot0/boot2/loader and in multi-user, but when booting into single-user
or when getting a mountroot prompt, the keyboard does not function.
When the mountroot prompt is printed (before or after ukbd attached)
makes no difference for me in this scenario -- I tested it many times.
It's very possible that "something" (kbdcontrol?) is getting run only
during late stages of multi-user, which makes the keyboard work. But
prior to that "something" being run (but AFTER boot2/loader), the
keyboard is not truly usable.
I hope everyone here is also aware of that fact that not all keyboards
are created equal. Case in point (and this reason is exactly why I
am purchasing a native PS/2 keyboard, as USB4BSD doesn't work with
all USB keyboards right now):
http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000219.html
The bottom line:
FreeBSD cannot be reliably used with a USB keyboard in all
circumstances. And that is a very sad reality, because 90% of the
keyboards you find on the consumer and enterprise market are USB --
native PS/2 keyboards are now a scarcity.
Do not even for a minute tell me "buy a USB-to-PS2 adapter", because the
"green ones" that come with USB mice do not work with USB keyboards. I
have even bought a "purple" USB-to-PS2 keyboard adapter from Amazon,
specifically for this purpose, and it *does not work*. I found out
weeks later the adapters only work on CERTAIN models of USB keyboards,
depending upon how they're engineered.
What really needs to happen here should be obvious: we need some form of
inexpensive keyboard-only USB support in boot2/loader.
I would *love* to know how Linux and Windows solve this problem.
--
| 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 |
_______________________________________________
Andriy Gapon
> On Wed, Nov 12, 2008 at 02:20:41PM +0200, Andriy Gapon wrote:
>> on 12/11/2008 14:14 Jeremy Chadwick said the following:
>>> On Wed, Nov 12, 2008 at 01:58:58PM +0200, Andriy Gapon wrote:
>> [snip]
>>>> 2. if ukbd driver is not attached then I don't see any way USB keyboard
>>>> would work in non-legacy way
>>> Regarding #2: at which stage? boot0/boot2/loader require an AT or PS/2
>>> keyboard to work. None of these stages use ukbd(4) or anything -- there
>>> is no kernel loaded at this point!! Meaning: if you have a USB keyboard,
>>> your BIOS will need to have a "USB Legacy" option to cause it to act as
>>> a PS/2 keyboard, for typing in boot0/boot2/loader to work.
>>>
>>> Device hints are for kernel drivers, once the kernel is loaded.
>> Jeremy,
>>
>> I understand all of this.
>> In subject line and earlier messages I say that I am interested in
>> mountroot prompt - the prompt where kernel can ask about what device to
>> use for root filesystem.
>> Essentially I would like kernel to recognize USB keyboard (and disable
>> all the legacy stuff if needed) before it prompts for the root device.
>
> I fully understand that fact. However, I don't see the logic in that
> statement. You should be able to remove and add a keyboard at any time
> and be able to type immediately. Meaning: I don't see why when the
> keyboard recognition is performed (e.g. before printing mountroot or
> after) matters. It should not. I think this is a red herring.
I think that this does matter because keyboard recognition is performed
after the 'mounting from' log line *only if* root mount is done
automatically.
If there is an actual interactive prompt then recognition is not
performed, at least I do not see any relevant lines on the screen and I
am stuck at the prompt.
> I've seen the problem where I have a fully functional USB keyboard in
> boot0/boot2/loader
For me it even randomly dies at these stages.
I reported this in a different thread.
But this should not be related to kernel behavior.
>and in multi-user,
For me this always works.
> but when booting into single-user
For me this always works.
> or when getting a mountroot prompt, the keyboard does not function.
> When the mountroot prompt is printed (before or after ukbd attached)
> makes no difference for me in this scenario -- I tested it many times.
For me ukbd lines are never printed if I get actual interactive
mountroot prompt.
> It's very possible that "something" (kbdcontrol?) is getting run only
> during late stages of multi-user, which makes the keyboard work. But
> prior to that "something" being run (but AFTER boot2/loader), the
> keyboard is not truly usable.
For me this is not true. My keyboard always works after ukbd lines
appear on screen.
> I hope everyone here is also aware of that fact that not all keyboards
> are created equal. Case in point (and this reason is exactly why I
> am purchasing a native PS/2 keyboard, as USB4BSD doesn't work with
> all USB keyboards right now):
For me this is not an option, no PS/2 ports.
> http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000219.html
>
> The bottom line:
>
> FreeBSD cannot be reliably used with a USB keyboard in all
> circumstances.And that is a very sad reality, because 90% of the
> keyboards you find on the consumer and enterprise market are USB --
> native PS/2 keyboards are now a scarcity.
I agree that this is a sad reality but only for boot stages where we
depend on external entity named BIOS to help us.
This doesn't have to be a sad reality once kernel takes control.
USB support in boot chain - I don't know - this would be great of course
but that's a lot of code.
--
Andriy Gapon
Jeremy Chadwick
I've pointed you to evidence where this isn't true, especially when
using the USB4BSD stack. There is something called "boot legacy
protocol" which USB keyboards have to support to properly be interfaced
with in FreeBSD using the USB4BSD stack; in the case of the Microsoft
Natural Ergo 4000 keyboard, it does not play well with USB4BSD (it DOES
work with the old USB stack, but none of the multimedia keys work, and
worse, the F-Lock key does not work; this is because those keys use
uhid(4) and not ukbd(4)).
Linux has a __20 page Wiki document__ on **just this keyboard**. That
should give you some idea of how complex the situation with USB
keyboards is in general.
http://www.gentoo-wiki.info/HOWTO_Microsoft_Natural_Ergonomic_Keyboard_4000
> > I hope everyone here is also aware of that fact that not all keyboards
> > are created equal. Case in point (and this reason is exactly why I
> > am purchasing a native PS/2 keyboard, as USB4BSD doesn't work with
> > all USB keyboards right now):
>
> For me this is not an option, no PS/2 ports.
I don't know what to say to ***ANY*** of the above, other than this:
No one is doing anything about this problem because there does not
appear to be a 100% reproducible always-screws-up-when-I-do-this
scenario that happens to *every FreeBSD user*.
Until we settle down, stop replying to Emails with one-liner injections,
and compile a list of test scenarios/cases that people can perform, and
get these people to provide both 1) full hardware details, 2) full
kernel configuration files, 3) full loader.conf files, and 4) full
device.hints files, we're not going to get anywhere.
> > http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000219.html
> >
> > The bottom line:
> >
> > FreeBSD cannot be reliably used with a USB keyboard in all
> > circumstances.And that is a very sad reality, because 90% of the
> > keyboards you find on the consumer and enterprise market are USB --
> > native PS/2 keyboards are now a scarcity.
>
> I agree that this is a sad reality but only for boot stages where we
> depend on external entity named BIOS to help us.
> This doesn't have to be a sad reality once kernel takes control.
It's been confirmed by numerous people now, including #bsdports users,
that "USB Legacy" does not work for some individuals. This is either
because of BIOS bugs, or because the USB keyboards do not support tying
into SMM. We don't know the true cause.
One thing we do know: we have FreeBSD users stating they cannot type in
boot0/boot2/loader, even with USB Legacy enabled, so going into
single-user after a reboot is impossible.
Another thing we do know: we have FreeBSD users who do not have fully
functional USB keyboards in FreeBSD (some see ukbd attach, others do
not; some are using USB4BSD, others are not).
So, can someone take the time to come up with test scenarios/cases so
that users can perform these tests, list off the exact hardware they
have, and we can see if there is a consistent/common failure between
everyone?
--
| 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 |
_______________________________________________
Andriy Gapon
> I don't know what to say to ***ANY*** of the above, other than this:
>
> No one is doing anything about this problem because there does not
> appear to be a 100% reproducible always-screws-up-when-I-do-this
> scenario that happens to *every FreeBSD user*.
>
> Until we settle down, stop replying to Emails with one-liner injections,
> and compile a list of test scenarios/cases that people can perform, and
> get these people to provide both 1) full hardware details, 2) full
> kernel configuration files, 3) full loader.conf files, and 4) full
> device.hints files, we're not going to get anywhere.
Well I started two separate threads.
This thread is about one very specific issue - ukbd attaching after
mountroot code.
Again, in this thread I am only interested in getting ukbd to attach
before the mount root.
I am not interested in BIOS, boot chain, etc. I am not even interested
in speculations about whether keyboard would work or not at mountroot
prompt if it were attaching before it.
--
Andriy Gapon
Sergey Babkin
>
> What really needs to happen here should be obvious: we need some form of
> inexpensive keyboard-only USB support in boot2/loader.
>
> I would *love* to know how Linux and Windows solve this problem.
If I remember right, UnixWare used(s) the BIOS calls in the loader.
-SB
Dag-Erling Smørgrav
> Jeremy Chadwick <koi...@FreeBSD.org> writes:
> > What really needs to happen here should be obvious: we need some
> > form of inexpensive keyboard-only USB support in boot2/loader.
So does FreeBSD.
DES
--
Dag-Erling Smørgrav - d...@des.no
Martin
schrieb Jeremy Chadwick <koi...@FreeBSD.org>:
> Until we settle down, stop replying to Emails with one-liner
> injections, and compile a list of test scenarios/cases that people
> can perform, and get these people to provide both 1) full hardware
> details, 2) full kernel configuration files, 3) full loader.conf
> files, and 4) full device.hints files, we're not going to get
> anywhere.
Ok, I will add the details for the GA-EP45-DS3R based system.
1) dmesg
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights
reserved. FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-PRERELEASE #0: Mon Nov 10 08:23:21 CET 2008
root@kirby:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (3166.32-MHz
K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x8e3fd<SSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,<
b19>>
AMD Features=0x20100800<SYSCALL,NX,LM>
AMD Features2=0x1<LAHF>
Cores per package: 2
usable memory = 8574255104 (8177 MB)
avail memory = 8286810112 (7902 MB)
ACPI APIC Table: <GBT GBTUACPI>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
ioapic0: Changing APIC ID to 2
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
RF5413) acpi0: <GBT GBTUACPI> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, cfdb0000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xa000-0xa0ff mem
0xd0000000-0xdfffffff,0xe5000000-0xe500ffff irq 16 at device 0.0 on pci1
pcm0: <ATI (Unknown) High Definition Audio Controller> mem
0xe5010000-0xe5013fff irq 17 at device 0.1 on pci1 pcm0: [ITHREAD]
uhci0: <UHCI (generic) USB controller> port 0xe000-0xe01f irq 16 at
device 26.0 on pci0 uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> on uhci0
usb0: USB revision 1.0
uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <UHCI (generic) USB controller> port 0xe100-0xe11f irq 21 at
device 26.1 on pci0 uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <UHCI (generic) USB controller> port 0xe200-0xe21f irq 18 at
device 26.2 on pci0 uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <UHCI (generic) USB controller> on uhci2
usb2: USB revision 1.0
uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xe9305000-0xe93053ff
irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: <EHCI (generic) USB 2.0 controller> on ehci0
usb3: USB revision 2.0
uhub3: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb3
uhub3: 6 ports with 6 removable, self powered
pcm1: <Intel (Unknown) High Definition Audio Controller> mem
0xe9300000-0xe9303fff irq 22 at device 27.0 on pci0 pcm1: [ITHREAD]
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
pci3: <ACPI PCI bus> on pcib3
atapci0: <JMicron JMB368 UDMA133 controller> port
0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f
irq 19 at device 0.0 on pci3 atapci0: [ITHREAD] ata2: <ATA channel 0>
on atapci0 ata2: [ITHREAD]
pcib4: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
pci4: <ACPI PCI bus> on pcib4
re0: <RealTek 8168/8168B/8168C/8168CP/8111B/8111C/8111CP PCIe Gigabit
Ethernet> port 0xc000-0xc0ff mem
Ethernet> 0xe9010000-0xe9010fff,0xe9000000-0xe900ffff irq 16 at device
Ethernet> 0.0 on pci4 re0: Chip rev. 0x3c000000
re0: MAC rev. 0x00400000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:24:96:ab
re0: [FILTER]
pcib5: <ACPI PCI-PCI bridge> irq 17 at device 28.5 on pci0
pci5: <ACPI PCI bus> on pcib5
re1: <RealTek 8168/8168B/8168C/8168CP/8111B/8111C/8111CP PCIe Gigabit
Ethernet> port 0xd000-0xd0ff mem
Ethernet> 0xe9110000-0xe9110fff,0xe9100000-0xe910ffff irq 17 at device
Ethernet> 0.0 on pci5 re1: Chip rev. 0x3c000000
re1: MAC rev. 0x00400000
miibus1: <MII bus> on re1
rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto re1: Ethernet address: 00:1f:d0:24:96:a9
re1: [FILTER]
uhci3: <UHCI (generic) USB controller> port 0xe300-0xe31f irq 23 at
device 29.0 on pci0 uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb4: <UHCI (generic) USB controller> on uhci3
usb4: USB revision 1.0
uhub4: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
uhci4: <UHCI (generic) USB controller> port 0xe400-0xe41f irq 19 at
device 29.1 on pci0 uhci4: [GIANT-LOCKED]
uhci4: [ITHREAD]
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 0xe500-0xe51f irq 18 at
device 29.2 on pci0 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 0xe9304000-0xe93043ff
irq 23 at device 29.7 on pci0 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
pcib6: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci6: <ACPI PCI bus> on pcib6
fwohci0: <Texas Instruments TSB43AB23> mem
0xe9204000-0xe92047ff,0xe9200000-0xe9203fff irq 23 at device 7.0 on
pci6 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:2c:a1:59:00:00:1f:d0
fwohci0: Phy 1394a available S400, 3 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 02:2c:a1:00:1f:d0
fwe0: Ethernet address: 02:2c:a1:00:1f:d0
fwip0: <IP over FireWire> on firewire0
fwip0: Firewire address: 00:2c:a1:59:00:00:1f:d0 @ 0xfffe00000000,
S400, maxrec 2048 sbp0: <SBP-2/SCSI over FireWire> on firewire0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0xcf2b4000
fwohci0: Initiate bus reset
fwohci0: BUS reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci1: <Intel AHCI controller> port
0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f
mem 0xe9306000-0xe93067ff irq 19 at device 31.2 on pci0 atapci1:
[ITHREAD] atapci1: AHCI Version 01.20 controller with 6 ports detected
ata3: <ATA channel 0> on atapci1 ata3: [ITHREAD]
ata4: <ATA channel 1> on atapci1
ata4: [ITHREAD]
ata5: <ATA channel 2> on atapci1
ata5: [ITHREAD]
ata6: <ATA channel 3> on atapci1
ata6: [ITHREAD]
ata7: <ATA channel 4> on atapci1
ata7: [ITHREAD]
ata8: <ATA channel 5> on atapci1
ata8: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on
acpi0 fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
acpi0 sio0: type 16550A
sio0: [FILTER]
ppc0: <Parallel port> port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
plip0: <PLIP network interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 61a492006004920
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 61a492006004920
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
orm0: <ISA Option ROM> at iomem 0xd0000-0xd1fff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on
isa0 ukbd0: <Microsoft Microsoft\M-. Digital Media Keyboard, class 0/0,
rev 2.00/1.10, addr 2> on uhub2 kbd2 at ukbd0
uhid0: <Microsoft Microsoft\M-. Digital Media Keyboard, class 0/0, rev
2.00/1.10, addr 2> on uhub2 ums0: <Logitech USB-PS/2 Optical Mouse,
class 0/0, rev 2.00/27.20, addr 3> on uhub2 ums0: 8 buttons and Z dir.
Timecounters tick every 1.000 msec
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
ad6: 476938MB <WDC WD5000AACS-00G8B0 05.04C05> at ata3-master SATA300
GEOM_JOURNAL: Journal 3939325718: ad6s1f contains data.
GEOM_JOURNAL: Journal 3939325718: ad6s1f contains journal.
GEOM_JOURNAL: Journal ad6s1f clean.
acd0: DVDR <Optiarc DVD RW AD-7203S/1.06> at ata4-master SATA150
pcm0: <HDA Codec: Unknown Codec>
pcm0: <HDA Driver Revision: 20080420_0052>
pcm1: <HDA Codec: Realtek ALC885>
pcm1: <HDA Driver Revision: 20080420_0052>
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/ad6s1a
cryptosoft0: <software crypto> on motherboard
GEOM_ELI: Device ad6s1g.eli created.
GEOM_ELI: Encryption: Blowfish-CBC 448
GEOM_ELI: Crypto: software
GEOM_JOURNAL: Journal 2001271740: ad6s1g.eli contains data.
GEOM_JOURNAL: Journal 2001271740: ad6s1g.eli contains journal.
GEOM_JOURNAL: Journal ad6s1g.eli clean.
GEOM_ELI: Device ad6s1b.eli created.
GEOM_ELI: Encryption: AES-CBC 256
GEOM_ELI: Crypto: software
2) As you can see above, GENERIC (here stable, but also occurs on
BETA2).
3) loader.conf:
acpi_load="YES"
acpi_video_load="YES"
beastie_disable="YES"
geom_journal_load="YES"
#smb_load="YES"
#smbus_load="YES"
#ichsmb_load="YES"
snd_hda_load="YES"
#aio_load="YES"
#kqemu_load="YES"
kern.cam.scsi_delay=1000
autoboot_delay=3
linux_load="YES"
linprocfs_load="YES"
linsysfs_load="YES"
4) device.hints unchanged.
> It's been confirmed by numerous people now, including #bsdports users,
> that "USB Legacy" does not work for some individuals. This is either
> because of BIOS bugs, or because the USB keyboards do not support
> tying into SMM. We don't know the true cause.
I'm not sure, if every BIOS has got such a setting. I'm not fully sure,
if this is a BIOS bug. It could be, of course. Gigabyte has released
BIOS firmware updates that are not usable, until one installs Windows
(the changes history does not mention any USB fixes though). It will
take some time until I can patch the firmware.
> One thing we do know: we have FreeBSD users stating they cannot type
> in boot0/boot2/loader, even with USB Legacy enabled, so going into
> single-user after a reboot is impossible.
>
> Another thing we do know: we have FreeBSD users who do not have fully
> functional USB keyboards in FreeBSD (some see ukbd attach, others do
> not; some are using USB4BSD, others are not).
Yes. These are 3 different problems.
1) No keyboard in bootloader => missing BIOS USB support.
2) No keyboard after USB controller initialisation => missing quirks?
3) No keyboard spontaneously while working => bug?
> So, can someone take the time to come up with test scenarios/cases so
> that users can perform these tests, list off the exact hardware they
> have, and we can see if there is a consistent/common failure between
> everyone?
If you need anything more, I can try to deliver the information. I
sometimes run out of ideas how to avoid annoying the developers. :)
(In other words, I have more problems to report waiting in the
queue...) ;)
--
Martin
Andriy Gapon
Setting this issue on a technical trail now.
1. I built a kernel with USB_DEBUG enabled.
BTW, there doesn't seem to be a way to set debug levels for USB
subsystems at boot time, i.e. via hints. Or am I missing something?
It seems that the levels can only be set via sysctl but that's too late
for boot time debugging.
I had to hardcode some non-zero initial values for the levels.
2. I performed a verbose boot with USB_DEBUG kernel.
3. I looked through the dmesg and through code.
Some observations and thoughts.
There seem to be 3 points where devices attached via USB get
explored/discovered and probed/matched/attached.
First of all, typical USB controllers are attached to PCI, so
ehci/uhci/ohci devices and their corresponding usb and uhub devices are
attached along with other PCI devices.
Then, for EHCI usb devices bus exploration is performed immediately and
so some devices can get attached quite early (e.g. umass).
This is the first point.
For UHCI/OHCI hubs are added to special cold exploration list.
And also event threads are created for all hubs.
Then, via SYSINIT mechanism buses in the "cold list" get explored.
Actual priority is SI_SUB_CONFIGURE:SI_ORDER_MIDDLE.
This is the second point.
And finally the event threads get executed and after some delay (about 4
seconds) they also explore their buses.
What I observe here matched the described behavior but only to a certain
extent:
1. I see that certain devices like an external USB hub get reported in
dmesg among PCI devices. I understand that this is the first point ("ehci").
2. My USB mouse (low speed, attached to uhci) gets reported somewhere
between the following lines:
isa_probe_children: probing PnP devices
..
Device configuration finished.
I understand that this is the second point ("sysinit").
3. My USB keyboard gets reported after mountroot (but before start of init).
I think that this is the third point.
So what is very puzzling to me is why the keyboard is not found along
with the mouse at the second point. Especially given that they are
attached to the ports of the same hub:
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
Intel(0x0000), rev 1.00
uhub2
port 1 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical
Mouse(0xc040), Logitech(0x046d), rev 24.30
ums0
port 2 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x0101),
CHESEN(0x0a81), rev 1.10
ukbd0
uhid0
Here's a snippet from verbose dmesg wth USB_DEBUG where the mouse is
reported:
isa_probe_children: probing PnP devices
uhub_explore: status change hub=1 port=1
usbd_reset_port: port 1 reset done, error=NORMAL_COMPLETION
usbd_new_device bus=0xffffffff80c7d000 port=1 depth=1 speed=1
usbd_setup_pipe: dev=0xffffff0004a16d00 iface=0 ep=0xffffff0004a16d38
pipe=0xffffff0004a16d08
uhci_open: pipe=0xffffff0004a16c00, addr=0, endpt=0 (1)
usb_allocmem: adding fragments
usbd_new_device: adding unit addr=2, rev=200, class=0, subclass=0,
protocol=0, maxpacket=8, len=18, speed=1
usbd_ar_pipe: pipe=0xffffff0004a16c00
usbd_setup_pipe: dev=0xffffff0004a16d00 iface=0 ep=0xffffff0004a16d38
pipe=0xffffff0004a16d08
uhci_open: pipe=0xffffff0004a16b00, addr=0, endpt=0 (1)
usbd_ar_pipe: pipe=0xffffff0004a16b00
usbd_setup_pipe: dev=0xffffff0004a16d00 iface=0 ep=0xffffff0004a16d38
pipe=0xffffff0004a16d08
uhci_open: pipe=0xffffff0004a16a00, addr=2, endpt=0 (1)
usbd_new_device: new dev (addr 2), dev=0xffffff0004a16d00,
parent=0xffffff0001338c00
usbd_probe_and_attach: trying device specific drivers
usbd_probe_and_attach: no device specific driver found
usbd_probe_and_attach: looping over 1 configurations
usbd_probe_and_attach: trying config idx=0
usbd_set_config_index: (addr 1) cno=2 attr=0xa0, selfpowered=0, power=98
usbd_set_config_index: set config 1
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.
uhub_explore: status change hub=1 port=2
uhub_explore: status change hub=1 port=1
Device configuration finished.
And here's how the keyboard is found later:
Trying to mount root from zfs:tank/root
usbd_new_device bus=0xffffffff80c7d000 port=2 depth=1 speed=1
usbd_setup_pipe: dev=0xffffff0004b53000 iface=0 ep=0xffffff0004b53038
pipe=0xffffff0004b53008
uhci_open: pipe=0xffffff0001242c00, addr=0, endpt=0 (1)
usbd_new_device: adding unit addr=3, rev=110, class=0, subclass=0,
protocol=0, maxpacket=8, len=18, speed=1
usbd_ar_pipe: pipe=0xffffff0001242c00
usbd_setup_pipe: dev=0xffffff0004b53000 iface=0 ep=0xffffff0004b53038
pipe=0xffffff0004b53008
uhci_open: pipe=0xffffff0001242e00, addr=0, endpt=0 (1)
usbd_ar_pipe: pipe=0xffffff0001242e00
usbd_setup_pipe: dev=0xffffff0004b53000 iface=0 ep=0xffffff0004b53038
pipe=0xffffff0004b53008
uhci_open: pipe=0xffffff0004b53100, addr=3, endpt=0 (1)
usbd_new_device: new dev (addr 3), dev=0xffffff0004b53000,
parent=0xffffff0001338c00
usbd_probe_and_attach: trying device specific drivers
usbd_probe_and_attach: no device specific driver found
usbd_probe_and_attach: looping over 1 configurations
usbd_probe_and_attach: trying config idx=0
usbd_set_config_index: (addr 1) cno=3 attr=0xa0, selfpowered=0, power=100
usbd_set_config_index: set config 1
ukbd0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 3> on uhub2
Full dmesg is here:
http://www.icyb.net.ua/~avg/ukbd.dmesg.gz
Andriy Gapon
ports hoping that order might matter. It didn't.
Here's fresh usbdevs output snippet:
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
Intel(0x0000), rev 1.00
uhub2
port 1 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x0101),
CHESEN(0x0a81), rev 1.10
ukbd0
uhid0
port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical
Mouse(0xc040), Logitech(0x046d), rev 24.30
ums0
And here's a new snippet from cold explore dmesg:
uhub2: uhub_explore: port 1 status 0x0100 0x0001
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ So, hm, it looks like a change in connection status is reported but
current status is reported as not connected.
+ I wonder why?
+ Could this be related to how we perform UHCI handover from BIOS to kernel?
+ Our uhci code seems to be much simpler than what MS folks described here:
+ http://www.microsoft.com/whdc/archive/usbhost.mspx#EQHAC
uhub_explore: status change hub=1 port=1
uhub_explore: port=1 !CURRENT_CONNECT_STATUS
uhub2: uhub_explore: port 2 status 0x0301 0x0001
uhub_explore: status change hub=1 port=2
usbd_reset_port: port 2 reset done, error=NORMAL_COMPLETION
usbd_new_device bus=0xffffffff80c7d000 port=2 depth=1 speed=1
--
Andriy Gapon
> I increased debug level in uhub and also switched mouse and keyboard
> ports hoping that order might matter. It didn't.
>
> Here's fresh usbdevs output snippet:
> Controller /dev/usb2:
> addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
> Intel(0x0000), rev 1.00
> uhub2
> port 1 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x0101),
> CHESEN(0x0a81), rev 1.10
> ukbd0
> uhid0
> port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical
> Mouse(0xc040), Logitech(0x046d), rev 24.30
> ums0
>
> And here's a new snippet from cold explore dmesg:
> uhub2: uhub_explore: port 1 status 0x0100 0x0001
> + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> + So, hm, it looks like a change in connection status is reported but
> current status is reported as not connected.
> + I wonder why?
For now I am blaming this on the keyboard. My wild un-educated guess is
that it takes it too long to come back after controller reset. I don't
have any other explanation at the moment.
I'll try to get another keyboard (from different vendor) and play with it.
Andriy Gapon
> on 27/11/2008 15:23 Andriy Gapon said the following:
>> I increased debug level in uhub and also switched mouse and keyboard
>> ports hoping that order might matter. It didn't.
>>
>> Here's fresh usbdevs output snippet:
>> Controller /dev/usb2:
>> addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
>> Intel(0x0000), rev 1.00
>> uhub2
>> port 1 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x0101),
>> CHESEN(0x0a81), rev 1.10
>> ukbd0
>> uhid0
>> port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical
>> Mouse(0xc040), Logitech(0x046d), rev 24.30
>> ums0
>>
>> And here's a new snippet from cold explore dmesg:
>> uhub2: uhub_explore: port 1 status 0x0100 0x0001
>> + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> + So, hm, it looks like a change in connection status is reported but
>> current status is reported as not connected.
>> + I wonder why?
Just wanted to followup on this and let you know that the issue seems to be
resolved in stable/8, I think that early usb takeover change might have fixed it.
The change is not in 8.0.