Subject: Re: [87attendees] Anyone using Fedora 18 on the IETF wifi?

From: Derek Atkins <[email-masked]>
Date: Mon, 29 Jul 2013 01:40:42 -0700

Yes, that is what I see...  Over and over.  Hard to type that into my phone.  :-)

I have a 3.9.10-200 kernel.  Do you not get that from the 3.10 kernel?  Maybe location matters?

I can try to update my kernel after I get out of appsarea.

-derek

Sent from my HTC EVO 4G

----- Reply message -----
From: "Dominik Bay" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [87attendees] Anyone using Fedora 18 on the IETF wifi?
Date: Mon, Jul 29, 2013 10:36 AM

On 07/29/2013 10:27 AM, Derek Atkins wrote:
> If so please contact me offline.
>
> My laptop is throwing a continuous stream of errors filling my messages
> log and brining my machine to a grinding halt.  It seems to be a warning
> from the 80211 stack trying to determine the channel type. I am curious
> if anyone else sees this or if it is just me?  I have tried 2 versions
> of the kernel to no avail, yet.  To keep my laptop usable I need to turn
> off the radio by switch before I boot up. Once it gets into the loop
> there seems to be no way to get out short of shutting down.  Maybe a
> different location (I'm in Charlottenburg 2/3) might help?

I'm in Potsdam 1 now, I've seen my Linux system freeze after leaving
OpSec. Maybe this was the issue that you see too.

I see this:

Jul 29 09:38:36 fledermaus kernel: [120142.639917] WARNING: at
/home/apw/COD/linux/net/mac80211/mlme.c:366
ieee80211_determine_chantype+0x25f/0x390 [mac80211]()
Jul 29 09:38:36 fledermaus kernel: [120142.639920] Modules linked in:
xt_TCPMSS xt_tcpmss xt_tcpudp iptable_mangle ip_tables x_tables
nls_iso8859_1 omfs jfs xfs libcrc32c reiserfs hfs hfsplus isofs nls_utf8
udf crc_itu_t mmc_block usb_storage ipheth ppp_deflate zlib_deflate
bsd_comp ppp_async crc_ccitt usbhid hid snd_hrtimer 8021q mrp garp stp
llc snd_hda_codec_hdmi intel_powerclamp snd_hda_codec_realtek kvm_intel
thinkpad_acpi snd_hda_intel kvm snd_hda_codec snd_seq_midi snd_hwdep
arc4 snd_rawmidi snd_pcm snd_seq_midi_event snd_seq snd_timer iwldvm
snd_seq_device mac80211 snd nvram btusb tpm_tis microcode iwlwifi
cfg80211 bnep psmouse rfcomm uvcvideo parport_pc bluetooth serio_raw
videobuf2_core ppdev cdc_mbim lpc_ich lp parport videodev
videobuf2_vmalloc videobuf2_memops cdc_ncm soundcore usbnet
snd_page_alloc nfsd nfs_acl auth_rpcgss cdc_acm cdc_wdm nfs fscache
lockd binfmt_misc sunrpc mac_hid ext2 lm75 coretemp dm_crypt i915
crc32_pclmul ghash_clmulni_intel aesni_intel drm_kms_helper ablk_helper
cryptd drm lrw g
Jul 29 09:38:36 fledermaus kernel: f128mul e1000e glue_helper
i2c_algo_bit wmi aes_x86_64 video sdhci_pci ptp sdhci pps_core ahci
libahci [last unloaded: ipmi_msghandler]
Jul 29 09:38:36 fledermaus kernel: [120142.640160] CPU: 3 PID: 24816
Comm: kworker/u16:0 Tainted: G        W    3.10.0-999-generic #201305190405
Jul 29 09:38:36 fledermaus kernel: [120142.640162] Hardware name: LENOVO
23252GG/23252GG, BIOS G2ET86WW (2.06 ) 11/13/2012
Jul 29 09:38:36 fledermaus kernel: [120142.640171] Workqueue: phy0
ieee80211_iface_work [mac80211]
Jul 29 09:38:36 fledermaus kernel: [120142.640173]  ffffffffa0541498
ffff880163da5898 ffffffff816c1e98 ffff880163da58d8
Jul 29 09:38:36 fledermaus kernel: [120142.640176]  ffffffff81044c70
0000000000000001 ffff880163da59e0 ffff88020c18e800
Jul 29 09:38:36 fledermaus kernel: [120142.640190]  0000000000000810
ffff880212129070 0000000000000000 ffff880163da58e8
Jul 29 09:38:36 fledermaus kernel: [120142.640197] Call Trace:
Jul 29 09:38:36 fledermaus kernel: [120142.640245]  [<ffffffff816c1e98>]
dump_stack+0x19/0x1b
Jul 29 09:38:36 fledermaus kernel: [120142.640252]  [<ffffffff81044c70>]
warn_slowpath_common+0x70/0xa0
Jul 29 09:38:36 fledermaus kernel: [120142.640273]  [<ffffffff81044cba>]
warn_slowpath_null+0x1a/0x20

I'm on ietf-v6ONLY (2.4GHz) and running a 3.10.0 64bit Kernel, works
fine at the moment.

-dominik
_______________________________________________
87attendees mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/87attendees

---

From: Dominik Bay <[email-masked]>
Date: Mon, 29 Jul 2013 10:48:26 +0200

> I have a 3.9.10-200 kernel.  Do you not get that from the 3.10 kernel?

yes, 3.10, I think it's location/AP dependant. Will check later.

-dominik

---

From: Chris Elliott <[email-masked]>
Date: Mon, 29 Jul 2013 10:55:40 +0200

All,

I am very interested in understanding this issue. There is a difference in
the AP configuration in the Potsdam area and the rest of the network--we
have 802.11n turned on for the 2.4G radio (802.11b/g, adding n) for the
Potsdam APs only.

Please collect the BSSID that you are connected to when you see this
problem if possible, or, at least, your location as precisely as possible.
Alternatively, the BSSIDs where you don't see this problem may help us
debug this problem.

Feel free to come by the help desk in the Terminal Room or open a ticket at
https://tickets.meeting.ietf.org/newticket.

Thanks!
Chris.

-- 
Chris Elliott
[email-masked]

---

From: Derek Atkins <[email-masked]>
Date: Mon, 29 Jul 2013 02:03:41 -0700

I am sitting in Charlottenburg 2/3.  There's no way I can give you the
BSSID(s) when the issue occurred; it put over 16GB of logs in just a few
minutes, my machine grinded to a halt with a load average of >27.

I was given a suggestion of disabling NetworkManager, and surprisingly
this actually works!  I'm now on the ietf-a network by directly
"ifup"ing.  Right now I'm connected to 3C:CE:73:5F:C2:72

I'll gladly work with you on debugging this.  I don't know if it's a
hardware or software issue, but the linux kernel shouldn't come to a
screeching halt when it finds a weird configuration.

-derek

PS: I'm running:
Linux mocana.ihtfp.org 3.9.10-200.fc18.x86_64 #1 SMP Sun Jul 14 01:36:53
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[   19.098951] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R)
Ultimate-N 6300 AGN, REV=0x74

