Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Mon, 5 Mar 2007, Amedee Van Gasse wrote: > It _appears_ that the bug reports started after an update of > bluez-utils, but this remains to be confirmed. It could be > coincidence/temporal correlation (which does not imply causation). Hi Amedee, did you have time to confirm whether this started to happen after bluez-utils update, as you stated in the mail above some time ago? 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Mon, 5 Mar 2007, Amedee Van Gasse wrote: It _appears_ that the bug reports started after an update of bluez-utils, but this remains to be confirmed. It could be coincidence/temporal correlation (which does not imply causation). Hi Amedee, did you have time to confirm whether this started to happen after bluez-utils update, as you stated in the mail above some time ago? 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Tue, 6 Mar 2007, Amedee Van Gasse wrote: > > This would be in fact very interesting to know. 1) does the BUG trigger > > only with newer versions of bluez-utils? 2) If so, does everything work > > with these older versions, or do the things fail in a same way, but > > silently? > I could install an older version of my distribution and see what > happens, but that means I'll have to reserve some disk space and a lot > more time. I hope one of the many live cds also support bluetooth, that > would speed things up a lot. Will try to do that, but it'll take some > time. I think that for the initial test just installing older version of bluez-utils might be enough to verify whether they do or don't cause the BUG to trigger. > I installed something called usbsnoop and waved a lot of dead chickens > to convince the bluetooth receiver to pair again with the keyboard. > Attached is the logfile. I hope this helps, if not just tell me what you > need. Thanks. Looks like there are the following reports that could potentially be used to switch the dongle from HID to HCI (assuming that Logitech didn't change behavior of its devices too much) ff 80 00 00 03 00 ff 80 80 02 00 00 ff 80 80 01 00 00 (and maybe ff 80 09 01 00 00 ?) This doesn't look like what is currently supported by hid2hci function switch_logitech(), but I would rather leave this to Marcel. 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Tue, 6 Mar 2007, Amedee Van Gasse wrote: This would be in fact very interesting to know. 1) does the BUG trigger only with newer versions of bluez-utils? 2) If so, does everything work with these older versions, or do the things fail in a same way, but silently? I could install an older version of my distribution and see what happens, but that means I'll have to reserve some disk space and a lot more time. I hope one of the many live cds also support bluetooth, that would speed things up a lot. Will try to do that, but it'll take some time. I think that for the initial test just installing older version of bluez-utils might be enough to verify whether they do or don't cause the BUG to trigger. I installed something called usbsnoop and waved a lot of dead chickens to convince the bluetooth receiver to pair again with the keyboard. Attached is the logfile. I hope this helps, if not just tell me what you need. Thanks. Looks like there are the following reports that could potentially be used to switch the dongle from HID to HCI (assuming that Logitech didn't change behavior of its devices too much) ff 80 00 00 03 00 ff 80 80 02 00 00 ff 80 80 01 00 00 (and maybe ff 80 09 01 00 00 ?) This doesn't look like what is currently supported by hid2hci function switch_logitech(), but I would rather leave this to Marcel. 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
(added Marcel to CC) On Mon, 5 Mar 2007, Amedee Van Gasse wrote: > It _appears_ that the bug reports started after an update of > bluez-utils, but this remains to be confirmed. It could be > coincidence/temporal correlation (which does not imply causation). This would be in fact very interesting to know. 1) does the BUG trigger only with newer versions of bluez-utils? 2) If so, does everything work with these older versions, or do the things fail in a same way, but silently? > Anyway, is this a kernel problem or is bluez-utils to blame? I would bet that the problem is that we don't know yet the correct vendor-specific report that is needed to be sent to the dongle to switch from HID to HCI mode. > PS: I bumped into this topic when googling for "046d:c70e". I'm not a > developer (I'm what they call "a user"), but I'm not afraid to get my > hands dirty. If you want me to run debug versions or patched kernels, I > can do that. After all, I have the hardware and I might give you > valuable information (even if I wouldn't recognise it when it spat me in > the face). Would you also be capable of catching the report which switches the dongle from HID to HCI in other operating system, for which there already is a support? 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Tue, 27 Feb 2007 16:54:27 +0100 (CET), Jiri Kosina <> wrote: > > What puzzles me a bit is a fact that both the bugreporters seem to > state pretty clearly that this started happening after some update, am > I right? > > Or did the hardware before work all the time in the HID mode, without > even being attempted to switch to HCI (which seems to cause the bug)? It _appears_ that the bug reports started after an update of bluez-utils, but this remains to be confirmed. It could be coincidence/temporal correlation (which does not imply causation). As for myself, I have a Logitech MX5000 keyboard/mouse with usb dongle, and I can confirm that the keyboard/mouse have always worked in HID. But in HID mode, no other bluetooth functions are possible (like pairing with a smartphone). It's possible to switch from HID to HCI and have a working mouse +bluetooth receiver, but in that case the keyboard can't pair. I used this script to get functional bluetooth (and unresponsive keyboard): hid2hci --tohci sleep 1 /etc/init.d/bluetooth restart sleep 1 # connect with the mouse hidd -i hci0 --connect 00:07:61:48:71:DE # connect with the keyboard hidd -i hci0 --connect 00:07:61:3F:DA:41 I think the "-i hci0" isn't even needed, but it can't hurt. This triggers a lot of occurences of the following in my logs: BUG: at drivers/hid/hid-core.c:785 implement() [] hid_output_report+0x288/0x300 [hid] [] hid_submit_ctrl+0x58/0x200 [usbhid] [schedule_timeout+83/208] schedule_timeout+0x53/0xd0 [finish_wait+45/112] finish_wait+0x2d/0x70 [] usbhid_submit_report+0x11b/0x1b0 [usbhid] [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 [] hiddev_ioctl+0x446/0xb40 [usbhid] [filemap_nopage+753/928] filemap_nopage+0x2f1/0x3a0 [kmap_atomic+134/160] kmap_atomic+0x86/0xa0 [kunmap_atomic+107/112] kunmap_atomic+0x6b/0x70 [__handle_mm_fault+633/2624] __handle_mm_fault+0x279/0xa40 [nameidata_to_filp+53/64] nameidata_to_filp+0x35/0x40 [do_ioctl+120/144] do_ioctl+0x78/0x90 [vfs_ioctl+92/672] vfs_ioctl+0x5c/0x2a0 [sys_ioctl+114/144] sys_ioctl+0x72/0x90 [sysenter_past_esp+105/169] sysenter_past_esp+0x69/0xa9 === There are a few Ubuntu bug reports that describe the problem, with some log files and other useful info: https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/32415 https://launchpad.net/ubuntu/+source/bluez-utils/+bug/66884/ I have found similar descriptions in other distros. I have exactly the same experience as Vincent Fortier described (keyboard working at boot, some keys repeating sometimes, keyboard unresponsive when bluetooth comes up, keyboard works again after dongle unplug/replug, but no bluetooth) Anyway, is this a kernel problem or is bluez-utils to blame? PS: I bumped into this topic when googling for "046d:c70e". I'm not a developer (I'm what they call "a user"), but I'm not afraid to get my hands dirty. If you want me to run debug versions or patched kernels, I can do that. After all, I have the hardware and I might give you valuable information (even if I wouldn't recognise it when it spat me in the face). -- Amedee Van Gasse [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Tue, 27 Feb 2007 16:54:27 +0100 (CET), Jiri Kosina wrote: What puzzles me a bit is a fact that both the bugreporters seem to state pretty clearly that this started happening after some update, am I right? Or did the hardware before work all the time in the HID mode, without even being attempted to switch to HCI (which seems to cause the bug)? It _appears_ that the bug reports started after an update of bluez-utils, but this remains to be confirmed. It could be coincidence/temporal correlation (which does not imply causation). As for myself, I have a Logitech MX5000 keyboard/mouse with usb dongle, and I can confirm that the keyboard/mouse have always worked in HID. But in HID mode, no other bluetooth functions are possible (like pairing with a smartphone). It's possible to switch from HID to HCI and have a working mouse +bluetooth receiver, but in that case the keyboard can't pair. I used this script to get functional bluetooth (and unresponsive keyboard): hid2hci --tohci sleep 1 /etc/init.d/bluetooth restart sleep 1 # connect with the mouse hidd -i hci0 --connect 00:07:61:48:71:DE # connect with the keyboard hidd -i hci0 --connect 00:07:61:3F:DA:41 I think the -i hci0 isn't even needed, but it can't hurt. This triggers a lot of occurences of the following in my logs: BUG: at drivers/hid/hid-core.c:785 implement() [f8d59608] hid_output_report+0x288/0x300 [hid] [f8d7d4c8] hid_submit_ctrl+0x58/0x200 [usbhid] [schedule_timeout+83/208] schedule_timeout+0x53/0xd0 [finish_wait+45/112] finish_wait+0x2d/0x70 [f8d7d78b] usbhid_submit_report+0x11b/0x1b0 [usbhid] [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 [f8d7f9d6] hiddev_ioctl+0x446/0xb40 [usbhid] [filemap_nopage+753/928] filemap_nopage+0x2f1/0x3a0 [kmap_atomic+134/160] kmap_atomic+0x86/0xa0 [kunmap_atomic+107/112] kunmap_atomic+0x6b/0x70 [__handle_mm_fault+633/2624] __handle_mm_fault+0x279/0xa40 [nameidata_to_filp+53/64] nameidata_to_filp+0x35/0x40 [do_ioctl+120/144] do_ioctl+0x78/0x90 [vfs_ioctl+92/672] vfs_ioctl+0x5c/0x2a0 [sys_ioctl+114/144] sys_ioctl+0x72/0x90 [sysenter_past_esp+105/169] sysenter_past_esp+0x69/0xa9 === There are a few Ubuntu bug reports that describe the problem, with some log files and other useful info: https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/32415 https://launchpad.net/ubuntu/+source/bluez-utils/+bug/66884/ I have found similar descriptions in other distros. I have exactly the same experience as Vincent Fortier described (keyboard working at boot, some keys repeating sometimes, keyboard unresponsive when bluetooth comes up, keyboard works again after dongle unplug/replug, but no bluetooth) Anyway, is this a kernel problem or is bluez-utils to blame? PS: I bumped into this topic when googling for 046d:c70e. I'm not a developer (I'm what they call a user), but I'm not afraid to get my hands dirty. If you want me to run debug versions or patched kernels, I can do that. After all, I have the hardware and I might give you valuable information (even if I wouldn't recognise it when it spat me in the face). -- Amedee Van Gasse [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
(added Marcel to CC) On Mon, 5 Mar 2007, Amedee Van Gasse wrote: It _appears_ that the bug reports started after an update of bluez-utils, but this remains to be confirmed. It could be coincidence/temporal correlation (which does not imply causation). This would be in fact very interesting to know. 1) does the BUG trigger only with newer versions of bluez-utils? 2) If so, does everything work with these older versions, or do the things fail in a same way, but silently? Anyway, is this a kernel problem or is bluez-utils to blame? I would bet that the problem is that we don't know yet the correct vendor-specific report that is needed to be sent to the dongle to switch from HID to HCI mode. PS: I bumped into this topic when googling for 046d:c70e. I'm not a developer (I'm what they call a user), but I'm not afraid to get my hands dirty. If you want me to run debug versions or patched kernels, I can do that. After all, I have the hardware and I might give you valuable information (even if I wouldn't recognise it when it spat me in the face). Would you also be capable of catching the report which switches the dongle from HID to HCI in other operating system, for which there already is a support? 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/
RE: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
Hi Jiri, Actually I don't know... Let me test this. Here is the scenario: 1) If I plug my USB dongle after my system has booted, everything works fine (except that the keyboard repeats a few keys somethimes..) 2) If the dongle is already plugged at boot-time, there is a BUG echo in the dmesg when the bluetooth service fires up. This make both the mouse and keyboard unresponsive until I finally unplug / replug the dongle hence going back at state 1) I never run the hid2hci command manually but the bluetooth init script seems to do so. Quick test: 1- unplug/plug back the dongle to get back to state 1) The keyboard and mouse do work has expected... 2- Now run the hid2hci command has root [EMAIL PROTECTED] init.d]# hid2hci Switching device 046d:c70a to HCI mode was successful Switching device 046d:c70e to HCI mode was successful DMESG: input: Logitech Logitech BT Mini-Receiver as /class/input/input15 input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.3 BUG: warning: (value > m) at drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) [] dump_trace+0x69/0x1b6 [] show_trace_log_lvl+0x18/0x2c [] show_trace+0xf/0x11 [] dump_stack+0x15/0x17 [] hid_output_report+0x23c/0x2e7 [] hid_submit_ctrl+0x4c/0x1d9 [] hid_submit_report+0x134/0x15f [] hiddev_ioctl+0x327/0x88a [] do_ioctl+0x4c/0x62 [] vfs_ioctl+0x24a/0x25c [] sys_ioctl+0x4c/0x66 [] syscall_call+0x7/0xb [<001e8402>] 0x1e8402 === BUG: warning: 3) Now repeat step 1): === usb 4-6.2.2.1.2.1: new full speed USB device using ehci_hcd and address 24 usb 4-6.2.2.1.2.1: configuration #1 chosen from 1 choice usb 4-6.2.2.1.2: USB disconnect, address 21 usb 4-6.2.2.1.2.1: USB disconnect, address 24 usb 4-6.2.2.1.2.2: USB disconnect, address 22 usb 4-6.2.2.1.2.3: USB disconnect, address 23 usb 4-6.2.2.1.2: new full speed USB device using ehci_hcd and address 25 usb 4-6.2.2.1.2: configuration #1 chosen from 1 choice hub 4-6.2.2.1.2:1.0: USB hub found hub 4-6.2.2.1.2:1.0: 3 ports detected usb 4-6.2.2.1.2.1: new full speed USB device using ehci_hcd and address 26 usb 4-6.2.2.1.2.1: configuration #1 chosen from 1 choice usb 4-6.2.2.1.2.2: new full speed USB device using ehci_hcd and address 27 usb 4-6.2.2.1.2.2: configuration #1 chosen from 1 choice input: Logitech Logitech BT Mini-Receiver as /class/input/input16 input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.2 usb 4-6.2.2.1.2.3: new full speed USB device using ehci_hcd and address 28 usb 4-6.2.2.1.2.3: configuration #1 chosen from 1 choice input: Logitech Logitech BT Mini-Receiver as /class/input/input17 input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.3 So yes, it looks like a hid2hci BUG or kernel BUG initiated by the hid2hci command. - vin > -Message d'origine- > De : Jiri Kosina [mailto:[EMAIL PROTECTED] > Envoyé : 27 février 2007 11:15 > À : Fortier,Vincent [Montreal] > Objet : RE: Boot time Bluetooth BUG: warning: (value > m) at > hid-core.c:793 > > On Tue, 27 Feb 2007, Fortier,Vincent [Montreal] wrote: > > > Actually it's the first time I'm trying this keyboard and mouse. > > And I guess when you use it in HID mode (i.e. when the > hid2hci command is not run), then keyboard and mouse work > with no errors reported in the kernel logs, and all the > buttons work correctly, am I right? > > -- > 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/
RE: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
> > we understand the original CSR HID proxy dongles, but for the Logitech > ones, it is wild guesses. The current support in hid2hci has been > tested on Logitech diNovo first generation and I have no other > Logitech hardware to verify it with. We might simply need > the full HID report descriptor to see who is at fault. > > As far as I can see from a quick look, the device IDs are > unchanged (0x046d/0xc70e for the keyboard), but the report > descriptor seems to differ from the one you have at > http://www.holtmann.org/linux/bluetooth/logitech.html - that > seems pretty sad. > > What puzzles me a bit is a fact that both the bugreporters > seem to state pretty clearly that this started happening > after some update, am I right? > > Or did the hardware before work all the time in the HID mode, > without even being attempted to switch to HCI (which seems to > cause the bug)? > Actually it's the first time I'm trying this keyboard and mouse. - vin - 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Mon, 19 Feb 2007, Marcel Holtmann wrote: > we understand the original CSR HID proxy dongles, but for the Logitech > ones, it is wild guesses. The current support in hid2hci has been tested > on Logitech diNovo first generation and I have no other Logitech > hardware to verify it with. We might simply need the full HID report > descriptor to see who is at fault. As far as I can see from a quick look, the device IDs are unchanged (0x046d/0xc70e for the keyboard), but the report descriptor seems to differ from the one you have at http://www.holtmann.org/linux/bluetooth/logitech.html - that seems pretty sad. What puzzles me a bit is a fact that both the bugreporters seem to state pretty clearly that this started happening after some update, am I right? Or did the hardware before work all the time in the HID mode, without even being attempted to switch to HCI (which seems to cause the bug)? -- 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Mon, 19 Feb 2007, Marcel Holtmann wrote: we understand the original CSR HID proxy dongles, but for the Logitech ones, it is wild guesses. The current support in hid2hci has been tested on Logitech diNovo first generation and I have no other Logitech hardware to verify it with. We might simply need the full HID report descriptor to see who is at fault. As far as I can see from a quick look, the device IDs are unchanged (0x046d/0xc70e for the keyboard), but the report descriptor seems to differ from the one you have at http://www.holtmann.org/linux/bluetooth/logitech.html - that seems pretty sad. What puzzles me a bit is a fact that both the bugreporters seem to state pretty clearly that this started happening after some update, am I right? Or did the hardware before work all the time in the HID mode, without even being attempted to switch to HCI (which seems to cause the bug)? -- 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/
RE: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
we understand the original CSR HID proxy dongles, but for the Logitech ones, it is wild guesses. The current support in hid2hci has been tested on Logitech diNovo first generation and I have no other Logitech hardware to verify it with. We might simply need the full HID report descriptor to see who is at fault. As far as I can see from a quick look, the device IDs are unchanged (0x046d/0xc70e for the keyboard), but the report descriptor seems to differ from the one you have at http://www.holtmann.org/linux/bluetooth/logitech.html - that seems pretty sad. What puzzles me a bit is a fact that both the bugreporters seem to state pretty clearly that this started happening after some update, am I right? Or did the hardware before work all the time in the HID mode, without even being attempted to switch to HCI (which seems to cause the bug)? Actually it's the first time I'm trying this keyboard and mouse. - vin - 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/
RE: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
Hi Jiri, Actually I don't know... Let me test this. Here is the scenario: 1) If I plug my USB dongle after my system has booted, everything works fine (except that the keyboard repeats a few keys somethimes..) 2) If the dongle is already plugged at boot-time, there is a BUG echo in the dmesg when the bluetooth service fires up. This make both the mouse and keyboard unresponsive until I finally unplug / replug the dongle hence going back at state 1) I never run the hid2hci command manually but the bluetooth init script seems to do so. Quick test: 1- unplug/plug back the dongle to get back to state 1) The keyboard and mouse do work has expected... 2- Now run the hid2hci command has root [EMAIL PROTECTED] init.d]# hid2hci Switching device 046d:c70a to HCI mode was successful Switching device 046d:c70e to HCI mode was successful DMESG: input: Logitech Logitech BT Mini-Receiver as /class/input/input15 input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.3 BUG: warning: (value m) at drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) [c0405018] dump_trace+0x69/0x1b6 [c040517d] show_trace_log_lvl+0x18/0x2c [c0405778] show_trace+0xf/0x11 [c0405875] dump_stack+0x15/0x17 [c05993c0] hid_output_report+0x23c/0x2e7 [c05994b7] hid_submit_ctrl+0x4c/0x1d9 [c05997fd] hid_submit_report+0x134/0x15f [c059bd09] hiddev_ioctl+0x327/0x88a [c04802c8] do_ioctl+0x4c/0x62 [c0480528] vfs_ioctl+0x24a/0x25c [c0480586] sys_ioctl+0x4c/0x66 [c040404b] syscall_call+0x7/0xb [001e8402] 0x1e8402 === BUG: warning: 3) Now repeat step 1): === usb 4-6.2.2.1.2.1: new full speed USB device using ehci_hcd and address 24 usb 4-6.2.2.1.2.1: configuration #1 chosen from 1 choice usb 4-6.2.2.1.2: USB disconnect, address 21 usb 4-6.2.2.1.2.1: USB disconnect, address 24 usb 4-6.2.2.1.2.2: USB disconnect, address 22 usb 4-6.2.2.1.2.3: USB disconnect, address 23 usb 4-6.2.2.1.2: new full speed USB device using ehci_hcd and address 25 usb 4-6.2.2.1.2: configuration #1 chosen from 1 choice hub 4-6.2.2.1.2:1.0: USB hub found hub 4-6.2.2.1.2:1.0: 3 ports detected usb 4-6.2.2.1.2.1: new full speed USB device using ehci_hcd and address 26 usb 4-6.2.2.1.2.1: configuration #1 chosen from 1 choice usb 4-6.2.2.1.2.2: new full speed USB device using ehci_hcd and address 27 usb 4-6.2.2.1.2.2: configuration #1 chosen from 1 choice input: Logitech Logitech BT Mini-Receiver as /class/input/input16 input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.2 usb 4-6.2.2.1.2.3: new full speed USB device using ehci_hcd and address 28 usb 4-6.2.2.1.2.3: configuration #1 chosen from 1 choice input: Logitech Logitech BT Mini-Receiver as /class/input/input17 input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.3 So yes, it looks like a hid2hci BUG or kernel BUG initiated by the hid2hci command. - vin -Message d'origine- De : Jiri Kosina [mailto:[EMAIL PROTECTED] Envoyé : 27 février 2007 11:15 À : Fortier,Vincent [Montreal] Objet : RE: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793 On Tue, 27 Feb 2007, Fortier,Vincent [Montreal] wrote: Actually it's the first time I'm trying this keyboard and mouse. And I guess when you use it in HID mode (i.e. when the hid2hci command is not run), then keyboard and mouse work with no errors reported in the kernel logs, and all the buttons work correctly, am I right? -- 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Thu, 22 Feb 2007, Veronique & Vincent wrote: > > > - report descriptor dump - seems to be missing in the output (it > > > should read something like "hid-core.c: report descriptor (size > > > XY, read YZ) = ... some hexadecimal numbers". This should be > > > output by the time the HID device is connected. > The full dmesg with define DEBUG was included in the original message. > Unless > something else was needed? Unfortunately it was missing the report descriptor dump. The output should look like drivers/usb/input/hid-core.c: report descriptor (size 59, read 59) = 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 75 01 95 08 81 02 81 03 95 05 05 08 19 01 29 05 91 02 95 01 75 03 91 01 95 06 75 08 15 00 26 a4 00 05 07 19 00 2a a4 00 81 00 c0 and it should appear as soon as you connect the device. If it didn't, I suspect that the #define DEBUG_DATA was not set properly in drivers/usb/input/hid-core.c (only defining DEBUG is not enough for report descriptor dump to appear). > I was actually getting that on a stock FC6 kernel. The dmesg output > comes from a recompiled vanilla 2.6.19.x with the exact same > configuration BUT the modified define's in hid-core.c and a local > version appended to the .config file. So this BUG does not only affect > FC6 users but also the vanilla kernel. But so far all reports that have gathered for this bug at me seem to come from FC6 ... does hid2hci by any chance in FC6 have any additional patches that could be causing it, instead of being a kernel issue? 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
> > > > I've set up the hid-core.c to DEBUG mode... and it literally got pretty verbose... > > > thanks for the output. Is this really the full output? The important part > > - report descriptor dump - seems to be missing in the output (it should > > read something like "hid-core.c: report descriptor (size XY, read YZ) = > > ... some hexadecimal numbers". This should be output by the time the HID > > device is connected. The full dmesg with define DEBUG was included in the original message. Unless something else was needed? > Can I get something useful without a kernel recompile, with something > like evtest? I have users on Fedora hitting this too. It very likely is > a regression caused by the new unified HID. I was actually getting that on a stock FC6 kernel. The dmesg output comes from a recompiled vanilla 2.6.19.x with the exact same configuration BUT the modified define's in hid-core.c and a local version appended to the .config file. So this BUG does not only affect FC6 users but also the vanilla kernel. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227598 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228755 Good thing, I've added myself to the CC list of both. > > -- Pete > - vin - 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Wed, 21 Feb 2007, Pete Zaitcev wrote:
> Can I get something useful without a kernel recompile, with something
> like evtest? I have users on Fedora hitting this too. It very likely is
> a regression caused by the new unified HID.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227598
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228755
Hi Pete,
I don't think that this is caused by the newly introduced generic HID
layer - I can see that both the bugreports in RH bugzilla are reported
against 2.6.19-1.2895.fc6. I have downloaded the source RPM and discovered
that these kernels are based on vanilla 2.6.19.2 - these kernels didn't
have generic HID layer yet, so this can't be the case.
The thing is that hid2hci sends through hiddev some excessivelly large
value, and HID subsystem then complains about it. It could be that the
device has a broken report descriptor (*), which results in buggy behavior
of sw.
It would be really nice to get the report descriptor - Vincent, it wasn't
in your output. There is a following code in drivers/usb/input/hid-core.c
#ifdef DEBUG_DATA
printk(KERN_DEBUG __FILE__ ": report descriptor (size %u, read %d) = ",
rsize, n);
for (n = 0; n < rsize; n++)
printk(" %02x", (unsigned char) rdesc[n]);
printk("\n");
#endif
Could you make sure that you really compiled this file with
#define DEBUG_DATA
so that you get this output upon connection of new USB HID device?
(*) Which looks quite probable to me - I have been playing yesterday with
another masterpiece from Logitech (S510 keyboard), which also requires
fixing its report descriptor on-the-fly because it is fully usable :(
--
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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Wed, 21 Feb 2007, Pete Zaitcev wrote: Can I get something useful without a kernel recompile, with something like evtest? I have users on Fedora hitting this too. It very likely is a regression caused by the new unified HID. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227598 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228755 Hi Pete, I don't think that this is caused by the newly introduced generic HID layer - I can see that both the bugreports in RH bugzilla are reported against 2.6.19-1.2895.fc6. I have downloaded the source RPM and discovered that these kernels are based on vanilla 2.6.19.2 - these kernels didn't have generic HID layer yet, so this can't be the case. The thing is that hid2hci sends through hiddev some excessivelly large value, and HID subsystem then complains about it. It could be that the device has a broken report descriptor (*), which results in buggy behavior of sw. It would be really nice to get the report descriptor - Vincent, it wasn't in your output. There is a following code in drivers/usb/input/hid-core.c #ifdef DEBUG_DATA printk(KERN_DEBUG __FILE__ : report descriptor (size %u, read %d) = , rsize, n); for (n = 0; n rsize; n++) printk( %02x, (unsigned char) rdesc[n]); printk(\n); #endif Could you make sure that you really compiled this file with #define DEBUG_DATA so that you get this output upon connection of new USB HID device? (*) Which looks quite probable to me - I have been playing yesterday with another masterpiece from Logitech (S510 keyboard), which also requires fixing its report descriptor on-the-fly because it is fully usable :( -- 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
I've set up the hid-core.c to DEBUG mode... and it literally got pretty verbose... thanks for the output. Is this really the full output? The important part - report descriptor dump - seems to be missing in the output (it should read something like hid-core.c: report descriptor (size XY, read YZ) = ... some hexadecimal numbers. This should be output by the time the HID device is connected. The full dmesg with define DEBUG was included in the original message. Unless something else was needed? Can I get something useful without a kernel recompile, with something like evtest? I have users on Fedora hitting this too. It very likely is a regression caused by the new unified HID. I was actually getting that on a stock FC6 kernel. The dmesg output comes from a recompiled vanilla 2.6.19.x with the exact same configuration BUT the modified define's in hid-core.c and a local version appended to the .config file. So this BUG does not only affect FC6 users but also the vanilla kernel. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227598 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228755 Good thing, I've added myself to the CC list of both. -- Pete - vin - 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Thu, 22 Feb 2007, Veronique Vincent wrote: - report descriptor dump - seems to be missing in the output (it should read something like hid-core.c: report descriptor (size XY, read YZ) = ... some hexadecimal numbers. This should be output by the time the HID device is connected. The full dmesg with define DEBUG was included in the original message. Unless something else was needed? Unfortunately it was missing the report descriptor dump. The output should look like drivers/usb/input/hid-core.c: report descriptor (size 59, read 59) = 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 75 01 95 08 81 02 81 03 95 05 05 08 19 01 29 05 91 02 95 01 75 03 91 01 95 06 75 08 15 00 26 a4 00 05 07 19 00 2a a4 00 81 00 c0 and it should appear as soon as you connect the device. If it didn't, I suspect that the #define DEBUG_DATA was not set properly in drivers/usb/input/hid-core.c (only defining DEBUG is not enough for report descriptor dump to appear). I was actually getting that on a stock FC6 kernel. The dmesg output comes from a recompiled vanilla 2.6.19.x with the exact same configuration BUT the modified define's in hid-core.c and a local version appended to the .config file. So this BUG does not only affect FC6 users but also the vanilla kernel. But so far all reports that have gathered for this bug at me seem to come from FC6 ... does hid2hci by any chance in FC6 have any additional patches that could be causing it, instead of being a kernel issue? 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Tue, 20 Feb 2007 09:02:53 +0100 (CET), Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Mon, 19 Feb 2007, Veronique & Vincent wrote: > > Hi again Marcel and Jiri, > > I've set up the hid-core.c to DEBUG mode... and it literally got pretty > > verbose... > thanks for the output. Is this really the full output? The important part > - report descriptor dump - seems to be missing in the output (it should > read something like "hid-core.c: report descriptor (size XY, read YZ) = > ... some hexadecimal numbers". This should be output by the time the HID > device is connected. Can I get something useful without a kernel recompile, with something like evtest? I have users on Fedora hitting this too. It very likely is a regression caused by the new unified HID. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227598 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228755 -- Pete - 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Tue, 20 Feb 2007 09:02:53 +0100 (CET), Jiri Kosina [EMAIL PROTECTED] wrote: On Mon, 19 Feb 2007, Veronique Vincent wrote: Hi again Marcel and Jiri, I've set up the hid-core.c to DEBUG mode... and it literally got pretty verbose... thanks for the output. Is this really the full output? The important part - report descriptor dump - seems to be missing in the output (it should read something like hid-core.c: report descriptor (size XY, read YZ) = ... some hexadecimal numbers. This should be output by the time the HID device is connected. Can I get something useful without a kernel recompile, with something like evtest? I have users on Fedora hitting this too. It very likely is a regression caused by the new unified HID. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227598 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228755 -- Pete - 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/
Re: Fwd: RE: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Mon, 19 Feb 2007, Veronique & Vincent wrote: > Hi again Marcel and Jiri, > I've set up the hid-core.c to DEBUG mode... and it literally got pretty > verbose... Vincent, thanks for the output. Is this really the full output? The important part - report descriptor dump - seems to be missing in the output (it should read something like "hid-core.c: report descriptor (size XY, read YZ) = ... some hexadecimal numbers". This should be output by the time the HID device is connected. This output is generated in usb_hid_configure() function in hid-core.c -- 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/
Re: Fwd: RE: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Mon, 19 Feb 2007, Veronique Vincent wrote: Hi again Marcel and Jiri, I've set up the hid-core.c to DEBUG mode... and it literally got pretty verbose... Vincent, thanks for the output. Is this really the full output? The important part - report descriptor dump - seems to be missing in the output (it should read something like hid-core.c: report descriptor (size XY, read YZ) = ... some hexadecimal numbers. This should be output by the time the HID device is connected. This output is generated in usb_hid_configure() function in hid-core.c -- 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/
Fwd: RE: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
00 00 2286 hid-debug: input Button.0001 = 0 2287 hid-debug: input Button.0002 = 0 2288 hid-debug: input Button.0003 = 0 2289 hid-debug: input Button.0004 = 0 2290 hid-debug: input Button.0005 = 0 2291 hid-debug: input Button.0006 = 0 2292 hid-debug: input Button.0007 = 0 2293 hid-debug: input Button.0008 = 0 2294 hid-debug: input GenericDesktop.X = 0 2295 hid-debug: input GenericDesktop.Y = 0 2296 hid-debug: input GenericDesktop.Wheel = 0 2297 hid-debug: input Consumer.HorizontalWheel = 0 2298 hid-debug: input Button.0009 = 0 2299 hid-debug: input Button.000a = 0 2300 hid-debug: input Button.000b = 0 2301 hid-debug: input Button.000c = 0 2302 drivers/usb/input/hid-core.c: report (size 8) (unnumbered) 2303 drivers/usb/input/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 2304 hid-debug: input Keyboard.00e0 = 0 2305 hid-debug: input Keyboard.00e1 = 0 2306 hid-debug: input Keyboard.00e2 = 0 2307 hid-debug: input Keyboard.00e3 = 0 2308 hid-debug: input Keyboard.00e4 = 0 2309 hid-debug: input Keyboard.00e5 = 0 2310 hid-debug: input Keyboard.00e6 = 0 2311 hid-debug: input Keyboard.00e7 = 0 2312 drivers/usb/input/hid-core.c: report (size 5) (numbered) 2313 drivers/usb/input/hid-core.c: report 3 (size 4) = 00 00 00 00 2314 drivers/usb/input/hid-core.c: report (size 7) (numbered) 2315 drivers/usb/input/hid-core.c: report 16 (size 6) = ff 44 01 00 00 00 2316 hid-debug: input 01a1.0109 = 1 2317 hid-debug: input c06a.8f60 = 0 2318 drivers/usb/input/hid-core.c: report (size 2) (numbered) 2319 drivers/usb/input/hid-core.c: report 4 (size 1) = 00 2320 drivers/usb/input/hid-core.c: report (size 8) (unnumbered) 2321 drivers/usb/input/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 2322 hid-debug: input Keyboard.00e0 = 0 2323 hid-debug: input Keyboard.00e1 = 0 2324 hid-debug: input Keyboard.00e2 = 0 2325 hid-debug: input Keyboard.00e3 = 0 2326 hid-debug: input Keyboard.00e4 = 0 2327 hid-debug: input Keyboard.00e5 = 0 2328 hid-debug: input Keyboard.00e6 = 0 2329 hid-debug: input Keyboard.00e7 = 0 2330 Bluetooth: HIDP (Human Interface Emulation) ver 1.1 2331 drivers/usb/input/hid-core.c: report (size 8) (unnumbered) 2332 drivers/usb/input/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 2333 hid-debug: input Keyboard.00e0 = 0 2334 hid-debug: input Keyboard.00e1 = 0 2335 hid-debug: input Keyboard.00e2 = 0 2336 hid-debug: input Keyboard.00e3 = 0 2337 hid-debug: input Keyboard.00e4 = 0 2338 hid-debug: input Keyboard.00e5 = 0 2339 hid-debug: input Keyboard.00e6 = 0 2340 hid-debug: input Keyboard.00e7 = 0 2341 drivers/usb/input/hid-core.c: report (size 8) (unnumbered) 2342 drivers/usb/input/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 2343 hid-debug: input Keyboard.00e0 = 0 2344 hid-debug: input Keyboard.00e1 = 0 2345 hid-debug: input Keyboard.00e2 = 0 2346 hid-debug: input Keyboard.00e3 = 0 2347 hid-debug: input Keyboard.00e4 = 0 2348 hid-debug: input Keyboard.00e5 = 0 2349 hid-debug: input Keyboard.00e6 = 0 2350 hid-debug: input Keyboard.00e7 = 0 - vin -- Message transmis -- Sujet : RE: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793 Date : lundi 19 février 2007 De : "Fortier,Vincent [Montreal]" <[EMAIL PROTECTED]> À : Jiri Kosina <[EMAIL PROTECTED]>, Marcel Holtmann <[EMAIL PROTECTED]> Hi Macel and Jiri, Thnx for answering! I'll recompile my kernel when I'll be back home. Do you want me to keep my 2.6.19, switch to 2.6.20 or 2.6.21-rcX-gitYZ ? Thnx. Note: Added my home address in CC. - vin > -Message d'origine- > De : Jiri Kosina [mailto:[EMAIL PROTECTED] > Envoyé : 19 février 2007 04:37 > À : Marcel Holtmann > Cc : Fortier,Vincent [Montreal]; linux-kernel@vger.kernel.org > Objet : Re: Boot time Bluetooth BUG: warning: (value > m) at > hid-core.c:793 > > On Mon, 19 Feb 2007, Marcel Holtmann wrote: > > > we understand the original CSR HID proxy dongles, but for > the Logitech > > ones, it is wild guesses. The current support in hid2hci has been > > tested on Logitech diNovo first generation and I have no other > > Logitech hardware to verify it with. We might simply need > the full HID > > report descriptor to see who is at fault. > > Vincent, > > from the stacktrace it seems that you are using pre-2.6.20 > kernel. Could you please compile kernel with the following > changes in drivers/usb/input/hid-core.c > > - comment the #undef DEBUG and #undef DEBUG_DATA > - add #define DEBUG and #define DEBUG_DATA > > and send us the output? > > -- > Jiri Kosina > --- dmesg.2.6.19-DEBUG.gz Description: GNU Zip compressed data
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Mon, 19 Feb 2007, Marcel Holtmann wrote: > we understand the original CSR HID proxy dongles, but for the Logitech > ones, it is wild guesses. The current support in hid2hci has been tested > on Logitech diNovo first generation and I have no other Logitech > hardware to verify it with. We might simply need the full HID report > descriptor to see who is at fault. Vincent, from the stacktrace it seems that you are using pre-2.6.20 kernel. Could you please compile kernel with the following changes in drivers/usb/input/hid-core.c - comment the #undef DEBUG and #undef DEBUG_DATA - add #define DEBUG and #define DEBUG_DATA and send us the output? -- 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Mon, 19 Feb 2007, Marcel Holtmann wrote: we understand the original CSR HID proxy dongles, but for the Logitech ones, it is wild guesses. The current support in hid2hci has been tested on Logitech diNovo first generation and I have no other Logitech hardware to verify it with. We might simply need the full HID report descriptor to see who is at fault. Vincent, from the stacktrace it seems that you are using pre-2.6.20 kernel. Could you please compile kernel with the following changes in drivers/usb/input/hid-core.c - comment the #undef DEBUG and #undef DEBUG_DATA - add #define DEBUG and #define DEBUG_DATA and send us the output? -- 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/
Fwd: RE: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
Keyboard.00e7 = 0 2281 usb 2-2.1: configuration #1 chosen from 1 choice 2282 Bluetooth: HCI USB driver ver 2.9 2283 usbcore: registered new interface driver hci_usb 2284 drivers/usb/input/hid-core.c: report (size 7) (numbered) 2285 drivers/usb/input/hid-core.c: report 2 (size 6) = 00 00 00 00 00 00 2286 hid-debug: input Button.0001 = 0 2287 hid-debug: input Button.0002 = 0 2288 hid-debug: input Button.0003 = 0 2289 hid-debug: input Button.0004 = 0 2290 hid-debug: input Button.0005 = 0 2291 hid-debug: input Button.0006 = 0 2292 hid-debug: input Button.0007 = 0 2293 hid-debug: input Button.0008 = 0 2294 hid-debug: input GenericDesktop.X = 0 2295 hid-debug: input GenericDesktop.Y = 0 2296 hid-debug: input GenericDesktop.Wheel = 0 2297 hid-debug: input Consumer.HorizontalWheel = 0 2298 hid-debug: input Button.0009 = 0 2299 hid-debug: input Button.000a = 0 2300 hid-debug: input Button.000b = 0 2301 hid-debug: input Button.000c = 0 2302 drivers/usb/input/hid-core.c: report (size 8) (unnumbered) 2303 drivers/usb/input/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 2304 hid-debug: input Keyboard.00e0 = 0 2305 hid-debug: input Keyboard.00e1 = 0 2306 hid-debug: input Keyboard.00e2 = 0 2307 hid-debug: input Keyboard.00e3 = 0 2308 hid-debug: input Keyboard.00e4 = 0 2309 hid-debug: input Keyboard.00e5 = 0 2310 hid-debug: input Keyboard.00e6 = 0 2311 hid-debug: input Keyboard.00e7 = 0 2312 drivers/usb/input/hid-core.c: report (size 5) (numbered) 2313 drivers/usb/input/hid-core.c: report 3 (size 4) = 00 00 00 00 2314 drivers/usb/input/hid-core.c: report (size 7) (numbered) 2315 drivers/usb/input/hid-core.c: report 16 (size 6) = ff 44 01 00 00 00 2316 hid-debug: input 01a1.0109 = 1 2317 hid-debug: input c06a.8f60 = 0 2318 drivers/usb/input/hid-core.c: report (size 2) (numbered) 2319 drivers/usb/input/hid-core.c: report 4 (size 1) = 00 2320 drivers/usb/input/hid-core.c: report (size 8) (unnumbered) 2321 drivers/usb/input/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 2322 hid-debug: input Keyboard.00e0 = 0 2323 hid-debug: input Keyboard.00e1 = 0 2324 hid-debug: input Keyboard.00e2 = 0 2325 hid-debug: input Keyboard.00e3 = 0 2326 hid-debug: input Keyboard.00e4 = 0 2327 hid-debug: input Keyboard.00e5 = 0 2328 hid-debug: input Keyboard.00e6 = 0 2329 hid-debug: input Keyboard.00e7 = 0 2330 Bluetooth: HIDP (Human Interface Emulation) ver 1.1 2331 drivers/usb/input/hid-core.c: report (size 8) (unnumbered) 2332 drivers/usb/input/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 2333 hid-debug: input Keyboard.00e0 = 0 2334 hid-debug: input Keyboard.00e1 = 0 2335 hid-debug: input Keyboard.00e2 = 0 2336 hid-debug: input Keyboard.00e3 = 0 2337 hid-debug: input Keyboard.00e4 = 0 2338 hid-debug: input Keyboard.00e5 = 0 2339 hid-debug: input Keyboard.00e6 = 0 2340 hid-debug: input Keyboard.00e7 = 0 2341 drivers/usb/input/hid-core.c: report (size 8) (unnumbered) 2342 drivers/usb/input/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 2343 hid-debug: input Keyboard.00e0 = 0 2344 hid-debug: input Keyboard.00e1 = 0 2345 hid-debug: input Keyboard.00e2 = 0 2346 hid-debug: input Keyboard.00e3 = 0 2347 hid-debug: input Keyboard.00e4 = 0 2348 hid-debug: input Keyboard.00e5 = 0 2349 hid-debug: input Keyboard.00e6 = 0 2350 hid-debug: input Keyboard.00e7 = 0 - vin -- Message transmis -- Sujet : RE: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793 Date : lundi 19 février 2007 De : Fortier,Vincent [Montreal] [EMAIL PROTECTED] À : Jiri Kosina [EMAIL PROTECTED], Marcel Holtmann [EMAIL PROTECTED] Hi Macel and Jiri, Thnx for answering! I'll recompile my kernel when I'll be back home. Do you want me to keep my 2.6.19, switch to 2.6.20 or 2.6.21-rcX-gitYZ ? Thnx. Note: Added my home address in CC. - vin -Message d'origine- De : Jiri Kosina [mailto:[EMAIL PROTECTED] Envoyé : 19 février 2007 04:37 À : Marcel Holtmann Cc : Fortier,Vincent [Montreal]; linux-kernel@vger.kernel.org Objet : Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793 On Mon, 19 Feb 2007, Marcel Holtmann wrote: we understand the original CSR HID proxy dongles, but for the Logitech ones, it is wild guesses. The current support in hid2hci has been tested on Logitech diNovo first generation and I have no other Logitech hardware to verify it with. We might simply need the full HID report descriptor to see who is at fault. Vincent, from the stacktrace it seems that you are using pre-2.6.20 kernel. Could you please compile kernel with the following changes in drivers/usb/input/hid-core.c - comment the #undef DEBUG and #undef DEBUG_DATA - add #define DEBUG and #define DEBUG_DATA and send us the output? -- Jiri Kosina --- dmesg.2.6.19-DEBUG.gz Description: GNU Zip compressed data
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
Hi Jiri, > > I m using a Logitech MX 5000 keyboard with an included MX 1000 mouse, > > both bluetooth using the same USB reciever. > > When the USB reciever is already plugged-in at boot-time and the > > Bluetooth service fires-up I get this message: > > === > > BUG: warning: (value > m) at > > drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) > > [] dump_trace+0x69/0x1b6 > > [] show_trace_log_lvl+0x18/0x2c > > [] show_trace+0xf/0x11 > > [] dump_stack+0x15/0x17 > > [] hid_output_report+0x23c/0x2e7 > > [] hid_submit_ctrl+0x4c/0x1d9 > > [] hid_submit_report+0x134/0x15f > > [] hiddev_ioctl+0x327/0x88a > > [] do_ioctl+0x4c/0x62 > > [] vfs_ioctl+0x24a/0x25c > > [] sys_ioctl+0x4c/0x66 > > [] syscall_call+0x7/0xb > > [<005b5402>] 0x5b5402 > > === > > (added Marcel to CC) > > This means that something (I guess that it's hid2hci command?) is trying > to pass through hiddev a value in a field that is greater than a given > bitmask (and is not going to fit into the bitfield). > > Vincent, does the problem go away when you don't use bluetooth (both > keyboard and mouse is switched to HID mode, if they support it)? > > Marcel, do you have any idea how this could happen? we understand the original CSR HID proxy dongles, but for the Logitech ones, it is wild guesses. The current support in hid2hci has been tested on Logitech diNovo first generation and I have no other Logitech hardware to verify it with. We might simply need the full HID report descriptor to see who is at fault. Regards Marcel - 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/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Fri, 16 Feb 2007, Fortier,Vincent [Montreal] wrote: > I m using a Logitech MX 5000 keyboard with an included MX 1000 mouse, > both bluetooth using the same USB reciever. > When the USB reciever is already plugged-in at boot-time and the > Bluetooth service fires-up I get this message: > === > BUG: warning: (value > m) at > drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) > [] dump_trace+0x69/0x1b6 > [] show_trace_log_lvl+0x18/0x2c > [] show_trace+0xf/0x11 > [] dump_stack+0x15/0x17 > [] hid_output_report+0x23c/0x2e7 > [] hid_submit_ctrl+0x4c/0x1d9 > [] hid_submit_report+0x134/0x15f > [] hiddev_ioctl+0x327/0x88a > [] do_ioctl+0x4c/0x62 > [] vfs_ioctl+0x24a/0x25c > [] sys_ioctl+0x4c/0x66 > [] syscall_call+0x7/0xb > [<005b5402>] 0x5b5402 > === (added Marcel to CC) This means that something (I guess that it's hid2hci command?) is trying to pass through hiddev a value in a field that is greater than a given bitmask (and is not going to fit into the bitfield). Vincent, does the problem go away when you don't use bluetooth (both keyboard and mouse is switched to HID mode, if they support it)? Marcel, do you have any idea how this could happen? 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
On Fri, 16 Feb 2007, Fortier,Vincent [Montreal] wrote: I m using a Logitech MX 5000 keyboard with an included MX 1000 mouse, both bluetooth using the same USB reciever. When the USB reciever is already plugged-in at boot-time and the Bluetooth service fires-up I get this message: === BUG: warning: (value m) at drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) [c0405018] dump_trace+0x69/0x1b6 [c040517d] show_trace_log_lvl+0x18/0x2c [c0405778] show_trace+0xf/0x11 [c0405875] dump_stack+0x15/0x17 [c05993c0] hid_output_report+0x23c/0x2e7 [c05994b7] hid_submit_ctrl+0x4c/0x1d9 [c05997fd] hid_submit_report+0x134/0x15f [c059bd09] hiddev_ioctl+0x327/0x88a [c04802c8] do_ioctl+0x4c/0x62 [c0480528] vfs_ioctl+0x24a/0x25c [c0480586] sys_ioctl+0x4c/0x66 [c040404b] syscall_call+0x7/0xb [005b5402] 0x5b5402 === (added Marcel to CC) This means that something (I guess that it's hid2hci command?) is trying to pass through hiddev a value in a field that is greater than a given bitmask (and is not going to fit into the bitfield). Vincent, does the problem go away when you don't use bluetooth (both keyboard and mouse is switched to HID mode, if they support it)? Marcel, do you have any idea how this could happen? 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/
Re: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
Hi Jiri, I m using a Logitech MX 5000 keyboard with an included MX 1000 mouse, both bluetooth using the same USB reciever. When the USB reciever is already plugged-in at boot-time and the Bluetooth service fires-up I get this message: === BUG: warning: (value m) at drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) [c0405018] dump_trace+0x69/0x1b6 [c040517d] show_trace_log_lvl+0x18/0x2c [c0405778] show_trace+0xf/0x11 [c0405875] dump_stack+0x15/0x17 [c05993c0] hid_output_report+0x23c/0x2e7 [c05994b7] hid_submit_ctrl+0x4c/0x1d9 [c05997fd] hid_submit_report+0x134/0x15f [c059bd09] hiddev_ioctl+0x327/0x88a [c04802c8] do_ioctl+0x4c/0x62 [c0480528] vfs_ioctl+0x24a/0x25c [c0480586] sys_ioctl+0x4c/0x66 [c040404b] syscall_call+0x7/0xb [005b5402] 0x5b5402 === (added Marcel to CC) This means that something (I guess that it's hid2hci command?) is trying to pass through hiddev a value in a field that is greater than a given bitmask (and is not going to fit into the bitfield). Vincent, does the problem go away when you don't use bluetooth (both keyboard and mouse is switched to HID mode, if they support it)? Marcel, do you have any idea how this could happen? we understand the original CSR HID proxy dongles, but for the Logitech ones, it is wild guesses. The current support in hid2hci has been tested on Logitech diNovo first generation and I have no other Logitech hardware to verify it with. We might simply need the full HID report descriptor to see who is at fault. Regards Marcel - 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/
