lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 19 Aug 2010 16:19:08 +0200 From: Tejun Heo <tj@...nel.org> To: "Rafael J. Wysocki" <rjw@...k.pl> CC: Luis Rodriguez <lrodriguez@...eros.com>, LKML <linux-kernel@...r.kernel.org>, Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>, linux-wireless@...r.kernel.org, ath9k-devel@...ema.h4ckr.net, Maciej Rutecki <maciej.rutecki@...il.com> Subject: Re: [Regression, 2.6.36-rc1] ath9k resume problem on Acer Ferrari One 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists