Hello, On Wed, Jun 05, 2013 at 01:47:43PM +0930, Rusty Russell wrote: > > I have some printk debugging in (see bottom of email) and was using a serial console, so things > > were probably running a bit slower than on most systems. Here is trace > > from my kernel with local patches and not so much debugging enabled > > (this is NOT a clean upstream kernel, though I reproduced the same thing > > with a clean upstream 3.9.4 kernel plus your module unlink patch yesterday). > > Tejun CC'd. We can't be running two stop machines in parallel, since > there's a mutex (and there's also one in the module code). > > > __stop_machine, num-threads: 4, fn: __try_stop_module data: ffff8801c6ae7f28 > > cpu: 0 loops: 1 jiffies: 4299011449 timeout: 4299011448 curstate: 0 smdata->state: 1 thread_ack: 4 > > cpu: 1 loops: 1 jiffies: 4299011449 timeout: 4299011448 curstate: 0 smdata->state: 1 thread_ack: 4 > > cpu: 2 loops: 1 jiffies: 4299011449 timeout: 4299011448 curstate: 0 smdata->state: 1 thread_ack: 3 > > cpu: 3 loops: 1 jiffies: 4299011449 timeout: 4299011448 curstate: 0 smdata->state: 1 thread_ack: 2 > > __stop_machine, num-threads: 4, fn: __unlink_module data: ffffffffa0aeeab0 > > cpu: 0 loops: 1 jiffies: 4299011501 timeout: 4299011500 curstate: 0 smdata->state: 1 thread_ack: 4 > > cpu: 1 loops: 1 jiffies: 4299011501 timeout: 4299011500 curstate: 0 smdata->state: 1 thread_ack: 4 > > cpu: 3 loops: 1 jiffies: 4299011501 timeout: 4299011500 curstate: 0 smdata->state: 1 thread_ack: 3 > > ath: wiphy0: Failed to stop TX DMA, queues=0x005! > > cpu: 2 loops: 1 jiffies: 4299011501 timeout: 4299011500 curstate: 0 smdata->state: 1 thread_ack: 2 A bit confused. I looked at the code again and it still seems properly interlocked. Can't see how the above scenario could happen. Actually, I'm not even sure, what I'm looking at. Is the above from the lockup? It'd be helpful if we can get more traces from the locked up state. Shouldn't be hard to detect. Dumb timeout based detection should work fine. How easily can you reproduce the issue? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html