Re: ukbd attachment and root mount
on 28/11/2008 15:12 Andriy Gapon said the following: > 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(0x), >> Intel(0x), 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. > 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ukbd attachment and root mount
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(0x), > Intel(0x), 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
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(0x), Intel(0x), 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=0x80c7d000 port=2 depth=1 speed=1 usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38 pipe=0xff0004a16d08 uhci_open: pipe=0xff0004a16c00, 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=0xff0004a16c00 usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38 pipe=0xff0004a16d08 uhci_open: pipe=0xff0004a16b00, addr=0, endpt=0 (1) usbd_ar_pipe: pipe=0xff0004a16b00 usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38 pipe=0xff0004a16d08 uhci_open: pipe=0xff0004a16a00, addr=2, endpt=0 (1) usbd_new_device: new dev (addr 2), dev=0xff0004a16d00, parent=0xff0001338c00 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: on uhub2 ums0: 8 buttons and Z dir. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
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(0x),
Intel(0x), 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=0x80c7d000 port=1 depth=1 speed=1
usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38
pipe=0xff0004a16d08
uhci_open: pipe=0xff0004a16c00, 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=0xff0004a16c00
usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38
pipe=0xff0004a16d08
uhci_open: pipe=0xff0004a16b00, addr=0, endpt=0 (1)
usbd_ar_pipe: pipe=0xff0004a16b00
usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38
pipe=0xff0004a16d08
uhci_open: pipe=0xff0004a16a00, addr=2, endpt=0 (1)
usbd_new_device: new dev (addr 2), dev=0xff0004a16d00,
parent=0xff0001338c00
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: 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=0x80c7d000 port=2 depth=1 speed=1
usbd_setup_pipe: dev=0xff0004b53000 iface=0 ep=0xff0004b53038
pipe=0xff0004b53008
uhci_open: pipe=0xff0001242c00, 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=0xff0001242c00
usbd_setup_pipe: dev=0xff0004b53000 iface=0 ep=0xff0004b53038
pipe=0xff0004b53008
uhci_open: pipe=0xff0001242e00, addr=0, endpt=0 (1)
usbd_ar_pipe: pipe=0xff0001242e00
usbd_setup_pipe: dev=0xff0004b53000 iface=0 ep=0xff0004b53038
pipe=0xff0004b53008
uhci_open: pipe=0xff0004b53100, addr=3, endpt=0 (1)
usbd_new_device: new dev (addr 3), dev=0xff0004b53000,
parent=0xff0001338c00
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:
Re: ukbd attachment and root mount
Am Wed, 12 Nov 2008 05:21:24 -0800 schrieb Jeremy Chadwick <[EMAIL PROTECTED]>: > 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 [EMAIL PROTECTED]:/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 Features2=0x8e3fd> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 8574255104 (8177 MB) avail memory = 8286810112 (7902 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cfdb (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: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xd000-0xdfff,0xe500-0xe500 irq 16 at device 0.0 on pci1 pcm0: mem 0xe501-0xe5013fff irq 17 at device 0.1 on pci1 pcm0: [ITHREAD] uhci0: port 0xe000-0xe01f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe100-0xe11f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe200-0xe21f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: 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: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcm1: mem 0xe930-0xe9303fff irq 22 at device 27.0 on pci0 pcm1: [ITHREAD] pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 atapci0: port 0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f irq 19 at device 0.0 on pci3 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 re0: port 0xc000-0xc0ff mem Ethernet> 0xe901-0xe9010fff,0xe900-0xe900 irq 16 at device Ethernet> 0.0 on pci4 re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: on re0 rgephy0: 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: irq 17 at device 28.5 on pci0 pci5: on pcib5 re1: port 0xd000-0xd0ff mem Ethernet> 0xe911-0xe9110fff,0xe910-0xe910 irq 17 at device Ethernet> 0.0 on pci5 re1: Chip rev. 0x3c00 re1: MAC rev. 0x0040 miibus1: on re1 rgephy1: 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: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xe9304000-0xe93043ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion con
Re: ukbd attachment and root mount
Sergey Babkin <[EMAIL PROTECTED]> writes: > Jeremy Chadwick <[EMAIL PROTECTED]> writes: > > What really needs to happen here should be obvious: we need some > > form of inexpensive keyboard-only USB support in boot2/loader. > If I remember right, UnixWare used(s) the BIOS calls in the loader. So does FreeBSD. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
Jeremy Chadwick wrote: > > 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 12/11/2008 15:21 Jeremy Chadwick said the following: > 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
On Wed, Nov 12, 2008 at 02:49:15PM +0200, Andriy Gapon wrote: > on 12/11/2008 14:33 Jeremy Chadwick said the following: > > 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'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 scar
Re: ukbd attachment and root mount
on 12/11/2008 14:33 Jeremy Chadwick said the following: > 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
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'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 Chadwickjdc 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
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. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
On Wed, Nov 12, 2008 at 01:58:58PM +0200, Andriy Gapon wrote: > on 12/11/2008 13:53 Nate Eldredge said the following: > > On Wed, 12 Nov 2008, Andriy Gapon wrote: > > > >> 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 . 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 Chadwickjdc 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 12/11/2008 13:53 Nate Eldredge said the following: > On Wed, 12 Nov 2008, Andriy Gapon wrote: > >> 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 . > 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
On Wed, 12 Nov 2008, Andriy Gapon wrote: 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 [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 05/11/2008 17:24 Andriy Gapon said the following: > 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: 1.10/1.10, addr 3> on uhub2 > Nov 3 15:40:54 kernel: kbd2 at ukbd0 > Nov 3 15:40:54 kernel: uhid0: 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: 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:0x3d > Nov 4 17:54:03 odyssey kernel: uhid0: 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
