Re: [Acx100-users] System hangs and other Problems with monitor mode

[Witold B. <ba...@sm...>]

On 06-04 22:11, Andreas Mohr wrote:
> Hi,
> 
> On Mon, Jun 04, 2012 at 09:13:55PM +0200, Witold Baryluk wrote:
> > Hi,
> > 
> > I am able sometimes to run monitor mode (airodump-ng) on my DWL-520+
> > using acx-mac80211 git driver, but often and repeatly see system hangs
> > and other problems, probably releated to memory corruption.
> 
> You don't want to tell me that I should spend more time on this project? :-P
> (in fact the WLAN side of things is a bit neglected,
> thus I'll have some activity soon)
> 

:) I'm really glad that somebody is still doing something with acx driver!
I was running this card like 8 years ago, when this project was just
starting, and it looks that again it is getting better shape. Maybe even
it could be merged upstream in the end of this year :D (I do not know if
legal issues are resolved about code, hope they are).


As I ssaid, monitor mode is working, it just sometimes hangs system. It
is probably some memory corruption, and once fixed should resolve
probably many other problems. I will also try reviewing code manually to
see where problem may sit.

> 
> > System in this case was still running, but for safety I rebooted it.
> > 
> > However system can hang even in other circumcances, like just stoping
> > apache! (which probably listens on *:80).
> > 
> > It looks like memory corruption, but do not know how to start debuging it.
> > 
> > Maybe more debuging message in ioctl handling?
> > 
> > 
> > Any ideas?
> 
> Yes (possibly):
> 
> linux/lib/Kconfig.debug:
> 
> config DEBUG_KMEMLEAK
>         bool "Kernel memory leak detector"
>         depends on DEBUG_KERNEL && EXPERIMENTAL && \
>                 (X86 || ARM || PPC || MIPS || S390 || SPARC64 || SUPERH || MICROBLAZE || TILE)
> 
>         select DEBUG_FS
>         select STACKTRACE if STACKTRACE_SUPPORT
>         select KALLSYMS
>         select CRC32
>         help
>           Say Y here if you want to enable the memory leak
>           detector. The memory allocation/freeing is traced in a way
>           similar to the Boehm's conservative garbage collector, the
>           difference being that the orphan objects are not freed but
>           only shown in /sys/kernel/debug/kmemleak. Enabling this
>           feature will introduce an overhead to memory
>           allocations. See Documentation/kmemleak.txt for more
>           details.
> 
>           Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
>           of finding leaks due to the slab objects poisoning.
> 
>           In order to access the kmemleak file, debugfs needs to be
>           mounted (usually at /sys/kernel/debug).
> 
> 
> IOW: enable DEBUG_KMEMLEAK, DEBUG_SLAB and SLUB_DEBUG. That will hopefully
> aid in getting these things tracked down.
> 
I have already DEBUG_SLAB and SLUB_DEBUG and use it on daily basis :D
(it have some impact on performance, but acceptable), will enabled
DEBUG_KMEMLEAK also (this one makes performances drop significantly and
memory ussage raises considerably, to use only when needed).

Will also connect to serial console to retrive full kernel message
information.

> Thank you very much for your interesting and detailed report!
> 

I also was planning to test this card in machine with Alpha architecture
CPU, so be prepared for some more reports (or sucess stories) :D



Thanks,
Witek

-- 
Witold Baryluk