From nobody@FreeBSD.org  Wed Dec 21 02:36:37 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 36A9A1065670
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 21 Dec 2011 02:36:37 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 21C6D8FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 21 Dec 2011 02:36:37 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pBL2aapx064875
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 21 Dec 2011 02:36:36 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id pBL2aaNA064874;
	Wed, 21 Dec 2011 02:36:36 GMT
	(envelope-from nobody)
Message-Id: <201112210236.pBL2aaNA064874@red.freebsd.org>
Date: Wed, 21 Dec 2011 02:36:36 GMT
From: Oleg Ginzburg <olevole@olevole.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: FreeBSD 9x amd64 unstable while work with RAM
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         163493
>Category:       kern
>Synopsis:       FreeBSD 9x amd64 unstable while work with RAM
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 21 02:40:09 UTC 2011
>Closed-Date:    
>Last-Modified:  Thu Dec 22 08:10:10 UTC 2011
>Originator:     Oleg Ginzburg
>Release:        9.0-RC3
>Organization:
>Environment:
>Description:
I have found out stable lag of systems amd64 at employment of all memory. This problem isn't reproduced on i386 (
I have checked up on FreeBSD-current on my Asus EE PC Book - problems aren't present. Also has checked up in VirtualBox with FreeBSD 9.0-RC3/i386. Both systems has written "No space left on device" at my method of testing (see below))

Also, in the absence of any special tuning options in sysctl.conf and loader.conf (like maxusers etc) I see on many systems incorrect value vm.kmem_size_max (amd64 only). The unstable condition remains when i set vm.kmem_size\*  equal or less then the hw.physmem


>How-To-Repeat:
1) mdconfig -a -t malloc -s Ng

Where num N is greater then RAM ( the problem also is actual while N  < physmem+swap )

2) dd if=/dev/random of=/dev/md0 bs=10m

3) watch on the top. At exhaustion Free memory the problem is comes
>Fix:


>Release-Note:
>Audit-Trail:

From: Oleg Ginzburg <olevole@olevole.ru>
To: bug-followup@freebsd.org,
 olevole@olevole.ru
Cc:  
Subject: Re: kern/163493: FreeBSD 9x amd64 unstable while work with RAM
Date: Wed, 21 Dec 2011 06:54:59 +0400

 I seem have hastened with the statement amd64-only.=20
 i386 falls in a panic through any time after that test with:
 
 panic: kmem_malloc(4096): kmem_map too small: 432013312 total allocated cpu=
 id=20
 =3D 2
 KDB: enter: panic
 [ thread pid 1033 tid 100154 ]
 Stopped at  kbd_enter+0x3a: movl $0,kbd_why
 
 Last trace before panic is:
 zone_fetch_slab ->
 keg_fetch_flab ->
 keg_alloc_slab ->
 page_alloc ->
 kmem_malloc ->
 
 ( Unfortunately currenlty there is no possibility to get dump as is )=20
 
 
 
 
 =2D-=20
 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, With respect,
 =D0=9E=D0=BB=D0=B5=D0=B3 =D0=93=D0=B8=D0=BD=D0=B7=D0=B1=D1=83=D1=80=D0=B3 O=
 leg Ginzburg
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D
 E-mail: mailto: olevole@olevole.ru
 Skype: olegginzburg
 XMPP/Jabber: olevole@jabber.ru
 

From: Oleg Ginzburg <oleg.ginzburg@nevosoft.ru>
To: bug-followup@freebsd.org,
 olevole@olevole.ru
Cc:  
Subject: Re: kern/163493: FreeBSD 9x amd64 unstable while work with RAM
Date: Thu, 22 Dec 2011 11:37:07 +0400

 Update:
 
 The described case for the physical machine is ZFS-related. 
 
 It is reproduced at ZFS Volume-based swap:
 
 (for example - da0 is empty disk):
 kldload zfs
 echo 'zfs_load="YES"' >> /etc/rc.conf
 zpool create swp /dev/da0
 zfs create -V 4G swp/swap
 zfs set org.freebsd:swap=on zwp/swap
 zfs set checksum=off swp/swap
 
 service zfs restart
 service zvol restart
 
 then repeat actions from How-to-repeat
 
 For VirtualBox a case - problems arise without ZFS. It seems, it is related 
 with inheritance kmem\* or other parameters from the master host
>Unformatted:
