Description of problem: If I boot up with my USB Bluetooth dongle plugged in, eventually the Bluetooth mouse quits working (nonresponsive). If I attempt to reboot after the mouse dies, I literally have to power down the machine --because reboot hangs while "shutting down hidd". It usually takes about an hour between boot up and the oops. The first oops of this type is found in my logs on 1/29/07. A typical backtrace is included under "additional information". Version-Release number of selected component (if applicable): Rawhide up to date as of 2/8/07 kernel-2.6.20-1.2922.fc7 gnome-bluetooth-libs-0.8.0-2.fc7 gnome-bluetooth-0.8.0-2.fc7 libbtctl-0.8.2-2.fc7 nautilus-sendto-bluetooth-0.8-4.fc7 How reproducible: always Additional info: Feb 7 16:58:23 azalea kernel: BUG: unable to handle kernel paging request at virtual address 6b6b6b6b Feb 7 16:58:23 azalea kernel: printing eip: Feb 7 16:58:23 azalea kernel: c04e3bd2 Feb 7 16:58:23 azalea kernel: *pde = 00000000 Feb 7 16:58:23 azalea kernel: Oops: 0000 [#1] Feb 7 16:58:23 azalea kernel: SMP Feb 7 16:58:23 azalea kernel: last sysfs file: /class/net/eth0/carrier Feb 7 16:58:23 azalea kernel: Modules linked in: radeon drm autofs4 hidp rfcomm l2cap sunrpc cpufreq_ondemand vfat fat dm_mirror dm_multipath dm_mod video sbs ibm_acpi i2c_ec dock button battery asus_acpi backlight ac lp hci_usb bluetooth snd_intel8x0m ipw2200 nsc_ircc parport_pc irda parport ieee80211 crc_ccitt ieee80211_crypt tg3 iTCO_wdt serio_raw snd_intel8x0 snd_ac97_codec ac97_bus iTCO_vendor_support snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device i2c_i801 snd_pcm_oss snd_mixer_oss snd_pcm i2c_core pcspkr snd_timer snd soundcore snd_page_alloc floppy sr_mod cdrom sg joydev ata_generic ata_piix ahci libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Feb 7 16:58:23 azalea kernel: CPU: 0 Feb 7 16:58:23 azalea kernel: EIP: 0060:[<c04e3bd2>] Not tainted VLI Feb 7 16:58:23 azalea kernel: EFLAGS: 00010286 (2.6.20-1.2922.fc7 #1) Feb 7 16:58:23 azalea kernel: EIP is at kobject_get_path+0x20/0x9a Feb 7 16:58:23 azalea kernel: eax: 00000000 ebx: f682775a ecx: ffffffff edx: 000000d0 Feb 7 16:58:23 azalea kernel: esi: dc0536d0 edi: 6b6b6b6b ebp: f3ff6e9c esp: f3ff6e80 Feb 7 16:58:23 azalea kernel: ds: 007b es: 007b ss: 0068 Feb 7 16:58:23 azalea kernel: Process khidpd_04614b01 (pid: 3540, ti=f3ff6000 task=dbea2ac0 task.ti=f3ff6000) Feb 7 16:58:23 azalea kernel: Stack: f3ff6ea0 dc0536d0 00000001 c04e3bf1 f682775a dc0535f8 e99d9b98 f3ff6edc Feb 7 16:58:23 azalea kernel: c0556def 00463611 00000046 ffffffff fffffffe ffffffff 00000000 c069d9c6 Feb 7 16:58:23 azalea kernel: f682772e dc650d94 00000000 00000000 f682775a 00000006 c0556db2 f3ff6f30 Feb 7 16:58:23 azalea kernel: Call Trace: Feb 7 16:58:23 azalea kernel: [<c04051c9>] show_trace_log_lvl+0x1a/0x2f Feb 7 16:58:23 azalea kernel: [<c0405279>] show_stack_log_lvl+0x9b/0xa3 Feb 7 16:58:23 azalea kernel: [<c0405415>] show_registers+0x194/0x26a Feb 7 16:58:23 azalea kernel: [<c0405618>] die+0x12d/0x242 Feb 7 16:58:23 azalea kernel: [<c0606d47>] do_page_fault+0x3ee/0x4ba Feb 7 16:58:23 azalea kernel: [<c0605544>] error_code+0x7c/0x84 Feb 7 16:58:23 azalea kernel: [<c0556def>] class_uevent+0x3d/0x1dc Feb 7 16:58:23 azalea kernel: [<c04e4564>] kobject_uevent_env+0x21a/0x412 Feb 7 16:58:23 azalea kernel: [<c04e4766>] kobject_uevent+0xa/0xc Feb 7 16:58:23 azalea kernel: [<c055676c>] class_device_del+0x119/0x137 Feb 7 16:58:23 azalea kernel: [<c0556795>] class_device_unregister+0xb/0x15 Feb 7 16:58:23 azalea kernel: [<c057d5f4>] input_unregister_device+0x116/0x13e Feb 7 16:58:23 azalea kernel: [<f8b5805c>] hidp_session+0x411/0x435 [hidp] Feb 7 16:58:23 azalea kernel: [<c0404cb3>] kernel_thread_helper+0x7/0x10 Feb 7 16:58:23 azalea kernel: ======================= Feb 7 16:58:23 azalea kernel: Code: 90 55 89 e5 e8 94 01 f9 ff 5d c3 55 89 e5 57 56 89 c6 53 83 ec 10 89 45 e8 c7 45 ec 01 00 00 00 8b 3e 85 ff 74 73 31 c0 83 c9 ff <f2> ae f7 d1 49 8b 45 ec 8d 44 08 01 89 45 ec 8b 76 24 85 f6 75 Feb 7 16:58:23 azalea kernel: EIP: [<c04e3bd2>] kobject_get_path+0x20/0x9a SS:ESP 0068:f3ff6e80 Feb 7 16:58:29 azalea hidd[2583]: New HID device 00:0C:55:19:DB:67 (Primax Four Button Mouse)
One further observation. I have been using this same hardware (Kensington dongle and mouse) on a Thinkpad T43 that has been tracking Rawhide for the last 18 months. This is the first time I've seen this problem (or had any problem with the Bluetooth mouse).
A good bug report, but... I'll keep it in NEW state for now. I suspect that the generic HID caused it. Just in case, please attach /proc/bus/usb/devices. I'd like to see it.
Created attachment 147912 [details] /proc/bus/usb/devices before oops occurs I have attached a copy of /proc/bus/usb/devices immediately after boot up (before the oops) occurs and will also attach a copy of the file from a couple of days after the oops. There was no change in hardware attached to the machine.
Created attachment 147913 [details] /proc/bus/usb/devices a couple of days after the oops
I actually diff'ed these two files and realized that there is virtually no difference between "before" and "after" instances except for some of the device numbers. To avoid any misunderstanding about this, let me state that the procedure I used to get these files was to print the usb devices from a system with a hung mouse, reboot the system, then print the usb devices from a system with a working Bluetooth mouse. Hence, there was a reboot in the interval between the two usb device snapshots.
Marcel, are you interested? Drop off cc: if not.
*** Bug 231601 has been marked as a duplicate of this bug. ***
*** Bug 229096 has been marked as a duplicate of this bug. ***
For now I'm running with this patch to prevent my laptop from constantly crashing. Why _did_ we enable CONFIG_SYSFS_DEPRECATED anyway? We should have bugs filed for any userspace which requires it. --- linux-2.6.20.ppc/drivers/base/class.c~ 2007-03-11 15:35:12.000000000 +0100 +++ linux-2.6.20.ppc/drivers/base/class.c 2007-03-11 16:56:58.000000000 +0100 @@ -379,7 +379,7 @@ static int deprecated_class_uevent(char struct device *dev = class_dev->dev; char *path; - if (!dev) + if (1 || !dev) return 0; /* add device, backing this class device (deprecated) */
Applied this change to 2.6.20-1.2985.fc7 and it solves the issue described in Bug 229096. But with this change bluetoothd-serv eats more than 90% of CPU and won't come down unless I stop the bluetooth service which is off course not a solution. Also when hidd is started it always spits out "Starting hidd: Can't listen on HID control channel: Address already in use". The mouse does work correctly though.
FYI. System has been running for several days now with Bluetooth USB dongle plugged in/Bluetooth mouse active and no oop's. Currently running kernel 2.6.20-1.3045.fc7.
Yeah, we have a hack which works around the problem.