Re: [BUG, Regression, bisected] USB mouse causes bug on 1st insert, ignored on 2nd insert, lsusb stuck at usbdev_open

Jiri Kosina
2010-09-21T12:31:25Z

On Mon, 20 Sep 2010, Phil Turmel wrote:

> dmesg attached. Note: the timestamp of the BUG corresponds to hal
> startup when the external mouse is plugged in before booting.

Mat, Phil, Gabriel,

thanks for providing the dmesg with the debugging patch in place. Here we
go:

[snip]
> [ 3.268784] HID debug: usbhid_probe() -- set intfdata(ffff880137d0ac00, ffff88013a7c0000)
> [ 3.278462] input: DualPoint Stick as /devices/platform/i8042/serio1/input/input6
> [ 3.285212] HID debug: hid_connect() -- hid: ffff88013a7c0000
> [ 3.286141] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0/input/input7
> [ 3.287413] generic-usb 0003:046D:C51B.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1/input0

hid device pointer 0xffff88013a7c0000, usb_interface pointer
0xffff880137d0ac00. This interface doesn't get registered with hiddev.

> [ 3.288338] HID debug: usbhid_probe() -- set intfdata(ffff880137d0a400, ffff880138344000)
> [ 3.303524] HID debug: hid_connect() -- hid: ffff880138344000
> [ 3.304424] HID debug: hiddev_connect() -- hid: ffff880138344000, hiddev: ffff880137ce9f00, intf: ffff880137d0a400
> [ 3.305678] HID debug: hid_connect() -- after hiddev_connect(), hid: ffff880138344000, hiddev: ffff880137ce9f00
> [ 3.306609] generic-usb 0003:046D:C51B.0002: hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.0-1/input1

hid device pointer 0xffff880138344000, usb_interface pointer
0xffff880137d0a400. This interface does get registered with hiddev
(allocated at 0xffff880137ce9f00), doesn't get registered with input. So
far so good.

[snip]
> [ 22.705849] HID debug: hiddev_open(): hid: ffff88013a7c0000, hiddev: (null), intf: ffff880137d0ac00

hiddev_open() has been called. usb_find_interface(&hid_driver, minor)
returned interface pointer 0xffff880137d0ac00. Which is bogus! Interface
0xffff880137d0ac00 is not registered with hiddev at all, we should have
received 0xffff880137d0a400.

We currently register minors only for those usbhid devices (through
usb_register_dev() in hiddev_connect()) which are going to be claimed by
hiddev. It doesn't seem to be problematic to me, and I don't undersntand
why usb_find_interface() returns wrong interface.

I have just found out that it's actually CONFIG_USB_DYNAMIC_MINORS which
makes the difference. When unset, the problem doesn't trigger, and
usb_find_interface() always returns the proper interface. When
CONFIG_USB_DYNAMIC_MINORS is being used, the oops happen.

I'll look into that.

> [ 22.705859] BUG: unable to handle kernel NULL pointer dereference at (null)

This is then immediate consequence, as that device has nothing associated
in its hiddev pointer of course.

--
Jiri Kosina
SUSE Labs, Novell Inc.