I found a mutex deadlock in w1/slaves/w1_ds2760. The deadlock is intermittent in linux-2.6.39-rc4 (as though a race condition) but seems consistent in linux-2.6.39-rc5. The platform is an iPAQ hx4700 (XScale-PXA270).
I can demonstrate the deadlock by adding some printk() calls, replacing the mutex_lock() call in w1_ds2760_io() with mutex_trylock(), and dumping the stack trace if mutex_trylock() fails.
Here's the dmesg output:
w1_process: mutex_lock(0xc3921e68)
w1_ds2760_io: mutex_trylock(0xc3921e68)
[<c0023c44>] save_stack_trace_tsk+0x0/0xc4
[<c0023d2c>] save_stack_trace+0x24/0x28
[<c0193d58>] w1_ds2760_io+0x12c/0x144
[<c0193db0>] w1_ds2760_read+0x1c/0x24
[<c0195ed0>] ds2760_battery_read_status+0x3c/0x31c
[<c0196418>] ds2760_battery_probe+0xb0/0x26c
[<c015fff0>] platform_drv_probe+0x1c/0x20
[<c015eb74>] driver_probe_device+0x88/0x18c
[<c015ed58>] __device_attach+0x48/0x4c
[<c015e05c>] bus_for_each_drv+0x6c/0x94
[<c015edec>] device_attach+0x64/0x7c
[<c015de58>] bus_probe_device+0x30/0x50
[<c015c630>] device_add+0x4ec/0x5cc
[<c0160654>] platform_device_add+0x100/0x198
[<c0193b0c>] w1_ds2760_add_slave+0x90/0xfc
[<c0191548>] w1_attach_slave_device+0x1a4/0x370
[<c019186c>] w1_slave_found+0x158/0x15c
[<c0193750>] ds1wm_search+0xd8/0xdc
[<c0192d88>] w1_search_devices+0x44/0x50
[<c0191dcc>] w1_search_process+0x5c/0xf0
[<c0191f54>] w1_process+0xf4/0x120
[<c004b9e4>] kthread+0x90/0x98
[<c003563c>] do_exit+0x0/0x6e8
[<ffffffff>] 0xffffffff
w1_process: mutex_unlock(0xc3921e68)
Explanation:
1. w1_process() locks the mutex at 0xc3921e68.
2. w1_ds2760_io() locks the same mutex at 0xc3921e68 and thus mutex_trylock() fails.
3. stack trace showing the function path from w1_process() to w1_ds2760_io().
4. w1_process() unlocks the mutex at 0xc3921e68.