On Mon, 2013-07-29 at 01:55 -0700, Chris Elliott wrote:
> All,
> 
> 
> I am very interested in understanding this issue. There is a
> difference in the AP configuration in the Potsdam area and the rest of
> the network--we have 802.11n turned on for the 2.4G radio (802.11b/g,
> adding n) for the Potsdam APs only.
> 
> 
> problem if possible, or, at least, your location as precisely as
> possible. Alternatively, the BSSIDs where you don't see this problem
> may help us debug this problem.
> 
> 
> Feel free to come by the help desk in the Terminal Room or open a
> ticket at https://tickets.meeting.ietf.org/newticket.
> 
> 
> Thanks!
> Chris.
> 
> 
>         > Yes, that is what I see...  Over and over.  Hard to type
>         that into my
>         > phone.  :-)
>         >
>         > I have a 3.9.10-200 kernel.  Do you not get that from the
>         3.10 kernel?
>         >  Maybe location matters?
>         
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 29 Jul 2013 11:05:47 +0200

Le 2013-07-29 10:55, Chris Elliott a écrit :
> I am very interested in understanding this issue.

I replied to Derek privately but now that troubleshooting has been 
crowdsourced...

[simon@porto ~]$ iwconfig wlan0
wlan0     IEEE 802.11abgn  ESSID:"ietf"
           Mode:Managed  Frequency:5.2 GHz  Access Point: 
