Ugh. It doesn't look like that commit is on the open80211s master branch (which I'm currently using). I'm a git n00b, but it looks like it's on the open80211s 'ft-ath9k-htc-support' branch and the linux-stable 'master' branch.
I have other drivers that I'd like this devel tree to support. Am I better off to merge the ft-ath0k-htc-support branch into my branch, or ...? The way I'm currently working is to use open80211s repo as 'linux-next' when building compat-drivers. Thanks, Bob, for this very helpful info. Paul -----Original Message----- From: Bob Copeland [mailto:[email protected]] Sent: Wednesday, November 28, 2012 5:57 AM To: [email protected]; [email protected] Cc: 'Javier Cardona' Subject: Re: Debugging a RACOM problem. On Tue, Nov 27, 2012 at 09:14:22AM -0800, Paul Stoaks wrote: > > Nov 26 17:42:18 ub3 kernel: [13199.114297] BUG: scheduling while atomic: > > kworker/u:0/1920/0x00000200 This particular bug looks like the one fixed by: commit 55fabefe3695241e6ccfa0cd4974f3fa497693dc Author: Thomas Pedersen <[email protected]> Date: Fri Oct 5 17:57:39 2012 -0700 mac80211: call drv_get_tsf() in sleepable context The call to drv_get/set_tsf() was put on the workqueue to perform tsf adjustments since that function might sleep. However it ended up inside a spinlock, whose critical section must be atomic. Do tsf adjustment outside the spinlock instead, and get rid of a warning. Signed-off-by: Thomas Pedersen <[email protected]> Signed-off-by: John W. Linville <[email protected]> Can you check if your kernel has that commit? > > ath9k_htc_set_tsf+0x36/0x50 [ath9k_htc] Nov 26 17:42:18 ub3 kernel: > > [13199.114631] [<f871690d>] > > mesh_sync_adjust_tbtt+0x13d/0x2d0 [mac80211] Nov 26 17:42:18 ub3 > > kernel: [13199.114641] [<c14d007d>] ? drv_set_tsf() was called under mesh_sync_adjust_tbtt in atomic context, and drv_set_tsf() should be allowed to sleep. I believe ath9k_htc takes a mutex in this path, which is not allowed in a spin-locked section. In addition to what Javier suggested, you can find the line numbers from function name + offset with gdb via something like the following, provided you built with debug info: $ gdb net/mac80211/mac80211.ko (gdb) l *(mesh_sync_adjust_tbtt+0x13d) Knowing where kworker emitted the warning is probably less useful in this case than the execution stack leading up to that point, the relevant lines being what I quoted above. Here, the stack trace itself is enough to go on since there's only one call to drv_set_tsf() in mesh_sync_adjust_tbtt(). Without debug info and nice stack traces, things get harder. A few times I have started from assembly and register dumps and worked out which C code is called, and how a crash came to happen, but that's quite tedious and error-prone. -- Bob Copeland %% www.bobcopeland.com _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
