2009-04-30 13:34:21

by Marc Pignat

[permalink] [raw]
Subject: [BUG] 2.6.30-rc4 hid bluetooth not working

Hi all!

My bluetooth keyboard is not working any more in rc4, but was working in rc3.

Here is the dmesg output, triggered by the first key press on the keyboard, fortunately, this
is 100% reproductible (once per boot).

Attached my .config and the full dmesg output from boot, just in case.

Best regards

Marc


[ 1492.544731] ------------[ cut here ]------------
[ 1492.544741] WARNING: at kernel/workqueue.c:371 flush_cpu_workqueue+0x2d/0x77()
[ 1492.544748] Hardware name: System Product Name
[ 1492.544753] Modules linked in: btusb ipv6 nfs lockd nfs_acl auth_rpcgss sunrpc loop snd_cmipci tuner gameport snd_hda_codec_atihdmi snd_opl3_lib cx88_alsa cx8800 cx88xx snd_mpu401_uart ir_common snd_hda_codec_via tveeprom snd_seq_midi videobuf_dma_sg snd_hda_intel snd_hda_codec psmouse videobuf_core snd_rawmidi snd_hwdep serio_raw btcx_risc wmi pcspkr
[ 1492.544820] Pid: 324, comm: bluetooth Not tainted 2.6.30-rc4 #8
[ 1492.544825] Call Trace:
[ 1492.544837] [<ffffffff80246405>] ? warn_slowpath+0xd8/0x10a
[ 1492.544850] [<ffffffff8037b8a2>] ? vsnprintf+0x3b8/0x3f7
[ 1492.544862] [<ffffffff802cd069>] ? path_lookup_open+0x83/0x91
[ 1492.544872] [<ffffffff8037b9eb>] ? snprintf+0x44/0x4c
[ 1492.544882] [<ffffffff8020f631>] ? __switch_to+0xab/0x25a
[ 1492.544892] [<ffffffff8023f33f>] ? dequeue_entity+0xf/0x11f
[ 1492.544901] [<ffffffff805a5462>] ? _spin_unlock_irq+0x36/0x44
[ 1492.544910] [<ffffffff8023d646>] ? finish_task_switch+0x47/0xd8
[ 1492.544921] [<ffffffff805a3bf8>] ? thread_return+0x4c/0xa3
[ 1492.544931] [<ffffffff8025593d>] ? flush_cpu_workqueue+0x2d/0x77
[ 1492.544940] [<ffffffff8023d646>] ? finish_task_switch+0x47/0xd8
[ 1492.544950] [<ffffffff8022af3f>] ? default_spin_lock_flags+0x5/0xa
[ 1492.544959] [<ffffffff805a5257>] ? _spin_lock_irqsave+0x30/0x3d
[ 1492.544968] [<ffffffff80255b95>] ? flush_workqueue+0x33/0x55
[ 1492.544978] [<ffffffff80580553>] ? add_conn+0x14/0x39
[ 1492.544987] [<ffffffff80255687>] ? worker_thread+0x1c2/0x26a
[ 1492.544996] [<ffffffff802590aa>] ? autoremove_wake_function+0x0/0x2e
[ 1492.545006] [<ffffffff802554c5>] ? worker_thread+0x0/0x26a
[ 1492.545015] [<ffffffff802554c5>] ? worker_thread+0x0/0x26a
[ 1492.545023] [<ffffffff80258c88>] ? kthread+0x54/0x80
[ 1492.545033] [<ffffffff80243b77>] ? schedule_tail+0x2b/0x62
[ 1492.545042] [<ffffffff80211bfa>] ? child_rip+0xa/0x20
[ 1492.545050] [<ffffffff80258c34>] ? kthread+0x0/0x80
[ 1492.545058] [<ffffffff80211bf0>] ? child_rip+0x0/0x20
[ 1492.545064] ---[ end trace e4644449f8ce64bf ]---
[ 1492.613313] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
[ 1492.617028] IP: [<ffffffff803120c7>] sysfs_addrm_start+0x25/0xa5
[ 1492.617028] PGD 0
[ 1492.617028] Oops: 0000 [#1] PREEMPT SMP
[ 1492.617028] last sysfs file: /sys/devices/platform/it87.656/pwm1
[ 1492.617028] CPU 3
[ 1492.617028] Modules linked in: btusb ipv6 nfs lockd nfs_acl auth_rpcgss sunrpc loop snd_cmipci tuner gameport snd_hda_codec_atihdmi snd_opl3_lib cx88_alsa cx8800 cx88xx snd_mpu401_uart ir_common snd_hda_codec_via tveeprom snd_seq_midi videobuf_dma_sg snd_hda_intel snd_hda_codec psmouse videobuf_core snd_rawmidi snd_hwdep serio_raw btcx_risc wmi pcspkr
[ 1492.617028] Pid: 3556, comm: hidd Tainted: G W 2.6.30-rc4 #8 System Product Name
[ 1492.617028] RIP: 0010:[<ffffffff803120c7>] [<ffffffff803120c7>] sysfs_addrm_start+0x25/0xa5
[ 1492.617028] RSP: 0018:ffff88010ddd7a48 EFLAGS: 00010286
[ 1492.617028] RAX: ffff8800c59f1898 RBX: 0000000000000000 RCX: 0000000000000000
[ 1492.617028] RDX: fffffffffffffff8 RSI: 0000000000000000 RDI: ffffffff8074f1c0
[ 1492.617028] RBP: ffff88010ddd7a68 R08: 00000000000025c3 R09: ffff88010ddd7a2c
[ 1492.617028] R10: ffff88010cd64360 R11: ffff8801071d9250 R12: 00000000fffffff4
[ 1492.617028] R13: 0000000000000000 R14: ffff88010ddd7ac0 R15: ffff8800ca4710e8
[ 1492.617028] FS: 00007f0ba75f56f0(0000) GS:ffff88002806b000(0000) knlGS:0000000000000000
[ 1492.617028] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1492.617028] CR2: 0000000000000038 CR3: 000000010b4bb000 CR4: 00000000000006e0
[ 1492.617028] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1492.617028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1492.617028] Process hidd (pid: 3556, threadinfo ffff88010ddd6000, task ffff88010c5747c0)
[ 1492.617028] Stack:
[ 1492.617028] 0000000000000000 ffff8800c59f1898 ffff88010dc385a0 ffffffff80312608
[ 1492.617028] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1492.740068] ffff8800c59f1898 00000000fffffffe 00000000fffffff4 ffff8800c59f0000
[ 1492.740068] Call Trace:
[ 1492.740068] [<ffffffff80312608>] ? create_dir+0x44/0x7c
[ 1492.740068] [<ffffffff80312675>] ? sysfs_create_dir+0x35/0x4a
[ 1492.740068] [<ffffffff805a5560>] ? _spin_unlock+0x2f/0x3d
[ 1492.740068] [<ffffffff803762cf>] ? kobject_add_internal+0xd0/0x186
[ 1492.740068] [<ffffffff80376531>] ? kobject_add+0x74/0x7c
[ 1492.740068] [<ffffffff802be5cb>] ? ____cache_alloc+0x18/0x222
[ 1492.740068] [<ffffffff802be915>] ? __kmalloc+0x140/0x14c
[ 1492.740068] [<ffffffff8042c40e>] ? device_add+0xd1/0x50c
[ 1492.740068] [<ffffffff8057c9b1>] ? hci_get_route+0xae/0xbc
[ 1492.740068] [<ffffffff804ceb24>] ? hid_add_device+0x143/0x159
[ 1492.740068] [<ffffffff8058b74a>] ? hidp_add_connection+0x35d/0x5de
[ 1492.740068] [<ffffffff802c44eb>] ? __rcu_read_unlock+0xe/0x2a
[ 1492.740068] [<ffffffff8058c421>] ? hidp_sock_ioctl+0xf0/0x22b
[ 1492.740068] [<ffffffff805a50c3>] ? _spin_lock+0x1a/0x20
[ 1492.740068] [<ffffffff802a6451>] ? __do_fault+0x32e/0x376
[ 1492.740068] [<ffffffff80505a49>] ? sockfd_lookup_light+0x1a/0x51
[ 1492.740068] [<ffffffff8050573d>] ? sock_ioctl+0x1e7/0x20a
[ 1492.740068] [<ffffffff802cefda>] ? vfs_ioctl+0x21/0x6c
[ 1492.740068] [<ffffffff802cf457>] ? do_vfs_ioctl+0x432/0x46b
[ 1492.740068] [<ffffffff802cf4e1>] ? sys_ioctl+0x51/0x70
[ 1492.740068] [<ffffffff80210b42>] ? system_call_fastpath+0x16/0x1b
[ 1492.740068] Code: 44 89 f0 41 5e c3 55 31 c0 b9 08 00 00 00 48 89 fd 53 48 89 f3 48 83 ec 08 f3 ab 48 89 75 00 48 c7 c7 c0 f1 74 80 e8 3e 20 29 00 <48> 8b 73 38 48 8b 3d a6 18 60 00 48 89 d9 48 c7 c2 ec 1b 31 80
[ 1492.740068] RIP [<ffffffff803120c7>] sysfs_addrm_start+0x25/0xa5
[ 1492.740068] RSP <ffff88010ddd7a48>
[ 1492.740068] CR2: 0000000000000038
[ 1492.741545] ---[ end trace e4644449f8ce64c0 ]---


