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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux