| Subject | Re: BUG: possible deadlock detected! (sound) [Was: 2.6.17-rc5-mm1] | | From | Arjan van de Ven <> | | Date | Tue, 30 May 2006 13:06:28 +0200 |
| |
On Tue, 2006-05-30 at 147 +0159, Jiri Slaby wrote:
(I've turned your backtrace upside down to show it "chronological")
[<c05911e0>] alsa_emu10k1_synth_init+0x22/0x24 [<c0333d04>] snd_seq_device_register_driver+0x8f/0xeb
this one does:
mutex_lock(&ops->reg_mutex); ... list_for_each(head, &ops->dev_list) { struct snd_seq_device *dev = list_entry(head, struct snd_seq_device, list); init_device(dev, ops); } mutex_unlock(&ops->reg_mutex);
[<c0333537>] init_device+0x2c/0x94 which calls into the driver [<c0352c39>] snd_emu10k1_synth_new_device+0xe7/0x14e [<c0353f50>] snd_emux_register+0x10d/0x13f [<c0358260>] snd_emux_init_seq_oss+0x35/0x9c [<c0333aa0>] snd_seq_device_new+0x96/0x111
and this one does mutex_lock(&ops->reg_mutex); list_add_tail(&dev->list, &ops->dev_list); ops->num_devices++; mutex_unlock(&ops->reg_mutex);
so... on first sight this looks like a real deadlock; unless the ALSA folks can tell me why "ops" is always different, and what the lock ordering rules between those is...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|