3C:CE:73:65:FE:51
           Bit Rate=130 Mb/s   Tx-Power=15 dBm
           Retry  long limit:7   RTS thr:off   Fragment thr:off
           Power Management:off
           Link Quality=49/70  Signal level=-61 dBm
           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
           Tx excessive retries:153  Invalid misc:57   Missed beacon:0

[simon@porto ~]$ uname -r
3.9.11-200.fc18.x86_64

[    8.744498] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) 
Advanced-N 6205 AGN, REV=0xB0

I'm in Potsdam 1, next to the mic on the right side.

Everything's working smoothly.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jul 2013 11:43:26 +0200

> UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I'm running 3.9.6-200.fc18.x86_64 and I have tried out the v6-only
network and did not have any problems. I'm really interested in getting
some of your excessive NM logs to look at this and file a bug report for
the right people.

Paul

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 29 Jul 2013 17:53:11 +0200

> I can try to update my kernel after I get out of appsarea.

rsyslogd is going crazy on my system (Fedora 17) on the ietf network to 
the point the system locks.  It is running my CPU up to 98% and my temp 
to 83 degrees.

I am fine on the hotel network.  I was on the ietf-a, and thought that 
was the problem, so I switched to the ietf plain and same thing.  
/var/logs/messages is now 5.6GB!  I hope that logrotate works tonight!

-- 
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:248-928-6233
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Jean Lorchat <[email-masked]>
Date: Tue, 30 Jul 2013 01:29:40 +0900

Hi,

(sorry guys, wrong address for list posting)

Although I'm using a Debian, I have similar issues depending on which AP 
I associate to. I'm using the packaged kernel from unstable whose name 
is linux-image-3.10-1-amd64 and whose version is 3.10.3-1

> the point the system locks.  It is running my CPU up to 98% and my temp

As a workaround, you can try sticking to an AP address that does not 
make the system go crazy.

For example:
sudo iwconfig wlan0 ap 2c:36:f8:dd:6d:c2

My system here started going down as soon as it reassociated to the AP 
2c:36:f8:dd:f3:72

Here is a list of associations that happened on my box, in decreasing 
time order. When the association changed for the last time (top line), 
kernel oops started appearing 50ms later.

Jul 30 00:56:14 jean-n0 kernel: [  809.629797] wlan0: RX AssocResp from 
2c:36:f8:dd:f3:72 (capab=0x101 status=0 aid=6) [crashed]
Jul 30 00:54:10 jean-n0 kernel: [  685.547804] wlan0: RX AssocResp from 
00:27:0d:ab:89:e2 (capab=0x101 status=0 aid=3) [worked]
Jul 30 00:46:01 jean-n0 kernel: [  196.356296] wlan0: RX AssocResp from 
2c:36:f8:dd:6d:c2 (capab=0x101 status=0 aid=25) [worked]
Jul 30 00:44:52 jean-n0 kernel: [  127.607454] wlan0: RX AssocResp from 
2c:36:f8:dd:6d:c2 (capab=0x101 status=0 aid=25) [worked]

I'm available for more tests if needed.

Hope this helps,
Jean

