Re: [1/2] 2.6.22-rc7: known regressions

[Linus Torvalds]

On Wed, 4 Jul 2007, David Woodhouse wrote:
> 
> Oh, and here's another one for you. My Bluetooth mouse just stopped
> working and hidd is deadlocked...

Looks like it is stuck on hidp_session_sem.

Nothing after 2.6.21 seems to have even touched that semaphore usage, and 
in fact there's not a whole lot of changes to the hidp code at all (and 
none of them look even remotely interesting). 

So I suspect it's something lower down in the bluetooth stack, or it's a 
long-standing problem that you are somehow able to trigger more easily 
now. Is it consistent?

Can you showo the traces for the _other_ processes that are in bluetooth 
functions? Because there should be other processes there, holding that 
hidp_session_sem rwsem.

[ Alternatively, there is some process that doesn't release it in an error 
  case, but that is definitely not a regression if so: the changes to 
  net/bluetooth/hidp/core.c since 2.6.21 really are trivial. ]

IOW, more info needed, I think.

			Linus

---
> hidd          D 1FE27798  5940  1695      1 (NOTLB)
> Call Trace:
> [ef3ddb70] [00000004] 0x4 (unreliable)
> [ef3ddc30] [c0008e7c] __switch_to+0x50/0x68
> [ef3ddc50] [c02d5998] schedule+0x3cc/0x480
> [ef3ddc80] [c0137a20] rwsem_down_failed_common+0x1c4/0x1f4
> [ef3ddcb0] [c02d7454] rwsem_down_write_failed+0x28/0x40
> [ef3ddce0] [c004ff60] down_write+0x50/0x64
> [ef3ddd00] [f27f2068] hidp_add_connection+0x168/0x75c [hidp]
> [ef3ddd40] [f27f2e44] hidp_sock_ioctl+0x140/0x414 [hidp]
> [ef3ddeb0] [c024da6c] sock_ioctl+0x248/0x284
> [ef3dded0] [c00ab02c] do_ioctl+0x38/0x84
> [ef3ddee0] [c00ab448] vfs_ioctl+0x3d0/0x404
> [ef3ddf10] [c00ab4e4] sys_ioctl+0x68/0x98
> 
> -- 
> dwmw2
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/