Attachments:
(No filename) (6.25 kB)
.config (93.53 kB)
kern.log (82.42 kB)
Download all attachments

2009-04-30 13:57:28

by Jiri Kosina

[permalink] [raw]
Subject: Re: [BUG] 2.6.30-rc4 hid bluetooth not working

On Thu, 30 Apr 2009, Marc Pignat wrote:

> My bluetooth keyboard is not working any more in rc4, but was working in
> rc3.
> Here is the dmesg output, triggered by the first key press on the
> keyboard, fortunately, this is 100% reproductible (once per boot).

Does reverting f3784d834c7 fix the problem?

--
Jiri Kosina
SUSE Labs

2009-04-30 14:50:05

by Marc Pignat

[permalink] [raw]
Subject: Re: [BUG] 2.6.30-rc4 hid bluetooth not working

>>> Jiri Kosina <[email protected]> 04/30/09 3:57 PM >>>
>Does reverting f3784d834c7 fix the problem?

git-revert f3784d834c7 fixed the problem (I can re-use my super-expensive keyboard ;) ).



Best regards

Marc

2009-04-30 15:03:21

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [BUG] 2.6.30-rc4 hid bluetooth not working

Hi Jiri,

> > My bluetooth keyboard is not working any more in rc4, but was working in
> > rc3.
> > Here is the dmesg output, triggered by the first key press on the
> > keyboard, fortunately, this is 100% reproductible (once per boot).
>
> Does reverting f3784d834c7 fix the problem?