PS: an example of oops
Jul 30 00:57:27 jean-n0 kernel: [  883.158721] ------------[ cut here 
]------------
Jul 30 00:57:27 jean-n0 kernel: [  883.158726] WARNING: at 
/build/linux-39ErJp/linux-3.10.3/net/mac80211/mlme.c:366 
ieee80211_determine_chantype+0x25d/0x2ea [mac80211]()
Jul 30 00:57:27 jean-n0 kernel: [  883.158727] Modules linked in: ath3k 
btusb parport_pc ppdev lp parport bbswitch(O) bnep rfcomm bluetooth 
binfmt_misc uinput nls_utf8 nls_cp437 vfat fat loop fuse joydev uvcvideo 
coretemp videobuf2_vmalloc videobuf2_memops kvm_intel videobuf2_core 
videodev media snd_hda_codec_hdmi arc4 ath9k snd_hda_codec_realtek i915 
kvm drm_kms_helper drm ath9k_common ath9k_hw ath snd_hda_intel 
snd_hda_codec snd_hwdep snd_pcm snd_page_alloc i2c_i801 i2c_algo_bit 
i2c_core snd_seq snd_seq_device snd_timer snd mac80211 cfg80211 video 
crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper 
cryptd lrw gf128mul glue_helper mperf dell_laptop microcode mei_me 
iTCO_wdt psmouse iTCO_vendor_support rfkill lpc_ich efivars pcspkr 
dell_wmi sparse_keymap rtsx_pci_ms memstick wmi processor soundcore 
battery button ac thermal_sys dcdbas evdev serio_raw mei ext4 crc16 jbd2 
mbcache md_mod sg sr_mod cdrom sd_mod crc_t10dif rtsx_pci_sdmmc ahci 
libahci libata scsi_mod r8169 mii sdhci_pci sdhci mmc_core rtsx_pci 
mfd_core ehci_pci ehci_hcd xhci_hcd usbcore usb_common
Jul 30 00:57:27 jean-n0 kernel: [  883.158760] CPU: 0 PID: 235 Comm: 
kworker/u16:5 Tainted: G        W  O 3.10-1-amd64 #1 Debian 3.10.3-1
Jul 30 00:57:27 jean-n0 kernel: [  883.158761] Hardware name: Dell Inc. 
XPS L521X/029M77, BIOS A13 12/07/2012
Jul 30 00:57:27 jean-n0 kernel: [  883.158765] Workqueue: phy0 
ieee80211_iface_work [mac80211]
Jul 30 00:57:27 jean-n0 kernel: [  883.158765]  0000000000000000 
ffffffff8103bb5f 0000000000000000 ffff8802530adb20
Jul 30 00:57:27 jean-n0 kernel: [  883.158767]  0000000000000810 
ffff8802530ada88 ffff880253f3a800 ffffffffa03ba27d
Jul 30 00:57:27 jean-n0 kernel: [  883.158769]  0000000000000000 
ffff88025290b080 ffff880251d2c440 0000167100000000
Jul 30 00:57:27 jean-n0 kernel: [  883.158771] Call Trace:
Jul 30 00:57:27 jean-n0 kernel: [  883.158772]  [<ffffffff8103bb5f>] ? 
warn_slowpath_common+0x5b/0x70
Jul 30 00:57:27 jean-n0 kernel: [  883.158778]  [<ffffffffa03ba27d>] ? 
ieee80211_determine_chantype+0x25d/0x2ea [mac80211]
Jul 30 00:57:27 jean-n0 kernel: [  883.158785]  [<ffffffffa03bd089>] ? 
ieee80211_rx_mgmt_beacon+0xa60/0xa95 [mac80211]
Jul 30 00:57:27 jean-n0 kernel: [  883.158792]  [<ffffffffa03bd5ad>] ? 
ieee80211_sta_rx_queued_mgmt+0xc7/0x5a3 [mac80211]
Jul 30 00:57:27 jean-n0 kernel: [  883.158794]  [<ffffffff81066d1c>] ? 
find_busiest_group+0x23/0x1d0
Jul 30 00:57:27 jean-n0 kernel: [  883.158796]  [<ffffffff81066f7a>] ? 
load_balance+0xb1/0x5ca
Jul 30 00:57:27 jean-n0 kernel: [  883.158801]  [<ffffffffa039ace6>] ? 
ieee80211_iface_work+0x22e/0x2eb [mac80211]
Jul 30 00:57:27 jean-n0 kernel: [  883.158803]  [<ffffffff81052a4c>] ? 
process_one_work+0x18b/0x287
Jul 30 00:57:27 jean-n0 kernel: [  883.158805]  [<ffffffff81052ef1>] ? 
worker_thread+0x121/0x1e7
Jul 30 00:57:27 jean-n0 kernel: [  883.158806]  [<ffffffff81052dd0>] ? 
rescuer_thread+0x265/0x265
Jul 30 00:57:27 jean-n0 kernel: [  883.158808]  [<ffffffff810572f0>] ? 
kthread+0x7d/0x85
Jul 30 00:57:27 jean-n0 kernel: [  883.158810]  [<ffffffff810408ef>] ? 
do_exit+0x901/0x918
Jul 30 00:57:27 jean-n0 kernel: [  883.158812]  [<ffffffff81057273>] ? 
__kthread_parkme+0x59/0x59
Jul 30 00:57:27 jean-n0 kernel: [  883.158814]  [<ffffffff8138d2bc>] ? 
ret_from_fork+0x7c/0xb0
Jul 30 00:57:27 jean-n0 kernel: [  883.158815]  [<ffffffff81057273>] ? 
__kthread_parkme+0x59/0x59
Jul 30 00:57:27 jean-n0 kernel: [  883.158816] ---[ end trace 
7e4d6512780f0e9d ]---

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jul 2013 18:48:30 +0200

On 07/29/2013 05:53 PM, Robert Moskowitz wrote:

Fedora people hit by this bug, please try out the kernel at:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5583914

Please give feedback to the below bugzilla item, or me

https://bugzilla.redhat.com/show_bug.cgi?id=981445

Paul

> C:      248-928-6233
> F:      248-968-2824
> E:      [email-masked]
>

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 29 Jul 2013 23:57:23 +0200

> http://koji.fedoraproject.org/koji/taskinfo?taskID=5583914

Grumble.  I need F17.  I plan on skipping 18 and go to 19...

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 30 Jul 2013 09:16:31 +0200

Derek Atkins <[email-masked]> writes:

> this actually works!

I've still been using NM but simply turn off networking when the network
stops.  Interestingly, simply running "ifconfig" has been the biggest
problem.  That seems to trigger the issue more than anything else, so I
stopped doing that.

(I know, I know, I should be using "ip")
-- 
Wes Hardaker
Parsons

---

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Jul 2013 09:32:16 +0200

>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5583914

Those rpms got deleted already, please see:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5659623

> Grumble.  I need F17.  I plan on skipping 18 and go to 19...

the kernel rpm will probably work on both? :)

Paul

---

From: Derek Atkins <[email-masked]>
Date: Tue, 30 Jul 2013 03:20:48 -0700

Paul,

> http://koji.fedoraproject.org/koji/taskinfo?taskID=5659623

I just tried this kernel for x86_64 but it did not fix the problem.

I did do a little more debugging.  When I arrived this morning I could
not reproduce the problem from the EMU/IPSECME meeting in Shoeneburg
using any kernel.  However, when I moved from there towards the main
area and did an "iwlist wlan0 scan" then I succeeded in getting the bug
to show (which implies, to me, that it's possibly due to a full scan and
hearing the Potsdam APs).  The stack trace is below.

In a related note, using this test kernel from the main lobby area I was
hearing too many APs, and NM started spewing a bunch of notices about
that:

Jul 30 05:16:47 mocana NetworkManager[1506]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Jul 30 05:16:47 mocana NetworkManager[1506]: <info> (wlan0): supplicant
interface state: scanning -> disconnected
Jul 30 05:16:47 mocana NetworkManager[1506]: <info> (wlan0): supplicant
interface state: disconnected -> scanning
Jul 30 05:16:47 mocana NetworkManager[1506]: <info> (wlan0): supplicant
interface state: scanning -> disconnected
Jul 30 05:16:47 mocana NetworkManager[1506]: <info> (wlan0): supplicant
interface state: disconnected -> scanning

> the kernel rpm will probably work on both? :)

