Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Nov 2008 14:40:10 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
To:        freebsd-hackers@FreeBSD.org, freebsd-usb@FreeBSD.org
Subject:   Re: ukbd attachment and root mount
Message-ID:  <492E952A.80104@icyb.net.ua>
In-Reply-To: <491ADB3B.2090000@icyb.net.ua>
References:  <4911BA93.9030006@icyb.net.ua> <491ABFCD.3060309@icyb.net.ua> <Pine.GSO.4.64.0811120352100.1597@zeno.ucsd.edu> <491AC502.9000507@icyb.net.ua> <20081112121410.GA24629@icarus.home.lan> <491ACA19.2040008@icyb.net.ua> <20081112123315.GA24907@icarus.home.lan> <491AD0CB.8050309@icyb.net.ua> <20081112132124.GA25637@icarus.home.lan> <491ADB3B.2090000@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?492E952A.80104>