Hi. I have this wireless card: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Device 1a3b:1067 Kernel driver in use: ath9k Kernel modules: ath9k If i'm trying to enter monitor mode i have kernel panic(no traces on .36 kernel). This issue is reproducable on 2.6.36 and later kernels (i've tested this morning for .37-rc5). Some other people told me, that they have this bug too and give me their trace: >>While my card doen't work porperty with 2.6.35/36, randomly invalid leaving >>such in dmesg: >> >>Call Trace: >> [<c12e64dd>] ? printk+0x18/0x1b >> [<c1097037>] __report_bad_irq.clone.1+0x27/0x90 >> [<c1095b94>] ? handle_IRQ_event+0x44/0x1a0 >> [<c10971f2>] note_interrupt+0x152/0x190 >> [<c1097d0b>] handle_fasteoi_irq+0x9b/0xc0 >> [<c1005d68>] handle_irq+0x18/0x30 >> [<c1005a47>] do_IRQ+0x47/0xc0 >> [<c1106fc4>] ? sys_poll+0x54/0xd0 >> [<c1003d30>] common_interrupt+0x30/0x38 >> [<c12e0000>] ? detect_extended_topology+0x7d/0x182 >>handlers: >>[<fa3eb1a0>] (ath_isr+0x0/0x1f0 [ath9k]) >>Disabling IRQ #17
Looks like it is a mac80211 issue, monitor mode crashes with ath5k, ath9k, iwlagn and ath9k_htc. Here is a trace: kernel BUG at net/core/skbuff.c:146! invalid opcode: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/platform/regulatory.0/uevent CPU 1 Modules linked in: arc4 ecb ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 ext2 mct_u232 usbserial snd_hda_codec_analog snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device i915 sndd Pid: 0, comm: kworker/0:0 Not tainted 2.6.36-ARCH #1 7661GN4/7661GN4 RIP: 0010:[<ffffffff812dabd6>] [<ffffffff812dabd6>] skb_push+0x76/0x80 RSP: 0018:ffff880001b03b80 EFLAGS: 00010286 RAX: 0000000000000087 RBX: ffff88007a38d600 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000206 RBP: ffff880001b03ba0 R08: ffffffff8159dcb0 R09: 0000000000000305 R10: 0000000000000000 R11: 0000000000000000 R12: ffff880078e544c0 R13: ffff880078e550b0 R14: ffff880078e550b0 R15: ffff880076c4ec00 FS: 0000000000000000(0000) GS:ffff880001b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f8693f0ce50 CR3: 0000000001551000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kworker/0:0 (pid: 0, threadinfo ffff88007d0d8000, task ffff88007d08cc50) Stack: 0000000000000112 0000000000000140 ffff880076ca7000 ffffffff812dc142 <0> ffff880001b03bc0 ffffffff812fe944 ffff88007a38d600 ffff880078e544c0 <0> ffff880001b03c20 ffffffff812e52f2 ffff88007a38d600 ffff880076c4ec00 Call Trace: <IRQ> [<ffffffff812dc142>] ? __alloc_skb+0x72/0x160 [<ffffffff812fe944>] skb_defer_rx_timestamp+0x14/0x80 [<ffffffff812e52f2>] netif_receive_skb+0x32/0x110 [<ffffffff812dcd0d>] ? skb_copy_expand+0xad/0x120 [<ffffffffa052df25>] ieee80211_rx+0x7c5/0xa20 [mac80211] [<ffffffffa03dc034>] ? ath_rxbuf_alloc+0x34/0xc0 [ath] [<ffffffff812dc142>] ? __alloc_skb+0x72/0x160 [<ffffffff810da698>] ? perf_event_task_tick+0x148/0x180 [<ffffffffa055afc3>] ath_rx_send_to_mac80211.clone.19+0x73/0xa0 [ath9k] [<ffffffffa055c772>] ath_rx_tasklet+0xcc2/0x1020 [ath9k] [<ffffffff81012670>] ? nommu_map_page+0x0/0x80 [<ffffffff81084d75>] ? tick_program_event+0x25/0x30 [<ffffffffa055a160>] ath9k_tasklet+0x130/0x1d0 [ath9k] [<ffffffff8105b75d>] tasklet_action+0x7d/0x100 [<ffffffff8105c063>] __do_softirq+0xc3/0x220 [<ffffffff8100be5c>] call_softirq+0x1c/0x30 [<ffffffff8100e155>] do_softirq+0x65/0xa0 [<ffffffff8105c2bd>] irq_exit+0x8d/0x90 [<ffffffff8100dd60>] do_IRQ+0x70/0xf0 [<ffffffff813962d3>] ret_from_intr+0x0/0x11 [<ffffffffa02b81d0>] ? acpi_idle_enter_bm+0x252/0x28a [processor] [<ffffffffa02b81c9>] ? acpi_idle_enter_bm+0x24b/0x28a [processor] [<ffffffff812c8abd>] cpuidle_idle_call+0x8d/0x170 [<ffffffff81009236>] cpu_idle+0xa6/0x170 [<ffffffff8107b311>] ? raw_notifier_call_chain+0x11/0x20 [<ffffffff8138cfc2>] start_secondary+0x215/0x21c Code: 89 4c 24 10 8b 8f d0 00 00 00 48 89 4c 24 08 8b bf cc 00 00 00 89 f1 48 8b 75 08 48 89 3c 24 48 c7 c7 f0 b4 48 81 e8 0d 79 0b 00 <0f> 0b 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 20 8b 57 6c
Hmmm...I thought -rc5 was supposed to fix the skb_defer_rx_timestamp thing... Does the problem disappear if you disable CONFIG_NETWORK_PHY_TIMESTAMPING?
Yep, running today's wireless-testing with CONFIG_NETWORK_PHY_TIMESTAMPING disabled seems okay. I saw the panic on the stock kernel in Arch linux (2.6.36). I'll verify if enabling said option on wireless-testing borks anything ...
Panics with today's wireless-testing and CONFIG_NETWORK_PHY_TIMESTAMPING enabled.
The following three bugs are all duplicates of each other: 24102 24292 24452 They all have the same root cause, and all are fixed by the patch posted by Eric Dumazet on netdev: http://article.gmane.org/gmane.linux.network/180108 The work-around is to disable CONFIG_NETWORK_PHY_TIMESTAMPING. Richard
(In reply to comment #2) > Hmmm...I thought -rc5 was supposed to fix the skb_defer_rx_timestamp thing... Nope, but the fix is submitted on the netdev list for inclusion in 2.6.37. http://article.gmane.org/gmane.linux.network/180108 I will also try to get the fix into 2.6.36 stable/longterm. Richard
*** This bug has been marked as a duplicate of bug 24102 ***
*** Bug 23852 has been marked as a duplicate of this bug. ***