#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

Reply via email to