On Wed, 23 May 2007, Zan Lynx wrote:
> I am having weird problems with USB keyboard and mouse. The USB
> keyboard will drop keystrokes, but not all of them. The mouse seems to
> move fine but drops clicks. Could be that an occasional missed move
> event isn't noticeable. Nothing is logged when a key is dropped.
> However, I did have some of this when it was first booting:
> BUG: at drivers/hid/hid-core.c:778 implement()
> Call Trace:
> [<ffffffff880bb5ac>] :hid:hid_output_report+0x1dc/0x270
> [<ffffffff880c651a>] :usbhid:hid_submit_ctrl+0x7a/0x260
> [<ffffffff880c68ee>] :usbhid:usbhid_submit_report+0x11e/0x200
> [<ffffffff880c9312>] :usbhid:hiddev_ioctl+0x3e2/0xae0
> [<ffffffff8053523e>] do_page_fault+0x42e/0x880
> [<ffffffff802b486d>] do_ioctl+0x7d/0xa0
> [<ffffffff802b4ab1>] vfs_ioctl+0x221/0x2d0
> [<ffffffff8025a711>] trace_hardirqs_on+0xc1/0x160
> [<ffffffff802b4ba9>] sys_ioctl+0x49/0x80
> [<ffffffff8020a16e>] system_call+0x7e/0x83
OK, so something is touching one of your HID devices through hiddev, and
tries to push through it something that doesn't comply to the report
descriptor of the device. Are you aware of any userspace daemons running
which would touch /dev/hiddev*? (acupsd, nut, hid2hci, etc.).
Just for clarification, does situation get any better when you disable
hidraw, which I see you have enabled? (if that doesn't help, testing with
hiddev disabled should also be interesting - that would avoid the
possibility that userspace mocks the device up through hiddev).
> BUG: at include/linux/slub_def.h:83 kmalloc_index()
> Call Trace:
> [<ffffffff802a2e09>] get_slab+0xb9/0x180
> [<ffffffff802a2965>] kfree+0xc5/0x110
> [<ffffffff802a2fd4>] __kmalloc+0x24/0xc0
> [<ffffffff8049ab18>] get_modalias+0x68/0x120
> [<ffffffff8049ac07>] dmi_dev_uevent+0x37/0x60
> [<ffffffff80443b63>] dev_uevent+0x163/0x220
> [<ffffffff803bcc97>] kobject_uevent_env+0x2b7/0x500
> [<ffffffff80444f50>] bus_add_device+0x20/0x140
> [<ffffffff804438d2>] device_add+0x4a2/0x5b0
> [<ffffffff807a0a1b>] dmi_id_init+0x2cb/0x2f0
> [<ffffffff807866e6>] kernel_init+0x156/0x330
> [<ffffffff80531f5c>] trace_hardirqs_on_thunk+0x35/0x37
> [<ffffffff8025a711>] trace_hardirqs_on+0xc1/0x160
> [<ffffffff8020b028>] child_rip+0xa/0x12
> [<ffffffff8020a710>] restore_args+0x0/0x30
> [<ffffffff803e6c10>] vgacon_cursor+0x0/0x1f0
> [<ffffffff8023ad5b>] release_console_sem+0x4b/0x230
> [<ffffffff80786590>] kernel_init+0x0/0x330
> [<ffffffff8020b01e>] child_rip+0x0/0x12
This BTW needs a separate bugreport.
> input,hiddev0,hidraw2: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:02.2-2.2.1
This is pretty strange. Mouse shouldn't be claimed by hiddev. Seems like
this mouse probably has some "interesting" HID report descriptor. Could
you please recompile with CONFIG_HID_DEBUG enabled and send me the output?
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.22-rc2-mm1 #1
> -------------------------------------------------------
> rhythmbox/6976 is trying to acquire lock:
> (&mm->mmap_sem){----}, at: [<ffffffff80534f8c>] do_page_fault+0x17c/0x880
> but task is already holding lock:
> (&data->latch){----}, at: [<ffffffff8034a701>] get_exclusive_access+0x11/0x20
> which lock already depends on the new lock.
This also needs a separate report.
Do you please have any indication which kernel versions were OK with the
same .config, with respect to the USB mouse/keyboard hogs you are seeing
with 2.6.22-rc2-mm1?
Thanks,
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
