Thanks, I'll give that a try. Paul
-----Original Message----- From: Javier Cardona [mailto:[email protected]] Sent: Monday, November 26, 2012 9:18 PM To: [email protected]; [email protected] Subject: Re: Debugging a RACOM problem. Paul, > Nov 26 17:42:18 ub3 kernel: [13199.114297] BUG: scheduling while atomic: > kworker/u:0/1920/0x00000200 If you compile your kernel with CONFIG_DEBUG_BUGVERBOSE, the above BUG message would include the source file name and line number of the failed assertion. BUG_ON will raise a kernel panic, so it is likely that this is the reason for the non-established peer links. Also, there are mesh specific debug option that will dump additional information to the kernel logs: MAC80211_MPL_DEBUG, MAC80211_MPATH_DEBUG, MAC80211_MHWMP_DEBUG and MAC80211_MESH_SYNC Hope that it helps. Cheers, Javier On Mon, Nov 26, 2012 at 5:45 PM, Paul Stoaks <[email protected]> wrote: > Hello All, > > I have an ASUS USB (WL-167G) adapter (shows up in lsusb as a Ralink > RT2571W) that won't peer correctly with two ath9k_htc devices. (This > is a simple open mesh, no authentication.) The Atheros devices peer > with each other, but the Ralink device never gets to ESTAB with either of the Atheros devices (in > either direction). From constantly monitoring station dump on all three > devices, it appears that the Atheros devices are getting OPN frames > from the Ralink device, and the Ralink device is getting OPN frames > from the Ath devices (by virtue of the fact that they all make it to > the OPN_RCVD state from time to time) but I'm never seeing a CNF_RCVD state or ESTAB state. > > I'm using the origin/master branch of open80211s, and the linux-3.6.y > version of compat and compat-drivers. > > I'm not only interested in solving this problem, but I would like to > better understand what tools exist for debugging it? The 'trace-cmd > report -e mac80211' isn't helping me, 'iw event' doesn't appear to > provide anything helpful, and there are no messages appearing in the > syslog of the machine with the Ralink. > > Ahh, I do see this repeatedly in the syslogs of the Ath devices. Even > when the Ralink is shut down. > > Nov 26 17:42:18 ub3 kernel: [13199.114297] BUG: scheduling while atomic: > kworker/u:0/1920/0x00000200 > Nov 26 17:42:18 ub3 kernel: [13199.114301] Modules linked in: arc4 > joydev snd_atiixp_modem snd_atiixp snd_ac97_codec ac97_bus snd_pcm > ath9k_htc(O) > ath9k_common(O) snd_seq_midi ath9k_hw(O) pcmcia snd_rawmidi ath(O) > mac80211(O) snd_seq_midi_event cfg80211(O) snd_seq snd_timer > snd_seq_device psmouse rfcomm tifm_7xx1 compat(O) parport_pc ppdev > nfsd bnep yenta_socket pcmcia_rsrc radeon bluetooth snd bcma tifm_core > nfs lockd fscache auth_rpcgss nfs_acl serio_raw sunrpc soundcore > pcmcia_core k8temp snd_page_alloc ttm drm_kms_helper video i2c_piix4 > drm i2c_algo_bit mac_hid ati_agp shpchp lp parport firewire_ohci ssb > sdhci_pci sdhci pata_atiixp firewire_core crc_itu_t sky2 Nov 26 > 17:42:18 ub3 kernel: [13199.114395] Pid: 1920, comm: kworker/u:0 > Tainted: G W O 3.5.0-18-generic #29-Ubuntu > Nov 26 17:42:18 ub3 kernel: [13199.114399] Call Trace: > Nov 26 17:42:18 ub3 kernel: [13199.114407] [<c15c0c6d>] > __schedule_bug+0x52/0x5e Nov 26 17:42:18 ub3 kernel: [13199.114415] > [<c15c962e>] > __schedule+0x75e/0x770 > Nov 26 17:42:18 ub3 kernel: [13199.114426] [<c1037af8>] ? > default_spin_lock_flags+0x8/0x10 > Nov 26 17:42:18 ub3 kernel: [13199.114434] [<c15ca7ad>] ? > _raw_spin_lock_irqsave+0x2d/0x40 > Nov 26 17:42:18 ub3 kernel: [13199.114475] [<c15c98e3>] > schedule+0x23/0x60 Nov 26 17:42:18 ub3 kernel: [13199.114483] > [<c15c8004>] > schedule_timeout+0x124/0x280 > Nov 26 17:42:18 ub3 kernel: [13199.114491] [<c1053730>] ? > usleep_range+0x40/0x40 > Nov 26 17:42:18 ub3 kernel: [13199.114499] [<c15c9761>] > wait_for_common+0xa1/0x120 > Nov 26 17:42:18 ub3 kernel: [13199.114509] [<c1075e30>] ? > try_to_wake_up+0x230/0x230 > Nov 26 17:42:18 ub3 kernel: [13199.114517] [<c15c9892>] > wait_for_completion_timeout+0x12/0x20 > Nov 26 17:42:18 ub3 kernel: [13199.114530] [<f8951ad3>] > ath9k_wmi_cmd+0x153/0x1a0 [ath9k_htc] > Nov 26 17:42:18 ub3 kernel: [13199.114543] [<f8956f3d>] > ath9k_regwrite+0x5d/0x110 [ath9k_htc] > Nov 26 17:42:18 ub3 kernel: [13199.114565] [<f8aa6e49>] > ath9k_hw_settsf64+0x29/0x40 [ath9k_hw] Nov 26 17:42:18 ub3 kernel: > [13199.114578] [<f8954556>] > 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>] ? > __kfree_skb+0x3d/0x90 > Nov 26 17:42:18 ub3 kernel: [13199.114649] [<c14d007d>] ? > __kfree_skb+0x3d/0x90 > Nov 26 17:42:18 ub3 kernel: [13199.114699] [<f8711579>] > ieee80211_mesh_work+0x79/0x1a0 [mac80211] Nov 26 17:42:18 ub3 kernel: > [13199.114737] [<f86dec78>] > ieee80211_iface_work+0x268/0x310 [mac80211] Nov 26 17:42:18 ub3 > kernel: [13199.114746] [<c105f9ef>] > process_one_work+0x10f/0x380 > Nov 26 17:42:18 ub3 kernel: [13199.114784] [<f86dea10>] ? > ieee80211_check_queues+0x100/0x100 [mac80211] Nov 26 17:42:18 ub3 > kernel: [13199.114793] [<c1060c39>] > worker_thread+0xf9/0x290 > Nov 26 17:42:18 ub3 kernel: [13199.114800] [<c107073e>] ? > complete+0x4e/0x60 > Nov 26 17:42:18 ub3 kernel: [13199.114808] [<c1060b40>] ? > manage_workers.isra.25+0x1d0/0x1d0 > Nov 26 17:42:18 ub3 kernel: [13199.114817] [<c1064dd2>] > kthread+0x72/0x80 Nov 26 17:42:18 ub3 kernel: [13199.114826] [<c1064d60>] ? > kthread_freezable_should_stop+0x60/0x60 > Nov 26 17:42:18 ub3 kernel: [13199.114835] [<c15d1a7e>] > kernel_thread_helper+0x6/0x10 > > I'll look into this as a clue, but, in the meantime, anyone got any > good debugging pointers? > > Thanks, > Paul > > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel -- Javier Cardona cozybit Inc. http://www.cozybit.com _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
