Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #2067 (new defect)

Opened 13 years ago

Last modified 13 years ago

WDS AP delete causes Oops

Reported by: hasan@digitalpath.net Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version: v0.9.4
Keywords: WDS delete Oops Cc:
Patch is attached: 0 Pending:

Description

I setup my repeater with WDS support as follows:

wlanconfig ath create wlandev wifi0 wlanmode ap[[BR]]
iwconfig ath0 essid hehe1 channel 56[[BR]]
iwpriv ath0 wds 1[[BR]]
ifconfig ath0 up[[BR]][[BR]]

wlanconfig ath0wds0 create wlandev wifi0 wlanmode wds nosbeacon[[BR]]
iwconfig ath0wds0 channel 56[[BR]]
iwpriv ath0wds0 wds 1[[BR]]
iwpriv ath0wds0 wds_add XX:XX:XX:XX:XX:XX[[BR]]
ifconfig ath0wds0 up[[BR]][[BR]]

After verifying that the link is established by successfully pinging the other device. I did this:

wlanconfig ath0wds0 destroy

and that caused this 

10-0-201-56:/# wlanconfig ath0wds0 destroy
br0: port 3(ath0wds0) entering disabled state
device ath0wds0 left promiscuous mode
br0: port 3(ath0wds0) entering disabled state
10-0-201-56:/# BUG: unable to handle kernel paging request at virtual address 6b6b6c07
 printing eip:
