#334: adhoc memory leak
----------------------------------+-----------------------------------------
Reporter: kiru | Owner:
Type: defect | Status: new
Priority: critical | Milestone: version 0.9.0 - move to new
codebase
Component: madwifi: driver | Version: trunk
Resolution: | Keywords: adhoc memory leak
Patch_attached: 0 |
----------------------------------+-----------------------------------------
Comment (by Vikram):
Good News ! Maybe !
My setup had three ad-hoc nodes (s1, s2 and r). 'r' is the receiver
running two netserver intances. 's1' and 's2' ran netperf (UDP_STREAM) to
the netservers on 'r'.
If 'r' somehow has duplicate entries for 's1', then the traffic coming
into 'r' from 's1' causes heavy memory leaks. NOTE that if in this
situation 's2' sends traffic to 'r', that does NOT cause any problems.
Sometimes the duplicate entry does not happen, I am not sure why. But when
they do, it is virtually assured that the memory increase will cause a
panic in the kernel.
Based on the patch by Georg in [http://madwifi.org/ticket/441], I
downloaded the r1457 version and the patch for avoiding duplicate node
problems in input. The duplicate entries did not occur, and hence the
massive leaks leading to panic did not happen. There was still some
relatively minor leak, I am not sure what the source of that is. But that
one existed in r1454 as well. Probably nothing to do with madwifi, but I
am not sure
The panic that was caused is shown here:
{{{
Mar 3 13:51:45 ar83-176 kernel: BUG: soft lockup detected on CPU#0!
Mar 3 13:51:45 ar83-176 kernel:
Mar 3 13:51:45 ar83-176 kernel: Pid: 13538, comm: wlanconfig
Mar 3 13:51:45 ar83-176 kernel: EIP: 0060:[<e0c592ed>] CPU: 0
Mar 3 13:51:45 ar83-176 kernel: EIP is at
ieee80211_iterate_nodes+0xd1/0x1ec [wlan]
Mar 3 13:51:45 ar83-176 kernel: EFLAGS: 00200246 Tainted: P
(2.6.11-1.1369_FC4)
Mar 3 13:51:45 ar83-176 kernel: EAX: cc71d000 EBX: ccd82000 ECX: 00000000
EDX: 00000100
Mar 3 13:51:45 ar83-176 kernel: ESI: 0000001f EDI: cfbb0c48 EBP: cc71df04
DS: 007b ES: 007b
Mar 3 13:51:45 ar83-176 kernel: CR0: 8005003b CR2: 0079fac0 CR3: 0d1db000
CR4: 000006d0
Mar 3 13:51:45 ar83-176 kernel: [<e0c67962>] get_sta_space+0x0/0x53
[wlan]
Mar 3 13:51:45 ar83-176 kernel: [<e0c67cb8>]
ieee80211_ioctl_getstainfo+0x45/0xbe [wlan]
Mar 3 13:51:45 ar83-176 kernel: [<e0c67d6a>] ieee80211_ioctl+0x0/0xa1
[wlan]
Mar 3 13:51:45 ar83-176 kernel: [<c03099d9>] dev_ifsioc+0xf9/0x321
Mar 3 13:51:45 ar83-176 kernel: [<c0309d05>] dev_ioctl+0x104/0x28b
Mar 3 13:51:45 ar83-176 kernel: [<c02fd9f4>] sock_ioctl+0x0/0x244
Mar 3 13:51:45 ar83-176 kernel: [<c0192de9>] do_ioctl+0x19/0x55
Mar 3 13:51:45 ar83-176 kernel: [<c0192f17>] vfs_ioctl+0x50/0x1aa
Mar 3 13:51:45 ar83-176 kernel: [<c01930ce>] sys_ioctl+0x5d/0x6b
Mar 3 13:51:45 ar83-176 kernel: [<c0103a51>] syscall_call+0x7/0xb
Mar 3 13:51:46 ar83-176 kernel: [<c01505e1>] softlockup_tick+0x95/0x1b8
Mar 3 13:51:46 ar83-176 kernel: [<c012cd3d>] update_wall_time+0x14/0x40
Mar 3 13:51:46 ar83-176 kernel: [<c012d331>] do_timer+0x4d/0xfb
Mar 3 13:51:46 ar83-176 kernel: [<c0108c2e>] timer_interrupt+0x60/0x1b5
Mar 3 13:51:46 ar83-176 kernel: [<c015085d>] handle_IRQ_event+0x2e/0x5a
Mar 3 13:51:46 ar83-176 kernel: [<c015093c>] __do_IRQ+0xb3/0x367
Mar 3 13:51:46 ar83-176 kernel: [<c0105b1d>] do_IRQ+0x4a/0x82
Mar 3 13:51:46 ar83-176 kernel: =======================
Mar 3 13:51:46 ar83-176 kernel: [<c0103c0e>] common_interrupt+0x1a/0x20
Mar 3 13:51:46 ar83-176 kernel: [<e0c6007b>]
ieee80211_dturbo_switch+0x17/0xf6 [wlan]
Mar 3 13:51:46 ar83-176 kernel: [<e0c592ed>]
ieee80211_iterate_nodes+0xd1/0x1ec [wlan]
Mar 3 13:51:46 ar83-176 kernel: [<e0c67962>] get_sta_space+0x0/0x53
[wlan]
Mar 3 13:51:46 ar83-176 kernel: [<e0c67cb8>]
ieee80211_ioctl_getstainfo+0x45/0xbe [wlan]
Mar 3 13:51:46 ar83-176 kernel: [<e0c67d6a>] ieee80211_ioctl+0x0/0xa1
[wlan]
Mar 3 13:51:46 ar83-176 kernel: [<c03099d9>] dev_ifsioc+0xf9/0x321
Mar 3 13:51:46 ar83-176 kernel: [<c0309d05>] dev_ioctl+0x104/0x28b
Mar 3 13:51:46 ar83-176 kernel: [<c02fd9f4>] sock_ioctl+0x0/0x244
Mar 3 13:51:46 ar83-176 kernel: [<c0192de9>] do_ioctl+0x19/0x55
Mar 3 13:51:46 ar83-176 kernel: [<c0192f17>] vfs_ioctl+0x50/0x1aa
Mar 3 13:51:46 ar83-176 kernel: [<c01930ce>] sys_ioctl+0x5d/0x6b
Mar 3 13:51:46 ar83-176 kernel: [<c0103a51>] syscall_call+0x7/0xb
}}}
I think someone else should test the r1457-along-with-the-patch using
iperf or netperf and see if this ticket can be deemed partially closed !
--
Ticket URL: <http://madwifi.org/ticket/334>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity