[Dell Latitude D430] recent hid2hci upgrade breaks docking station USB input devices
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
udev |
Fix Released
|
Undecided
|
Martin Pitt | ||
udev-extras (Ubuntu) |
Fix Released
|
High
|
Martin Pitt | ||
Karmic |
Fix Released
|
High
|
Martin Pitt |
Bug Description
Binary package hint: udev-extras
I have a Dell Latitude D432 on an EURO-1 docking station. Since yesterday's upgrades, external USB mouse/keyboard don't work any more, they stop working during boot (udevadm trigger, I think) with some error messages about "cannot access device", and then keyboard and mouse get powered off. I don't get the issue without the docking station, all USB devices work fine when being connected directly on the laptop.
I tracked this down to the hid2hci rule change in http://
This is meant to do something with bluetooth devices, but apparently catches my USB input devices on the docking station.
ProblemType: Bug
Architecture: amd64
CustomUdevRuleF
Date: Thu Jun 25 16:42:57 2009
DistroRelease: Ubuntu 9.10
MachineType: Dell Inc. Latitude D430
Package: udev-extras 20090615+1-3 [modified: lib/udev/
ProcCmdLine: root=UUID=
ProcEnviron:
PATH=(custom, user)
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcVersionSign
SourcePackage: udev-extras
Uname: Linux 2.6.30-10-generic x86_64
dmi.bios.date: 05/21/2007
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A00
dmi.board.name: 0HU754
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: Latitude D430
dmi.sys.vendor: Dell Inc.
The second hunk is irrelevant, but this change seems to have triggered it:
-KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{idVendor} =="413c" , ATTRS{bmAttribu tes}==" e0", \ eProtocol} =="02", ATTRS{idVendor} =="413c" , ATTRS{bmAttribu tes}==" e0", \
+ATTR{bInterfac
RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
I guess what happens it that hid2hci is now called on this device.
First, my USB input devices:
keyboard: /devices/ pci0000: 00/0000: 00:1d.7/ usb1/1- 8/1-8.1/ 1-8.1.2/ 1-8.1.2: 1.1/input/ input8/ event8 pci0000: 00/0000: 00:1d.7/ usb1/1- 8/1-8.1/ 1-8.1.3/ 1-8.1.3: 1.0/input/ input9/ event9
mouse: /devices/
So let's check what this rule is called on:
$ udevadm trigger --dry-run --subsystem- match=usb --attr- match=bInterfac eProtocol= 02 --verbose pci0000: 00/0000: 00:1d.7/ usb1/1- 8/1-8.1/ 1-8.1.3/ 1-8.1.3: 1.0 pci0000: 00/0000: 00:1d.7/ usb1/1- 8/1-8:1. 0
/sys/devices/
/sys/devices/
/sys/devices/ pci0000: 00/0000: 00:1d.7/ usb1/1- 8/1-8:1. 0 is apparently the docking station's USB hub, in attached UdevDb.txt you see that the USB mouse/keyboard are attached to this.
/devices/ pci0000: 00/0000: 00:1d.7/ usb1/1- 8/1-8.1/ 1-8.1.3/ 1-8.1.3: 1.0 is the mouse (which is connected to the keyboard's builtin USB hub).
ATTRS{idVendor} =="413c" , ATTRS{bmAttribu tes}==" e0" matches on a far-out parent device:
looking at parent device '/devices/ pci0000: 00/0000: 00:1d.7/ usb1/1- 8': ="usb" configuration} =="" bNumInterfaces} ==" 1" bConfigurationV alue}== "1" bmAttributes} =="e0" bMaxPower} =="100mA" urbnum} =="71" idVendor} =="413c" idProduct} =="0058" bcdDevice} =="0000" bDeviceClass} =="09" bDeviceSubClass }=="00" bDeviceProtocol }=="02" bNumConfigurati ons}==" 1" bMaxPacketSize0 }=="64" speed}= ="480" busnum} =="1" devnum} =="3" version} ==" 2.00" maxchild} =="4" quirks} =="0x0" authorized} =="1"
KERNELS=="1-8"
SUBSYSTEMS=
DRIVERS=="usb"
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
so just because I have a Dell USB hub somewhere, all devices attached to it with bInterfaceProto col==02 get treated by this hid2hci program. Apparently this rule is way too wide.
You need to check ATTR{bInterface Class} and ATTR{bInterface SubClass} , to make sure that bInterfaceProto col=="02" actually has some meaning. E. g., as http:// www.usb. org/developers/ defined_ class shows, interface class 09, subclass 00, interface protocol 02 is a hi-speed USB. I don't think these are intended to match here. You probably want class E0, subclass 01 or 02 (I don't know what these rules are actually supposed to do), but these are bluetooth devices.