c8a9340c
*pde = 00000000
Oops: 0000 [#1]
PREEMPT 
Modules linked in: wlan_scan_ap wlan_scan_sta ath_rate_sample ath_pci ath_hal(P) ath_rate_onoe ath_rate_amrr wlan via_rhine
CPU:    0
EIP:    0060:[<c8a9340c>]    Tainted: P       VLI
EFLAGS: 00010246   (2.6.22 #11)
EIP is at ieee80211_input+0x9c/0x1270 [wlan]
eax: 00000000   ebx: 00000008   ecx: 0000004e   edx: 6b6b6b6b
esi: 6b6b6b6b   edi: c7262000   ebp: c03fbf04   esp: c03fbe98
ds: 007b   es: 007b   fs: 0000  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c03fa000 task=c03cfbc0 task.ti=c03fa000)
Stack: 00000000 c7866d88 c03fbeb0 00000046 c684798c c684798c c03fbebc c031eca7 
       c6ffb2d0 c03fbf14 c8823121 c6848000 c6ffb2d0 00000000 00000000 00097220 
       030800d2 c6975020 6b6b6b6b 6b6b6b6b c71d9500 00000018 c79a6a10 c7262000 
Call Trace:
 [<c010306a>] show_trace_log_lvl+0x1a/0x30
 [<c010313a>] show_stack_log_lvl+0x9a/0xc0
 [<c0103397>] show_registers+0x1d7/0x370
 [<c010374e>] die+0x17e/0x220
 [<c010bde4>] do_page_fault+0x274/0x5b0
 [<c031f26a>] error_code+0x6a/0x70
 [<c8829381>] ath_rx_tasklet+0x2a1/0x5b0 [ath_pci]
 [<c0119db7>] tasklet_action+0x67/0x80
 [<c01199f2>] __do_softirq+0x62/0xd0
 [<c0119aaf>] do_softirq+0x4f/0x60
 [<c0119b27>] irq_exit+0x47/0x50
 [<c0104948>] do_IRQ+0x48/0xa0
 [<c0102d8e>] common_interrupt+0x2e/0x40
 [<c0100ace>] cpu_idle+0x7e/0x90
 [<c031bb16>] rest_init+0x56/0x60
 [<c03fca8f>] start_kernel+0x1ef/0x290
 [<00000000>] 0x0
 =======================
Code: b6 03 0f b6 d8 f6 c3 03 0f 85 3c 03 00 00 8b 75 d8 0f b6 5e 01 8b 75 e0 80 e3 03 88 5d d7 88 c3 80 e3 0c 88 5d d6 24 f0 88 45 d5 <80> be 9c 00 00 00 00 0f 88 0b 02 00 00 83 fa 06 0f 87 d9 00 00 
EIP: [<c8a9340c>] ieee80211_input+0x9c/0x1270 [wlan] SS:ESP 0068:c03fbe98

Entering kdb (current=0xc03cfbc0, pid 0) Oops: Oops
due to oops @ 0xc8a9340c
eax = 0x00000000 ebx = 0x00000008 ecx = 0x0000004e edx = 0x6b6b6b6b 
esi = 0x6b6b6b6b edi = 0xc7262000 esp = 0xc03fbe98 eip = 0xc8a9340c 
ebp = 0xc03fbf04 xss = 0xc0260068 xcs = 0x00000060 eflags = 0x00010246 
xds = 0xc684007b xes = 0xc03f007b origeax = 0xffffffff &regs = 0xc03fbe60
kdb> btc
btc: cpu status: Currently on cpu 0
Available cpus: 0
Stack traceback for pid 0
0xc03cfbc0        0        0  1    0   R  0xc03cfd70 *swapper
esp        eip        Function (args)
0xc03fbe8c 0xc8a9340c [wlan]ieee80211_input+0x9c
0xc03fbeb4 0xc031eca7 _spin_unlock+0x27
0xc03fbec0 0xc8823121 [ath_pci]ath_uapsd_processtriggers+0x1f1
0xc03fbf08 0xc8829381 [ath_pci]ath_rx_tasklet+0x2a1
0xc03fbf14 0xc0132f45 __lock_release+0x25
0xc03fbf3c 0xc0119db7 tasklet_action+0x67
0xc03fbf4c 0xc01199f2 __do_softirq+0x62
0xc03fbf60 0xc0119aaf do_softirq+0x4f
0xc03fbf6c 0xc0119b27 irq_exit+0x47
0xc03fbf74 0xc0104948 do_IRQ+0x48
0xc03fbf78 0xc031c188 schedule+0x3b8
0xc03fbf94 0xc0102d8e common_interrupt+0x2e
0xc03fbfc4 0xc0100a26 default_idle+0x46
0xc03fbfd4 0xc0100ace cpu_idle+0x7e
0xc03fbfdc 0xc031bb16 rest_init+0x56
0xc03fbfe4 0xc03fca8f start_kernel+0x1ef
0xc03fbfec 0xc03fc4f0 unknown_bootoption

Has anyone else encountered this? My theory is that after the device has been deleted any new incoming packets, that are being handled by the interrupt, can't find the virtual device and the input function causes it to crash.

Change History

(follow-ups: ↓ 2 ↓ 3 ↓ 5 ) 07/23/08 06:24:14 changed by mrenzmann

Did you already try whether the issue still exists in trunk?

(in reply to: ↑ 1 ) 07/23/08 19:35:27 changed by anonymous

Replying to mrenzmann:

Did you already try whether the issue still exists in trunk?

No, I will try that right now and update you with the results.

(in reply to: ↑ 1 ; follow-up: ↓ 4 ) 07/30/08 01:42:11 changed by HR

Replying to mrenzmann:

Did you already try whether the issue still exists in trunk?

I have been trying to establish a link with a driver compiled from the trunk (downloaded Jul 25th) source, but, so far unsuccessful. The radio's don't link up and the iwlist ath0 scan command only performs scan in the 2.4Ghz band.

Therefore, this is only reproducible in v9.4. However, does the debug output make any sense? Why are spin_locks causing this issue?

HR.

(in reply to: ↑ 3 ) 08/27/08 03:19:28 changed by hasan r

Replying to HR:

Replying to mrenzmann:

Did you already try whether the issue still exists in trunk?

I have been trying to establish a link with a driver compiled from the trunk (downloaded Jul 25th) source, but, so far unsuccessful. The radio's don't link up and the iwlist ath0 scan command only performs scan in the 2.4Ghz band. Therefore, this is only reproducible in v9.4. However, does the debug output make any sense? Why are spin_locks causing this issue? HR.

With some debugging I've found out that ni->ni_vap->iv_ic && ni->ni_vap->iv_dev are the issue. Somehow, they get unset when you run the command iwpriv ath0wds0 wds_del (MAC ADDRESS). I found a similar issue in Ticket #1127, the source is different but the issue is the same. That ticket has been set to trunk, can anyone specify as to what was changed to fix this?

(in reply to: ↑ 1 ) 08/30/08 03:05:51 changed by anonymous

I compiled the latest trunk version, and was able to successfully link up two APs in Repeater mode via WDS. And I think its safe to say this issue does not exist in trunk.

I am still not sure why exactly it was caused and what fixed it. If someone has in-depth understanding of this, please do update this ticket.

Replying to mrenzmann:

Did you already try whether the issue still exists in trunk?