Hello, On 08/19/2010 04:05 PM, Rafael J. Wysocki wrote: > On Thursday, August 19, 2010, Tejun Heo wrote: >> Hello, Rafael. >> >> On 08/19/2010 12:01 AM, Rafael J. Wysocki wrote: >>> While testing 2.6.36-rc1 (with a couple of fixes on top) I noticed >>> that the ath9k driver didn't work after resume from suspend to RAM. >>> An attempt to unload the driver using rmmod caused the BUG_ON() in >>> kernel/workqueue.c:2844 to trigger. >> >> That BUG_ON() triggers if destroy_workqueue() is called while work >> items are still pending on the workqueue. Can you please trigger >> stack traces after resume and post it? > > Do you mean sysrq-t? Yeah, I'm a bit confused regarding what's going on. I thought the most likely cause is thawing failing to kick a frozen workqueue into working state but then flush_workqueue() which is called from destroy_workqueue() should have hung too, that is, unless flush_workqueue() is broken too. If flush_workqueue() is not broken, then it could be that workqueue itself isn't at fault and works are being scheduled and executed fine for the workqueue ath9k is using but the driver doesn't work for another reason. Also, the BUG_ON() being triggered means either flush_workqueue() is broken or the driver is failing to stop works on the workqueue from being requeued before calling destroy_workqueue(). So, finding out the followings would be great, * While the driver isn't working, do a sysrq-t and see whether any worker is executing a work for ath9k. * Repeat it several times and see whether the work is stuck or making progress and/or executing on different workers. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
