Re: [Regression, 2.6.36-rc1] ath9k resume problem on Acer FerrariOne

[Tejun Heo]

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-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/