Bug 196555

Summary:	HID create error 77 (File descriptor in bad state)
Product:	[Fedora] Fedora	Reporter:	Patrick <rh_bugzilla>
Component:	bluez-utils	Assignee:	David Woodhouse <dwmw2>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	bnocera, marcel
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-02-01 14:13:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Patrick 2006-06-24 17:35:32 UTC

Description of problem:
Hidd is slow in detecting bluetooth mouse activity. It can take more than 10
seconds before the bluetooth mouse is detected again and the screen pointer
follows the movement of the bluetooth mouse.

Version-Release number of selected component (if applicable):
bluez-utils-2.25-4

How reproducible:
Start laptop, enable bluetooth (hard button), login gnome desktop, use bluetooth
mouse, leave it alone for a couple of minutes, move mouse again.

Steps to Reproduce:
1. activate bluetooth on laptop and use bluetooth mouse
2. leave bluetooth mouse alone for a few minutes
3. move bluetooth mouse
  
Actual results:
The on-screen mouse pointer does not immediately react to movement of the
bluetooth mouse. The touchpad responds immediately. After a few seconds
(sometimes more than 10) the mouse pointer follows the bluetooth mouse again. 

Expected results:
The moment the bluetooth mouse is moved, the mouse pointer moves on the screen
accordingly.

Additional info:
When everything goes ok, so the hardly any delay in pointer movement I see this
in /var/log/messages:
Jun 24 18:29:37 werkstation hidd[1514]: New HID device 00:10:C6:32:7B:D1 (HP
Three Button Mouse)
Jun 24 18:29:37 werkstation kernel: input: Bluetooth HID Boot Protocol Device as
/class/input/input4

When there is a serious delay I see the following in /var/log/messages:
Jun 24 19:02:04 werkstation kernel: hci_acldata_packet: hci0 ACL packet for
unknown connection handle 7
Jun 24 19:02:14 werkstation kernel: hci_acldata_packet: hci0 ACL packet for
unknown connection handle 6
Jun 24 19:02:26 werkstation hidd[1514]: New HID device 00:10:C6:54:9C:2B (HP
Three Button Mouse)
Jun 24 19:02:26 werkstation kernel: input: Bluetooth HID Boot Protocol Device as
/class/input/input5

Wfiw note the difference in /class/input/input4 versus /class/input/input5

Comment 1 Patrick 2006-10-05 15:08:49 UTC

(changed the summary to be a bit more descriptive)

This issue is also present in Rawhide (updated today). I see the following
messages in /var/log/messages:

Oct  5 12:13:55 speedy hidd[1999]: New HID device 00:10:C6:54:9C:2B (HP Three
Button Mouse)
Oct  5 12:14:05 speedy kernel: ohci_hcd 0000:00:13.1: wakeup
Oct  5 12:14:05 speedy kernel: usb 2-2: new full speed USB device using ohci_hcd
and address 2
Oct  5 12:14:05 speedy kernel: usb 2-2: configuration #1 chosen from 1 choice
Oct  5 12:14:05 speedy kernel: Bluetooth: HCI USB driver ver 2.9
Oct  5 12:14:05 speedy kernel: usbcore: registered new driver hci_usb
Oct  5 12:14:05 speedy kernel: hci_acldata_packet: hci0 ACL packet for unknown
connection handle 6
Oct  5 12:14:05 speedy kernel: 
Oct  5 12:14:05 speedy kernel: =============================================
Oct  5 12:14:05 speedy kernel: [ INFO: possible recursive locking detected ]
Oct  5 12:14:05 speedy kernel: 2.6.18-1.2726.fc6 #1
Oct  5 12:14:05 speedy kernel: ---------------------------------------------
Oct  5 12:14:05 speedy kernel: hidd/1999 is trying to acquire lock:
Oct  5 12:14:05 speedy kernel:  (sk_lock-AF_BLUETOOTH){--..}, at:
[<ffffffff884b82b8>] bt_accept_dequeue+0x37/0xfa [bluetooth]
Oct  5 12:14:05 speedy kernel: 
Oct  5 12:14:05 speedy kernel: but task is already holding lock:
Oct  5 12:14:05 speedy kernel:  (sk_lock-AF_BLUETOOTH){--..}, at:
[<ffffffff884da464>] l2cap_sock_accept+0x52/0x162 [l2cap]
Oct  5 12:14:05 speedy kernel: 
Oct  5 12:14:05 speedy kernel: other info that might help us debug this:
Oct  5 12:14:05 speedy kernel: 1 lock held by hidd/1999:
Oct  5 12:14:05 speedy kernel:  #0:  (sk_lock-AF_BLUETOOTH){--..}, at:
[<ffffffff884da464>] l2cap_sock_accept+0x52/0x162 [l2cap]
Oct  5 12:14:05 speedy kernel: 
Oct  5 12:14:05 speedy kernel: stack backtrace:
Oct  5 12:14:05 speedy kernel: 
Oct  5 12:14:05 speedy kernel: Call Trace:
Oct  5 12:14:05 speedy kernel:  [<ffffffff8026ed20>] show_trace+0xae/0x336
Oct  5 12:14:05 speedy kernel:  [<ffffffff8026efbd>] dump_stack+0x15/0x17
Oct  5 12:14:05 speedy kernel:  [<ffffffff802a8834>] __lock_acquire+0x135/0x9d9
Oct  5 12:14:05 speedy kernel:  [<ffffffff802a967b>] lock_acquire+0x4b/0x69
Oct  5 12:14:05 speedy kernel:  [<ffffffff80236271>] lock_sock+0xd5/0xe7
Oct  5 12:14:05 speedy kernel:  [<ffffffff884b82b8>]
:bluetooth:bt_accept_dequeue+0x37/0xfa
Oct  5 12:14:05 speedy kernel:  [<ffffffff884da528>]
:l2cap:l2cap_sock_accept+0x116/0x162
Oct  5 12:14:05 speedy kernel:  [<ffffffff80420d6e>] sys_accept+0x102/0x1af
Oct  5 12:14:05 speedy kernel:  [<ffffffff8026094e>] system_call+0x7e/0x83
Oct  5 12:14:05 speedy kernel: DWARF2 unwinder stuck at system_call+0x7e/0x83
Oct  5 12:14:05 speedy kernel: Leftover inexact backtrace:
Oct  5 12:14:05 speedy kernel: 
Oct  5 12:14:05 speedy kernel: input: Bluetooth HID Boot Protocol Device as
/class/input/input3
Oct  5 13:23:38 speedy hidd[1999]: New HID device 00:10:C6:54:9C:2B (HP Three
Button Mouse)
Oct  5 13:28:05 speedy kernel: input: Bluetooth HID Boot Protocol Device as
/class/input/input4
Oct  5 14:30:35 speedy kernel: hci_acldata_packet: hci0 ACL packet for unknown
connection handle 7
Oct  5 14:30:37 speedy hidd[1999]: New HID device 00:10:C6:54:9C:2B (HP Three
Button Mouse)
Oct  5 14:30:37 speedy kernel: input: Bluetooth HID Boot Protocol Device as
/class/input/input5

The bluetooth mouse will suddenly stop working, even during a movement. After
some time it starts working again. When that happens /var/log/messages shows:

Oct  5 15:42:19 speedy hidd[1999]: New HID device 00:10:C6:54:9C:2B (HP Three
Button Mouse)
Oct  5 15:42:38 speedy kernel: input: Bluetooth HID Boot Protocol Device as
/class/input/input9
Oct  5 16:49:00 speedy hidd[1999]: New HID device 00:10:C6:54:9C:2B (HP Three
Button Mouse)
Oct  5 16:49:02 speedy kernel: input: Bluetooth HID Boot Protocol Device as
/class/input/input10
Oct  5 16:55:26 speedy hidd[1999]: New HID device 00:10:C6:54:9C:2B (HP Three
Button Mouse)
Oct  5 16:55:29 speedy kernel: input: Bluetooth HID Boot Protocol Device as
/class/input/input11

Then there are also other messages in /var/log/messages that seem related:

Oct  3 02:38:02 speedy hidd[1966]: New HID device 00:12:34:56:78:90 (HP Three
Button Mouse)
Oct  3 02:38:02 speedy hidd[1966]: HID create error 77 (File descriptor in bad
state)

Comment 2 Patrick 2006-12-08 03:02:47 UTC

Following David's recommendation on irc I have CCed Marcel. I also have changed
the summary to focus on the remaining issue because I no longer see the kernel
recursive lock message.

On FC6 the "HID create error 77 (File descriptor in bad state)" is still
present, the mouse is still non-resposive when left alone for a couple of
minutes and then moved. When the mouse is moved again after being idle for a
couple of minutes the following message is visible in /var/messages:
Dec  8 03:52:46 speedy hidd[2094]: New HID device 00:10:B2:45:F8:C1 (HP Three
Button Mouse)
Dec  8 03:52:46 speedy hidd[2094]: HID create error 77 (File descriptor in bad
state)

When this appears the mouse is dead. The mouse usually starts working again
after a while (between 10 seconds and several minutes) _or_ when I manually do $
sudo hidd --server --search.

Comment 3 Bastien Nocera 2007-10-04 12:56:05 UTC

Could you please test with a more recent version of bluez-utils? We use the
input service now, rather than the hidd daemon.

You can configure your mouse using bluetooth-properties.

Comment 4 Patrick 2008-02-01 14:13:40 UTC

Apologies for the delay. Seems to work fine on F8. Bug can be closed