we have seen a similar report where reverting f3784d834c7 didn't fix it.
And I don't see anything wrong with that patch. Did something important
got changed in the work queue code that I am missing?

Regards

Marcel

2009-04-30 15:33:34

by Marc Pignat

[permalink] [raw]
Subject: Re: [BUG] 2.6.30-rc4 hid bluetooth not working

>>> Marcel Holtmann <[email protected]> 04/30/09 5:03 PM >>>
>Hi Jiri,

>> > My bluetooth keyboard is not working any more in rc4, but was working in
>> > rc3.
>> > Here is the dmesg output, triggered by the first key press on the
>> > keyboard, fortunately, this is 100% reproductible (once per boot).
>>
>> Does reverting f3784d834c7 fix the problem?

>we have seen a similar report where reverting f3784d834c7 didn't fix it.
It seems to fix it for me...

>And I don't see anything wrong with that patch. Did something important
>got changed in the work queue code that I am missing?

Is this a good idea to flush the current queue? (add_con and del_con call flush_workqueue(bluetooth),
but add_con and del_con are run by this queue).

Best regards

Marc

2009-04-30 18:59:31

by Jiri Kosina

[permalink] [raw]
Subject: Re: [BUG] 2.6.30-rc4 hid bluetooth not working

On Thu, 30 Apr 2009, Marcel Holtmann wrote:

> > > My bluetooth keyboard is not working any more in rc4, but was
> > > working in rc3. Here is the dmesg output, triggered by the first key
> > > press on the keyboard, fortunately, this is 100% reproductible (once
> > > per boot).
> > Does reverting f3784d834c7 fix the problem?
> we have seen a similar report where reverting f3784d834c7 didn't fix it.
> And I don't see anything wrong with that patch. Did something important
> got changed in the work queue code that I am missing?

Calling flush() from work->func() is not safe. That's what the WARN_ON()
in flush_cpu_workqueue() is there for, right?

--
Jiri Kosina
SUSE Labs

2009-04-30 22:34:31

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [BUG] 2.6.30-rc4 hid bluetooth not working

Hi Jiri,

> > > > My bluetooth keyboard is not working any more in rc4, but was
> > > > working in rc3. Here is the dmesg output, triggered by the first key
> > > > press on the keyboard, fortunately, this is 100% reproductible (once
> > > > per boot).
> > > Does reverting f3784d834c7 fix the problem?
> > we have seen a similar report where reverting f3784d834c7 didn't fix it.
> > And I don't see anything wrong with that patch. Did something important
> > got changed in the work queue code that I am missing?
>
> Calling flush() from work->func() is not safe. That's what the WARN_ON()
> in flush_cpu_workqueue() is there for, right?

I don't know since this got changed in 2.6.30-rc1. I do have this kernel
running and I have seen the WARN_ON() only once. However I have never
seen a NULL pointer because of this patch.

Regards

Marcel

2009-05-01 00:37:30

by Marc Pignat

[permalink] [raw]
Subject: Re: [BUG] 2.6.30-rc4 hid bluetooth not working

Subject: bluetooth: Fix serialization when adding/deleting connections in hci_sysfs

add_conn and del_conn should be serialized, but flush_workqueue can't be used
by the worker thread on it's own queue, so use flush_work to serialize add_conn
and del_conn against each other.

Signed-off-by: Marc Pignat <[email protected]>
---

patch against 2.6.30-rc4.


diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index b7c5108..42695e3 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -89,8 +89,8 @@ static void add_conn(struct work_struct *work)
{
struct hci_conn *conn = container_of(work, struct hci_conn, work_add);

- /* ensure previous add/del is complete */
- flush_workqueue(bluetooth);
+ /* ensure previous del is complete */
+ flush_work(&conn->work_del);

if (device_add(&conn->dev) < 0) {
BT_ERR("Failed to register connection device");
@@ -134,8 +134,8 @@ static void del_conn(struct work_struct *work)
struct hci_conn *conn = container_of(work, struct hci_conn, work_del);
struct hci_dev *hdev = conn->hdev;

- /* ensure previous add/del is complete */
- flush_workqueue(bluetooth);
+ /* ensure previous add is complete */
+ flush_work(&conn->work_add);

while (1) {
struct device *dev;