Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759217AbXEWXlT (ORCPT ); Wed, 23 May 2007 19:41:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756506AbXEWXlJ (ORCPT ); Wed, 23 May 2007 19:41:09 -0400 Received: from twin.jikos.cz ([213.151.79.26]:46305 "EHLO twin.jikos.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756108AbXEWXlI (ORCPT ); Wed, 23 May 2007 19:41:08 -0400 Date: Thu, 24 May 2007 01:40:47 +0200 (CEST) From: Jiri Kosina To: Zan Lynx cc: Andrew Morton , linux-kernel@vger.kernel.org, Dmitry Torokhov , linux-usb-devel@lists.sourceforge.net Subject: Re: 2.6.22-rc2-mm1 In-Reply-To: <1179962229.8575.4.camel@localhost> Message-ID: References: <20070523004233.5ae5f6fd.akpm@linux-foundation.org> <1179962229.8575.4.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3814 Lines: 86 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: > [] :hid:hid_output_report+0x1dc/0x270 > [] :usbhid:hid_submit_ctrl+0x7a/0x260 > [] :usbhid:usbhid_submit_report+0x11e/0x200 > [] :usbhid:hiddev_ioctl+0x3e2/0xae0 > [] do_page_fault+0x42e/0x880 > [] do_ioctl+0x7d/0xa0 > [] vfs_ioctl+0x221/0x2d0 > [] trace_hardirqs_on+0xc1/0x160 > [] sys_ioctl+0x49/0x80 > [] 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: > [] get_slab+0xb9/0x180 > [] kfree+0xc5/0x110 > [] __kmalloc+0x24/0xc0 > [] get_modalias+0x68/0x120 > [] dmi_dev_uevent+0x37/0x60 > [] dev_uevent+0x163/0x220 > [] kobject_uevent_env+0x2b7/0x500 > [] bus_add_device+0x20/0x140 > [] device_add+0x4a2/0x5b0 > [] dmi_id_init+0x2cb/0x2f0 > [] kernel_init+0x156/0x330 > [] trace_hardirqs_on_thunk+0x35/0x37 > [] trace_hardirqs_on+0xc1/0x160 > [] child_rip+0xa/0x12 > [] restore_args+0x0/0x30 > [] vgacon_cursor+0x0/0x1f0 > [] release_console_sem+0x4b/0x230 > [] kernel_init+0x0/0x330 > [] 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: [] do_page_fault+0x17c/0x880 > but task is already holding lock: > (&data->latch){----}, at: [] 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/