It "worked" on F18, although it did not solve the bug.  Again, turning
off NM and running ifup manually works around the problem.

-derek

Jul 30 05:17:55 mocana kernel: [  514.377194] ------------[ cut here
]------------
Jul 30 05:17:55 mocana kernel: [  514.377201] WARNING: at
net/mac80211/mlme.c:366 ieee80211_determine_chantype+0x23f/0x370
[mac80211]()
Jul 30 05:17:55 mocana kernel: [  514.377201] Modules linked in: ppdev
parport_pc parport fuse vsock ebtable_nat be2iscsi ebtables
iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi
ipt_MASQUERADE ib_iser iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM
iptable_mangle bridge rdma_cm lockd sunrpc ib_addr iw_cm ib_cm ib_sa
rfcomm stp llc bnep ib_mad ib_core ip6t_REJECT nf_conntrack_ipv4
nf_conntrack_ipv6 nf_defrag_ipv4 iscsi_tcp nf_defrag_ipv6 libiscsi_tcp
xt_conntrack nf_conntrack ip6table_filter libiscsi ip6_tables
scsi_transport_iscsi snd_hda_codec_conexant snd_hda_intel snd_hda_codec
snd_hwdep snd_seq snd_seq_device snd_pcm arc4 uvcvideo iwldvm mac80211
btusb videobuf2_vmalloc bluetooth videobuf2_memops e1000e videobuf2_core
iTCO_wdt iTCO_vendor_support videodev media snd_page_alloc snd_timer
mperf coretemp iwlwifi cfg80211 lpc_ich mfd_core i2c_i801 ptp pps_core
thinkpad_acpi snd microcode soundcore rfkill vhost_net tun macvtap
macvlan binfmt_misc kvm_intel kvm uinput dm_crypt i915 crc32_pclmul
crc32c_intel ghash_clmulni_intel i2c_algo_bit drm_kms_helper sdhci_pci
firewire_ohci drm sdhci firewire_core mmc_core crc_itu_t i2c_core wmi
video
Jul 30 05:17:55 mocana kernel: [  514.377230] CPU: 1 PID: 109 Comm:
kworker/u16:3 Tainted: G        W
3.10.3-300.test_bz981445.fc19.x86_64 #1
Jul 30 05:17:55 mocana kernel: [  514.377231] Hardware name: LENOVO
4239CTO/4239CTO, BIOS 8AET49WW (1.29 ) 07/11/2011
Jul 30 05:17:55 mocana kernel: [  514.377237] Workqueue: phy0
ieee80211_iface_work [mac80211]
Jul 30 05:17:55 mocana kernel: [  514.377238]  0000000000000009
ffff88020e389990 ffffffff81643216 ffff88020e3899c8
Jul 30 05:17:55 mocana kernel: [  514.377239]  ffffffff8105c211
ffff88020e389ad0 0000000000000810 ffff880210770800
Jul 30 05:17:55 mocana kernel: [  514.377241]  0000000000000000
ffff880212421070 ffff88020e3899d8 ffffffff8105c2ea
Jul 30 05:17:55 mocana kernel: [  514.377242] Call Trace:
Jul 30 05:17:55 mocana kernel: [  514.377244]  [<ffffffff81643216>]
dump_stack+0x19/0x1b
Jul 30 05:17:55 mocana kernel: [  514.377246]  [<ffffffff8105c211>]
warn_slowpath_common+0x61/0x80
Jul 30 05:17:55 mocana kernel: [  514.377248]  [<ffffffff8105c2ea>]
warn_slowpath_null+0x1a/0x20
Jul 30 05:17:55 mocana kernel: [  514.377255]  [<ffffffffa04a241f>]
ieee80211_determine_chantype+0x23f/0x370 [mac80211]
Jul 30 05:17:55 mocana kernel: [  514.377262]  [<ffffffffa04a5582>]
ieee80211_rx_mgmt_beacon+0x5a2/0x1280 [mac80211]
Jul 30 05:17:55 mocana kernel: [  514.377266]  [<ffffffffa0351052>] ?
iwl_poll_bit+0x52/0x90 [iwlwifi]
Jul 30 05:17:55 mocana kernel: [  514.377270]  [<ffffffffa035bcaa>] ?
__iwl_trans_pcie_set_bits_mask+0x4a/0x80 [iwlwifi]
Jul 30 05:17:55 mocana kernel: [  514.377274]  [<ffffffffa035b6b1>] ?
iwl_trans_pcie_tx+0x3f1/0x680 [iwlwifi]
Jul 30 05:17:55 mocana kernel: [  514.377282]  [<ffffffffa04a6f31>]
ieee80211_sta_rx_queued_mgmt+0x411/0x6c0 [mac80211]
Jul 30 05:17:55 mocana kernel: [  514.377284]  [<ffffffff8109a253>] ?
load_balance+0xe3/0x730
Jul 30 05:17:55 mocana kernel: [  514.377291]  [<ffffffffa047980c>]
ieee80211_iface_work+0x25c/0x360 [mac80211]
Jul 30 05:17:55 mocana kernel: [  514.377293]  [<ffffffff81079b95>]
process_one_work+0x175/0x420
Jul 30 05:17:55 mocana kernel: [  514.377294]  [<ffffffff8107a7ab>]
worker_thread+0x11b/0x3a0
Jul 30 05:17:55 mocana kernel: [  514.377296]  [<ffffffff8107a690>] ?
rescuer_thread+0x340/0x340
Jul 30 05:17:55 mocana kernel: [  514.377297]  [<ffffffff81080b00>]
kthread+0xc0/0xd0
Jul 30 05:17:55 mocana kernel: [  514.377299]  [<ffffffff81080a40>] ?
insert_kthread_work+0x40/0x40
Jul 30 05:17:55 mocana kernel: [  514.377301]  [<ffffffff8165176c>]
ret_from_fork+0x7c/0xb0
Jul 30 05:17:55 mocana kernel: [  514.377303]  [<ffffffff81080a40>] ?
insert_kthread_work+0x40/0x40
Jul 30 05:17:55 mocana kernel: [  514.377304] ---[ end trace
06475c7fd61d6e86 ]---
Jul 30 05:17:55 mocana kernel: [  514.377304] ------------[ cut here
]------------

