On Nov 29, 2007 11:03 AM, Brad Smith <[email protected]> wrote:
>
> Thank you for the reply Marvel. I use the gnome bluetooth client which
Marcel
> apparently does manage bluetooth devices using bluetooth-input-service.
> I still have the problem of the devices disappearing if idle for too
> long such as when i lock the desktop or log out for a long period.
> Sometimes I can re-enable the devices, but sometimes I cannot. This is
> frustrating.
>
> I see a the following several times in the system log if i restart
> bluetooth:
> Nov 28 18:53:39 pico kernel: WARNING: at drivers/hid/hid-core.c:784
> implement() (Tainted: P )
> Nov 28 18:53:39 pico kernel:
> Nov 28 18:53:39 pico kernel: Call Trace:
> Nov 28 18:53:39 pico kernel: [<ffffffff811d8549>] hid_output_report
> +0x1c5/0x232
> Nov 28 18:53:39 pico kernel: [<ffffffff811ddaf1>] hid_submit_ctrl
> +0x60/0x24b
> Nov 28 18:53:39 pico kernel: [<ffffffff811dde45>] usbhid_submit_report
> +0x169/0x19e
> Nov 28 18:53:39 pico kernel: [<ffffffff811e030b>] hiddev_ioctl
> +0x368/0x919
> Nov 28 18:53:39 pico kernel: [<ffffffff810f54c5>] inode_has_perm
> +0x65/0x72
> Nov 28 18:53:39 pico kernel: [<ffffffff81120c17>] __up_read+0x19/0x7f
> Nov 28 18:53:39 pico kernel: [<ffffffff8125eecc>] do_page_fault
> +0x490/0x7e4
> Nov 28 18:53:39 pico kernel: [<ffffffff810a7399>] do_ioctl+0x55/0x6b
> Nov 28 18:53:39 pico kernel: [<ffffffff810a75f2>] vfs_ioctl+0x243/0x25c
> Nov 28 18:53:39 pico kernel: [<ffffffff810a7664>] sys_ioctl+0x59/0x79
> Nov 28 18:53:39 pico kernel: [<ffffffff8100bd45>] tracesys+0xd5/0xda
>
Does bluetooth input devices have something to do with usbhid? I don't
know, perhaps this is another problem in kernel.
Please dont mind to add lkml as cc.
Regards
dave
> Brad
>
>
>
> On Mon, 2007-11-26 at 06:49 +0100, Marcel Holtmann wrote:
> > Hi Brad,
> >
> > > I have a Logitech mouse and keyboard that use bluetooth (dinovo). I
> > > have enabled bluetooth on this Fedora 8 system and both work well with
> > > two problems.
> > >
> > > (1) When I lock the system and return later the mouse no longer works.
> > > I have to open a terminal window and issue an hidd --connect command.
> > >
> > > (2) When I log out, both the mouse and keyboard stop working. I have to
> > > connect a USB mouse and USB keyboard to enter the authentication
> > > information. Once logged in the bluetooth devices usually work,
> > > although I sometimes have to issue an hidd --connect command to enable
> > > the keyboard.
> > >
> > > Any suggestions on resolving these issues would be appreciated.
> >
> > not using hidd and using bluetoothd-input-service instead is one thing.
> > For input devices to re-connect you have to have a daemon running that
> > handles this. The input service is the best way to achieve this. Check
> > the BlueZ wiki for details.
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
>
Hi Dave,
>> apparently does manage bluetooth devices using bluetooth-input-
>> service.
>> I still have the problem of the devices disappearing if idle for too
>> long such as when i lock the desktop or log out for a long period.
>> Sometimes I can re-enable the devices, but sometimes I cannot.
>> This is
>> frustrating.
>>
>> I see a the following several times in the system log if i restart
>> bluetooth:
>> Nov 28 18:53:39 pico kernel: WARNING: at drivers/hid/hid-core.c:784
>> implement() (Tainted: P )
>> Nov 28 18:53:39 pico kernel:
>> Nov 28 18:53:39 pico kernel: Call Trace:
>> Nov 28 18:53:39 pico kernel: [<ffffffff811d8549>] hid_output_report
>> +0x1c5/0x232
>> Nov 28 18:53:39 pico kernel: [<ffffffff811ddaf1>] hid_submit_ctrl
>> +0x60/0x24b
>> Nov 28 18:53:39 pico kernel: [<ffffffff811dde45>]
>> usbhid_submit_report
>> +0x169/0x19e
>> Nov 28 18:53:39 pico kernel: [<ffffffff811e030b>] hiddev_ioctl
>> +0x368/0x919
>> Nov 28 18:53:39 pico kernel: [<ffffffff810f54c5>] inode_has_perm
>> +0x65/0x72
>> Nov 28 18:53:39 pico kernel: [<ffffffff81120c17>] __up_read
>> +0x19/0x7f
>> Nov 28 18:53:39 pico kernel: [<ffffffff8125eecc>] do_page_fault
>> +0x490/0x7e4
>> Nov 28 18:53:39 pico kernel: [<ffffffff810a7399>] do_ioctl+0x55/0x6b
>> Nov 28 18:53:39 pico kernel: [<ffffffff810a75f2>] vfs_ioctl
>> +0x243/0x25c
>> Nov 28 18:53:39 pico kernel: [<ffffffff810a7664>] sys_ioctl
>> +0x59/0x79
>> Nov 28 18:53:39 pico kernel: [<ffffffff8100bd45>] tracesys+0xd5/0xda
>>
>
> Does bluetooth input devices have something to do with usbhid? I don't
> know, perhaps this is another problem in kernel.
in case you have a HID proxy dongle the usbhid driver can be involved.
And since this is hiddev, then it will be caused by the hid2hci program.
Regards
Marcel
On Thu, 29 Nov 2007, Marcel Holtmann wrote:
> > >Nov 28 18:53:39 pico kernel: WARNING: at drivers/hid/hid-core.c:784
[ ... ]
> > Does bluetooth input devices have something to do with usbhid? I don't
> > know, perhaps this is another problem in kernel.
> in case you have a HID proxy dongle the usbhid driver can be involved. And
> since this is hiddev, then it will be caused by the hid2hci program.
Absolutely.
This particular warning means, that someone (usually indeed hid2hci)
passed usage through hiddev that was out of bounds, with respect to the
device's report descriptor.
This usually means that hid2hci has chosen the wrong method to switch the
modes. Unfortunately, it's not easy to implement always the switching
properly, if we don't know the vendor-specific packet that has to be sent.
--
Jiri Kosina
On Nov 30, 2007 4:43 AM, Jiri Kosina <[email protected]> wrote:
> On Thu, 29 Nov 2007, Marcel Holtmann wrote:
>
> > > >Nov 28 18:53:39 pico kernel: WARNING: at drivers/hid/hid-core.c:784
> [ ... ]
>
> > > Does bluetooth input devices have something to do with usbhid? I don't
> > > know, perhaps this is another problem in kernel.
> > in case you have a HID proxy dongle the usbhid driver can be involved. And
> > since this is hiddev, then it will be caused by the hid2hci program.
>
> Absolutely.
>
> This particular warning means, that someone (usually indeed hid2hci)
> passed usage through hiddev that was out of bounds, with respect to the
> device's report descriptor.
Is this behaviour the normal one? IMHO, userspace program should not
cause kernel warnings like this no mater what input from users.
>
> This usually means that hid2hci has chosen the wrong method to switch the
> modes. Unfortunately, it's not easy to implement always the switching
> properly, if we don't know the vendor-specific packet that has to be sent.
>
> --
> Jiri Kosina
>
On Fri, 30 Nov 2007, Dave Young wrote:
> > This particular warning means, that someone (usually indeed hid2hci)
> > passed usage through hiddev that was out of bounds, with respect to
> > the device's report descriptor.
> Is this behaviour the normal one? IMHO, userspace program should not
> cause kernel warnings like this no mater what input from users.
It has been on my todo list to convert that WARN_ON() to something that
won't scare users that much, especially the stacktrace shouldn't certainly
be there. I will do it.
--
Jiri Kosina
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le Fri, 30 Nov 2007 09:06:52 +0800,
"Dave Young" <[email protected]> a écrit :
> On Nov 30, 2007 4:43 AM, Jiri Kosina <[email protected]> wrote:
> > On Thu, 29 Nov 2007, Marcel Holtmann wrote:
> >
Hi all,
Just for add something on this bug report, I've the same hardware
(Logitech dinovo keyboard+mouse), connected with bluetooth
hcid/bluetoothd-service-input
First of all, this work very well at first run and all the time I
interact with keyboard and mouse, very good job of the bluez stack
developpers !
But, like Brad, after an amount of inactivity (about 20 minutes
I think ...) the devices go to sleep mode and never reconnect. I need to
restart the bluetooth service at all, with another usb keyboard. My
kernel log contain the same warnings as Brad each time the service is
restarted.
Some times I've a kernel oops that kill khidp and I never can use
keyboard and mouse, need to reboot the computer ... of course I've
tried to unload the modules concerned but it's impossible.
I attach the lines of this oops for kernel hackers.
My kernel is the last 2.6.23 and I run a Gentoo up to date (bluez-libs
and utils 3.22), on an AMD64 dual core processor with 2GB of ram. The
kernel is tainted by the nvidia proprietary driver, sorry :-/ ...
the result of 'cat /proc/bus/input/devices' for the bt devices is also
attached.
I will try to use the latest patch (2.6.23-mh1) from the bluez download
site tomorrow.
This problem is present since monthes for me but just a service restart
isn't so hard to do ... but the oppsses are so annoying and more
frequent these days !!
Thanks for your attention, I hope you can solve this issue easily and
if you need some more datas and results of tests just ask me !
Best regards.
Didier LINK
- --
Didier Link <[email protected]>
Jabber : [email protected]
MSN : [email protected]
SIP : [email protected]
Clé GPG : 75BAC9EE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHWdpvkyPwinW6ye4RApiTAJ0XX2jUzT1wAT9se7jQIzHejQ5DPgCfeYF3
YCsIEHHPGM6/NoOxQd7hEQc=
=1D17
-----END PGP SIGNATURE-----