[ previous ] [ next ] [ threads ]
 
 From:  rene moser <mail at renemoser dot net>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Kernel panic under load, 1.3b14 on Alix 2c3
 Date:  Thu, 04 Sep 2008 11:26:34 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

I can confirm this issue on alix.
Are there any plans to fix this?
Any other embedded platforms affected?
Should this bug be filed to freebsd kernel devs?

rm

Stefan Hegnauer wrote:
> After several unintentional reboots over the last couple days I startet to
> investigate. It seems that for some reason the kernel panics under moderate
> load, which in turn leads to a reboot.
> 
> How to replicate:
> Easiest with some instances of nmap running against some (4-6) targets on
> the WAN / internet side of m0n0, these instances can run from the same PC
> though (Windows XP over a WLAN AP in my case):
> 	nmap -v -A -PN -p1-65535 -T insane <your.target.org>
> Using less agressive timings crash m0n0 as well, it just takes longer until
> m0n0 reboots.
> 
> An out-of-the box installation of m0n0wall 1.3b14 embedded on my Alix 2c3
> (only rule change: enable any to any from LAN to WAN; and using PPPoE in my
> case) will crash within minutes.
> 
> On the serial port of my Alix 2c3 I catched the following output, the first
> two lines are probably the most interesting ones:
> 
> 	ipf_nattable_max reduced to 86282
> 	panic: kmem_malloc(4096): kmem_map too small: 80642048 total
> allocated
> 	Uptime: 13m23s
> 	Cannot dump. No dump device defined.
> 	Automatic reboot in 15 seconds - press a key on the console to abort
> 	Rebooting...
> 	PC Engines ALIX.2 v0.99
> 	640 KB Base Memory
> 	261120 KB Extended Memory
> 
> 	01F0 Master 848A SanDisk SDCFB-64                        
> 	Phys C/H/S 490/8/32 Log C/H/S 490/8/32
> 
> 	BIOS drive C: is disk0
> 	BIOS 640kB/261120kB available memory
> 
> 	FreeBSD/i386 bootstrap loader, Revision 1.1
> 	(root at mb63 dot neon1 dot net, Sat Aug 23 21:46:54 CEST 2008)
> ....
> 
> 
> I also uploaded vmstat to m0n0 (see
> http://m0n0.ch/wall/list/showmsg.php?id=344/93) and had it run on another
> trial. This is what it spit out: 
> 
> $ /tmp/vmstat -c 1000 -w 1
>  procs      memory      page                   disk   faults      cpu
>  r b w     avm    fre  flt  re  pi  po  fr  sr ad0   in   sy  cs us sy id
>  0 2 0   21220 201252   32   0   0   0  27   0   0 2271   94 2298  1  2 97
>  0 2 0   21220 201244    4   0   0   0   0   0   0 2139  117 2070  0  0 100
>  ...
>  0 2 0   21220 201068    0   0   0   0   0   0   0 3905  111 4417  0 10 90
> --> starting first instance of nmap
>  0 2 0   21220 200760    0   0   0   0   0   0   0 3904  111 4361  0 20 80
>  0 2 0   21220 200456    0   0   0   0   0   0   0 3900  111 4402  0 19 81
>  0 2 0   21220 200124    0   0   0   0   0   0   0 4080  184 4680  0 19 81
>  0 2 0   21220 199760    0   0   0   0   0   0   0 4241  111 4861  0 14 86
>  0 2 0   21220 199392    0   0   0   0   0   0   0 4296  111 4971  0 14 86
>  0 2 0   21220 199016    0   0   0   0   0   0   0 4272  111 4932  0 12 88
>  ...
>  0 2 0   21220 136512    1   0   0   0   0   0   0 5097 1017 6058  0 33 67
>  0 2 0   21220 136512    0   0   0   0   0   0   0 5117  138 5978  1 30 69
>  0 2 0   21220 136512    0   0   0   0   0   0   0 5103  116 6016  0 31 69
> --> kernel panic
> 
> As I see it, the CPU was not overloaded (with still some 70% of idling CPU),
> and although there was around 130MB of free memory the kernel run out of
> space.
> 
> Does anyone have a clue what to try next? In my understanding dropping of
> connections would be perfectly ok under heavy load, panicking of the kernel
> is certainly not. Am I too picky?
> 
> -Stefan
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki/qcoACgkQHXu/ROUxaMc48ACfYjWQ5jr0KiuFY4fpffV7lh6U
MaEAnRdtTqUzbVj3d2As6a0klzh+5iJZ
=/CwM
-----END PGP SIGNATURE-----