---

From: Chris Elliott <[email-masked]>
Date: Wed, 31 Jul 2013 04:18:47 +0200

All,

After closer inspection by Derek and I of the error, when it happens, and
the Linux source, we believe that it is likely that turning on 802.11n on
the 2.4Ghz radios is likely to trigger this bug.

I've changed my mind partly because it's clear now that it's while the
client is processing beacons that the message is generated.

So, I have turned off 802.11n on the 2.4Ghz radios so we can verify this.
We may turn it back on one or more APs later if we get a fix or need to do
further testing.

Please let me know if you still see the issue.

Chris.

On Tuesday, July 30, 2013, Derek Atkins wrote:

> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

-- 
Chris Elliott
[email-masked]

---

From: Derek Atkins <[email-masked]>
Date: Wed, 31 Jul 2013 03:07:29 -0700

Alas this didn't solve the problem for me.  When I came in to Tiergarten
this morning and turned on NM the issue resurrected itself.  :(

-derek

On Tue, 2013-07-30 at 19:18 -0700, Chris Elliott wrote:
> All,
> 
> 
> After closer inspection by Derek and I of the error, when it happens,
> and the Linux source, we believe that it is likely that turning on
> 802.11n on the 2.4Ghz radios is likely to trigger this bug.
> 
> 
> So, I have turned off 802.11n on the 2.4Ghz radios so we can verify
> this. We may turn it back on one or more APs later if we get a fix or
> need to do further testing.
> 
>

---

From: Chris Elliott <[email-masked]>
Date: Wed, 31 Jul 2013 12:18:47 +0200

OK--We did modify the 5Ghz radio to meet german wifi requirements. Come by
the NOC when you have a chance and we'll find a way to isolate ourselves
sufficiently to determine if this change (which is on every IETF AP here)
is the issue.

Chris.

-- 
Chris Elliott
[email-masked]