From owner-freebsd-emulation@FreeBSD.ORG Sun Mar 11 00:07:52 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3233106566C; Sun, 11 Mar 2012 00:07:52 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9918FC15; Sun, 11 Mar 2012 00:07:52 +0000 (UTC) Received: by iahk25 with SMTP id k25so5799104iah.13 for ; Sat, 10 Mar 2012 16:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wbHddrRhJcEYwwWmf6xDnejlzV1TVdXsl4Xo1XDEXNg=; b=EyViLLEqQXk+CiR1PKDGo2uaK/3UkluI1ka/ctNr3AcRMptYhnbPBLH7bk8p8UBarb zB4F846s23eIrEeEOgKO3lCP+Ym3j/l2WQDBXqYtl/ylaCWdogl7yOPiiwZiDRqn8z0V GUfu7XKvhn+0+WHTWUw+i4IfAlQrf8iyT1iB29gLsG3VyFRbuVdn36DwH3pMdaChn62Q UR5gSTyny+xUzsCpnAAepypSp45DNYZBn7oz8/3fhVNw4zmc7pKiCATxl4u+eeKfANUr 8qSYfcdsoMWKE6GccIyXIUb2XQdncMrQJ9kSdw6AeqofF94U20VdvvsaKQgBOYn2HYdW GdVw== MIME-Version: 1.0 Received: by 10.182.111.3 with SMTP id ie3mr3194918obb.14.1331424471788; Sat, 10 Mar 2012 16:07:51 -0800 (PST) Received: by 10.60.17.10 with HTTP; Sat, 10 Mar 2012 16:07:51 -0800 (PST) In-Reply-To: References: <9e02ac1bc0f7a8043f28ced31e319a20@bluelife.at> Date: Sat, 10 Mar 2012 18:07:51 -0600 Message-ID: From: Brandon Gooch To: Bernhard Froehlich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-emulation@freebsd.org, "Bjoern A. Zeeb" , Marko Zec Subject: Re: [PATCH] VirtualBox 4.1.8 kmod panic with VIMAGE kernel X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 00:07:52 -0000 On Sat, Mar 10, 2012 at 9:50 AM, Brandon Gooch wrote: > On Sat, Mar 10, 2012 at 3:00 AM, Bernhard Froehlich w= rote: >> On 10.03.2012 05:42, Brandon Gooch wrote: >>> >>> It's my guess that not many people are running VirtualBox on a >>> VIMAGE-enabled kernel. =A0However, for those of us who do (just me?), >>> the attached patch is required to prevent a panic when running >>> VirtualBox in such an environment. The patch belongs to the >>> emulators/virtualbox-ose-kmod port. >>> >>> --- src/VBox/HostDrivers/VBoxNetAdp/VBoxNetAdp.c.orig =A0 2011-12-19 >>> 07:01:06.000000000 -0600 >>> +++ src/VBox/HostDrivers/VBoxNetAdp/VBoxNetAdp.c =A0 =A0 =A0 =A02011-12= -26 >>> 14:54:27.000000000 -0600 >>> @@ -1189,6 +1189,7 @@ >>> =A0int =A0vboxNetAdpInit(void) >>> =A0{ >>> =A0 =A0 unsigned i; >>> + =A0 =A0PVBOXNETADP pVboxnet0; >>> =A0 =A0 /* >>> =A0 =A0 =A0* Init common members and call OS-specific init. >>> =A0 =A0 =A0*/ >>> @@ -1201,7 +1202,8 @@ >>> =A0 =A0 =A0 =A0 vboxNetAdpOsInit(&g_aAdapters[i]); >>> =A0 =A0 } >>> >>> - =A0 =A0return VINF_SUCCESS; >>> + =A0 =A0/* Create vboxnet0 */ >>> + =A0 =A0return vboxNetAdpCreate(&pVboxnet0, NULL); >>> =A0} >>> >>> =A0/** >>> >>> If there is a more appropriate fix, please help me find it, otherwise, >>> it would be great to have this committed! >> >> >> Sorry, that I haven't committed the patch until now. Do you agree that >> this patch is licensed under MIT License so I can send it upstream? > > Yes, absolutely. Do with it as you please... > > What I found when tracking this down led to this commit: > > https://www.virtualbox.org/changeset/35785/vbox > > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/HostDrivers/VBoxNe= tAdp/VBoxNetAdp.c?rev=3D35785 > > I'm not sure how the initial VBox network adapter is supposed to be > created; maybe it should be deferred to the OS-specific init process > (in VBoxNetAdp-freebsd.c)? Trouble is, not sure how to do that > exactly, but anyway it seems more like a bug that was introduced. > > Attempting to push this upstream will reveal something I imagine :) > >> Current VIMAGE support is only for vboxnetflt and you are touching >> vboxnetadp so that is probably why nobody used it before. Have you >> tested it with a non VIMAGE kernel? > > I tested it with GENERIC, a custom kernel WITHOUT VIMAGE, and a custom > kernel WITH VIMAGE. I tested on 9-STABLE (from this month) and now > 10-CURRENT. > >> -- >> Bernhard Froehlich >> http://www.bluelife.at/ Y'know, I think the real problem is that a VIMAGE-enabled kernel doesn't allow for the creation of new interfaces after boot. At least it was that way back in late 2010 when I was using a USB network device... So this is at BEST an attempt at a work-around, which I suspect will fail in any case more complicated than VirtualBox running in vnet0 with 1 network interface -- but I'm not totally sure I even understand the way the VBoxNetFlt and VBoxNetAdp drivers work! -Brandon From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 12 06:34:37 2012 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22954106564A for ; Mon, 12 Mar 2012 06:34:37 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id E7DF38FC0C for ; Mon, 12 Mar 2012 06:34:36 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q2C6NZs6042809 for ; Sun, 11 Mar 2012 23:23:36 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F5D9666.5000209@rawbw.com> Date: Sun, 11 Mar 2012 23:23:34 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-emulation@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Screen of Ubuntu64 guest doesn't update when 3D acceleration option is "on" X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 06:34:37 -0000 Once I enabled 3D acceleration in "Display options", Ubuntu64 guest screen stopped updating after guest window is covered by some other host window. So that areas that became invisible are filled with garbage until some window is closed or moved in guest and it repaints the whole screen. This doesn't happen with Windows7 guest with 2D and 3D acceleration. vbox-4.1.8 on 9.0 amd64 host Yuri From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 12 07:52:59 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 332DC1065678 for ; Mon, 12 Mar 2012 07:52:59 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id A46878FC18 for ; Mon, 12 Mar 2012 07:52:58 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 3846E7; Mon, 12 Mar 2012 08:48:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 12 Mar 2012 08:47:47 +0100 From: Bernhard Froehlich To: Yuri In-Reply-To: <4F5D9666.5000209@rawbw.com> References: <4F5D9666.5000209@rawbw.com> Message-ID: <19730368ac9f21f973e9b1de77feaa2d@bluelife.at> X-Sender: decke@bluelife.at User-Agent: Roundcube Webmail/0.7.1 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0203.4F5DAA23.0168,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: freebsd-emulation@freebsd.org Subject: Re: Screen of Ubuntu64 guest doesn't update when 3D acceleration option is "on" X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 07:52:59 -0000 On 12.03.2012 07:23, Yuri wrote: > Once I enabled 3D acceleration in "Display options", Ubuntu64 guest > screen stopped updating after guest window is covered by some other > host window. So that areas that became invisible are filled with > garbage until some window is closed or moved in guest and it repaints > the whole screen. > > This doesn't happen with Windows7 guest with 2D and 3D acceleration. > > vbox-4.1.8 on 9.0 amd64 host This doesn't sound like it's FreeBSD specific. Have you already searched in their bug database for that? -- Bernhard Fröhlich http://www.bluelife.at/ From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 12 07:56:51 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE0C71065763 for ; Mon, 12 Mar 2012 07:56:51 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 803548FC0A for ; Mon, 12 Mar 2012 07:56:51 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q2C7umHi056158; Mon, 12 Mar 2012 00:56:49 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F5DAC40.4070707@rawbw.com> Date: Mon, 12 Mar 2012 00:56:48 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bernhard Froehlich References: <4F5D9666.5000209@rawbw.com> <19730368ac9f21f973e9b1de77feaa2d@bluelife.at> In-Reply-To: <19730368ac9f21f973e9b1de77feaa2d@bluelife.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@freebsd.org Subject: Re: Screen of Ubuntu64 guest doesn't update when 3D acceleration option is "on" X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 07:56:51 -0000 On 03/12/2012 00:47, Bernhard Froehlich wrote: > This doesn't sound like it's FreeBSD specific. Have you already searched > in their bug database for that? I couldn't find such problem report in their ticket system. Now, if I file such PR, they will likely say that FreeBSD isn't a supported host. Yuri From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 12 11:07:09 2012 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A3D106566C for ; Mon, 12 Mar 2012 11:07:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BE1028FC20 for ; Mon, 12 Mar 2012 11:07:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2CB79p7072302 for ; Mon, 12 Mar 2012 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2CB79Al072300 for freebsd-emulation@FreeBSD.org; Mon, 12 Mar 2012 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Mar 2012 11:07:09 GMT Message-Id: <201203121107.q2CB79Al072300@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 11:07:10 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/159646 emulation [linux] [patch] bump Linux version in linuxulator f kern/156691 emulation [vmware] [panic] panic when using hard disks as RAW de o kern/156353 emulation [ibcs2] ibcs2 binaries that execute on 4.x not working o kern/155577 emulation [boot] BTX halted after install. Reboot during install o kern/155040 emulation [linux] [patch] Linux recvfrom doesn't handle proto fa o kern/153990 emulation [hyper-v]: Will not install into Hyper-V on Server 200 o kern/153887 emulation [linux] Linux emulator not understand STB_GNU_UNIQUE b o kern/153243 emulation [ibcs2] Seg fault whne running COFF binary using iBCS2 o kern/151714 emulation [linux] print/acroread9 not usable due to lack of supp a bin/150262 emulation [patch] truss(1) -f doesn't follow descendants of the a kern/150186 emulation [parallels] [panic] Parallels Desktop: CDROM disconnec o ports/148097 emulation [patch] suggested addition to linux_base-* packages to o ports/148096 emulation emulators/linux_base-* can not be built from ports on o kern/147793 emulation [vmware] [panic] cdrom handling, panic, possible race o kern/146237 emulation [linux] Linux binaries not reading directories mounted p kern/144584 emulation [linprocfs][patch] bogus values in linprocfs o ports/142837 emulation [patch] emulators/linux_base-* packages fails to insta o kern/140156 emulation [linux] cdparanoia fails to read drive data f kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage s kern/133144 emulation [linux] linuxulator 2.6 crashes with nvidias libGL.so. o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/86619 emulation [linux] linux emulator interacts oddly with cp a kern/72920 emulation [linux] path "prefixing" is not done on unix domain so o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/36952 emulation [patch] [linux] ldd(1) command of linux does not work o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 30 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 12 15:54:10 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34E72106566C for ; Mon, 12 Mar 2012 15:54:10 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AF0658FC0A for ; Mon, 12 Mar 2012 15:54:09 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3816244bkc.13 for ; Mon, 12 Mar 2012 08:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=KuivNq4aUTBjGkcKzD0kLrbEZVuHmEBLFVyCMpQIgjk=; b=N/1ImQ3GraqnioNvt9ascD+Px41M/tXZUQboSupEJVYdxsYr8X1bIgVxNF+CXAQpzH 27z4Q8Yb9y3R50Zutzizf2dg1YVCCM3UzB66GedMPfU3IagTuBs9j1JuY39ITWofuZu/ PrH0s6LeYfx6dEIIEbzckkkw7Z0whTeBgsRZsXDadEFoxePFUSL+P1sg3KefU3t6qhVI sf62kQgI67iDWvUcuvWmHbCfn7GnzvdvEcWzK9e+I66d99+ytvIQdbEDnefK7bfnxiGd S80OCoVqo3m5oAvaNBJHW27s/o8onxxoU5xM//MbBxw8+7w5mvPFD44BcmEW9eubFn6R +DRQ== Received: by 10.204.154.202 with SMTP id p10mr4831575bkw.79.1331567648521; Mon, 12 Mar 2012 08:54:08 -0700 (PDT) Received: from green.tandem.local (251-132-201-46.pool.ukrtel.net. [46.201.132.251]) by mx.google.com with ESMTPS id jr13sm26219034bkb.14.2012.03.12.08.54.06 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 08:54:07 -0700 (PDT) Message-ID: <4F5E1C1D.2070204@gmail.com> Date: Mon, 12 Mar 2012 17:54:05 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120220 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: freebsd-emulation@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: emulators/virtualbox-ose fails to build after recent update (maybe devel/dev86 lockup) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:54:10 -0000 Maybe not directly related to recent update though... # uname -a FreeBSD limbo.lan 9.0-STABLE FreeBSD 9.0-STABLE #0 r232716: Fri Mar 9 22:38:03 EET 2012 arcade@limbo.lan:/usr/obj/usr/src/sys/MINIMALx32 i386 World and ports built with clang. When building port everything stop after: kBuild: Compiling PcBiosBin - /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.x86/release/obj/PcBiosBin/rombios1.s load: 2.91 cmd: as86 21213 [runnable] 17.18r 16.10u 0.02s 53% 2136k load: 3.86 cmd: as86 21213 [runnable] 143.14r 132.38u 0.09s 91% 8980k load: 3.86 cmd: as86 21213 [runnable] 143.37r 132.60u 0.09s 91% 8980k load: 3.86 cmd: as86 21213 [runnable] 143.55r 132.77u 0.09s 91% 8980k load: 3.86 cmd: as86 21213 [runnable] 143.72r 132.93u 0.09s 91% 8980k load: 3.86 cmd: as86 21213 [runnable] 143.89r 133.09u 0.09s 91% 8980k load: 3.86 cmd: as86 21213 [runnable] 144.05r 133.24u 0.09s 91% 8980k load: 3.87 cmd: as86 21213 [runnable] 144.17r 133.35u 0.09s 91% 8980k load: 3.87 cmd: as86 21213 [runnable] 144.29r 133.46u 0.09s 91% 8980k load: 3.96 cmd: as86 21213 [runnable] 227.38r 212.50u 0.14s 93% 8980k It can sit for hours. I rebuild devel/dev86 from scratch and replaced /usr/local/bin/as86 with unstripped version. Using gcore I catched some cores of running process: (gdb) bt full #0 build_number (num=1, width=3, where=0x80587a0 "") at genlist.c:122 No locals. #1 0x0804d20a in entermac (symptr=Variable "symptr" is not available. ) at macro.c:37 param1 = Unhandled dwarf expression opcode 0x0 Current language: auto; currently minimal (gdb) bt full #0 build_number (num=1, width=3, where=0x80587a0 "") at genlist.c:122 No locals. #1 0x0804d20a in entermac (symptr=Variable "symptr" is not available. ) at macro.c:37 param1 = Unhandled dwarf expression opcode 0x0 Current language: auto; currently minimal (gdb) bt full #0 build_number (num=1, width=3, where=0x80587a0 "") at genlist.c:122 No locals. #1 0x0804d20a in entermac (symptr=Variable "symptr" is not available. ) at macro.c:37 param1 = Unhandled dwarf expression opcode 0x0 Current language: auto; currently minimal diff states that captured cores differ. -- Sphinx of black quartz judge my vow. From owner-freebsd-emulation@FreeBSD.ORG Tue Mar 13 03:35:53 2012 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C221F106566C for ; Tue, 13 Mar 2012 03:35:53 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id AB27A8FC15 for ; Tue, 13 Mar 2012 03:35:53 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q2D3Zrxk047694 for ; Mon, 12 Mar 2012 20:35:53 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F5EC098.3000602@rawbw.com> Date: Mon, 12 Mar 2012 20:35:52 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-emulation@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: flashplugin11 goes around the proxy: is this considered a significant security vulnerability? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 03:35:53 -0000 I have set up the proxy server on FreeBSD, set it in chrome browser in Ubuntu, and went to the complex flash site playing video. In the middle of the run when htmls loaded but flash didn't yet start to play I killed the proxy. I expected that flash video will fail. But after a while it still plays video from the internet. Obviously, flash 11.1.102.63 ignores the proxy settings and connects directly. Even though ZDNet article http://www.zdnet.com/blog/security/adobe-plugs-dangerous-flash-player-security-holes/5104 claimed that this security vulnerability had been fixed in flash 10 in late 2009. FreeBSD uses very close flash 11 binary (11.1r102.62). So it must suffer from the same vulnerability. Yuri From owner-freebsd-emulation@FreeBSD.ORG Tue Mar 13 15:30:10 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BE391065675 for ; Tue, 13 Mar 2012 15:30:10 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D93A8FC18 for ; Tue, 13 Mar 2012 15:30:09 +0000 (UTC) Received: by eekd17 with SMTP id d17so397285eek.13 for ; Tue, 13 Mar 2012 08:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OLoCOcHDIqor53bFiWBx2fY7qkzB4NlO1rQnr0zJ5aU=; b=bfV2ruY2P6PHyev3CDJiK2G05qV+GDVdcxeilhddbt+jLkW6Nq8eJN4tX8kPM0eyoT 9j7yTYKQMJ9RxrF+nSv7E0PtW97lGrPozRglAQuRs3doJo844IxTNk3JfpN4ihzbZw/m vPBjq+6gkz3cfxccSxudpNY8jRm0zHtnAhG5T/lFX7Hi4tVWTyX0RTuEwetmVfltvaje SBdbRKeDvVrNn1c0n21TMjoET3gboOt3ZsP6+B4MYSQUGWgulNT60H7k5+0h9Glo6DBY oyQJyNgEdJkp5/DG2ZukoswvYJ2bQZ5uI9OpduA4eU7iJ2n3L4ILKnrS+l5cEbXMGszW Or3w== MIME-Version: 1.0 Received: by 10.68.223.230 with SMTP id qx6mr6557652pbc.29.1331652607433; Tue, 13 Mar 2012 08:30:07 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Tue, 13 Mar 2012 08:30:07 -0700 (PDT) In-Reply-To: <4F5F2CC5.80608@herveybayaustralia.com.au> References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> Date: Tue, 13 Mar 2012 11:30:07 -0400 Message-ID: From: Super Bisquit To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 15:30:10 -0000 ---------- Forwarded message ---------- From: Da Rock <9Phackers@herveybayaustralia.com.au> Date: Tue, Mar 13, 2012 at 7:17 AM Subject: Re: Kernel memory usage To: freebsd-hackers@freebsd.org On 03/13/12 05:40, Super Bisquit wrote: > CPU architecture and model have a lot to do with performance. > You will also get different results if you used qemu in place of > VirtualBox. Qemu allows you to choose different emulated > architectures, CPUs, and machine bases. What's the downside? You have > to use the command line. > Install qemu and run a series of virtual machines. > Embedded devices also include Power(PC), ARMv?, Coldfire, et al; > you're only dealing with i386 and/or the 64 bit extension (AMD64). > CISC- which does not contain any hardware modification to be a RISC > replacement- runs fewer instructions than RISC due to the limited > number of registers. Take this into consideration every time a > program runs. > Everything else also matters on real and emulated systems: > Is it ide, scsi, sdd, flashdevice for the hard drive? > What type of RAM? > Dedicated or shared disk? > I'm a little confused by the response, I was interested if someone knew what determines the size of kernel in memory (or wired); I only considered the embedded list because they have a greater interest in the memory size working with so little. It is academic as I'm trying to understand the kernel internals, as well as understand what works with low memory so I can tune accordingly. I understand the different CPU instruction sets (roughly), although I would be interested as to the size of the kernel in each. What my question was about was the wired memory size and what makes it grow (to put it super simply :) ). I know some growth would be expected, but this seems obese; how would I find out how much memory a process structure takes? Or else what am I missing? That said I'll have a crack at what you suggest as that follows a whole new interesting tangent :) I have used qemu before, but found VBox a bit more responsive (and, I will admit, easier...) > On 3/11/12, Da Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>> > wrote: > >> I may be required to move this to embedded, but I am only looking for >> generalisation. >> >> Recently a thread came up on questions regarding memory usage, and a >> post was made regarding wired memory being nearly all kernel- something >> I was ready to dispute, but then I thought I'd better make sure. >> >> So I tested a few theories first off: >> >> 1. Comparing memory usage across machines >> >> I checked servers and desktops as well as vm's for memory usage, and I >> found some interesting results. On a firewall with no apps installed >> only 35M wired is used, on a desktop up to 700M~ can be used. Even as a >> dedicated server with a few services used it remains around 35M. >> >> Surely this means that the wired memory used is not just kernel? But I >> held off my assumptions as it was still plausible that the structures >> used by the kernel could balloon that far, too. >> >> 2. Stripped down, lean mean, kernel machine >> >> I then (using a vm I was building a kernel for anyway) stripped down a >> kernel in a VBox VM using le drivers for network to see what could be >> achieved. This is my kernel conf: >> >> include GENERIC >> ident VPN >> options IPSEC >> options IPSEC_DEBUG >> options IPSEC_NAT_T >> device crypto >> device enc >> >> # minimise kernel >> nooptions UFS_GJOURNAL >> nooptions MD_ROOT >> nooptions NFSCL >> nooptions NFSD >> nooptions NFSLOCKD >> nooptions NFS_ROOT >> nooptions MSDOSFS >> nooptions CD9660 >> nooptions PROCFS >> nooptions PSEUDOFS >> nodevice fdc >> nodevice mvs >> nodevice siis >> nodevice ahc >> nodevice ahd >> nodevice esp >> nodevice hptiop >> nodevice isp >> nodevice mpt >> nodevice mps >> nodevice sym >> nodevice trm >> nodevice adv >> nodevice adw >> nodevice aic >> nodevice bt >> nodevice ses >> nodevice amr >> nodevice arcmsr >> nodevice ciss >> nodevice dpt >> nodevice hptmv >> nodevice hptrr >> nodevice irr >> nodevice ips >> nodevice mly >> nodevice twa >> nodevice aac >> nodevice aacp >> nodevice ida >> nodevice mfi >> nodevice mlx >> nodevice twe >> nodevice tws >> nodevice splash >> nodevice cbb >> nodevice pccard >> nodevice cardbus >> nodevice uart >> nodevice ppc >> nodevice ppbus >> nodevice lpt >> nodevice plip >> nodevice ppi >> nodevice puc >> nodevice bxe >> nodevice de >> nodevice em >> nodevice igb >> nodevice ixgbe >> nodevice ti >> nodevice txp >> nodevice vx >> nodevice miibus >> nodevice ae >> nodevice age >> nodevice alc >> nodevice ale >> nodevice bce >> nodevice bfe >> nodevice bge >> nodevice dc >> nodevice et >> nodevice fxp >> nodevice jme >> nodevice lge >> nodevice msk >> nodevice nfe >> nodevice nge >> nodevice pcn >> nodevice re >> nodevice rl >> nodevice sf >> nodevice sge >> nodevice sis >> nodevice sk >> nodevice ste >> nodevice stge >> nodevice tl >> nodevice tx >> nodevice vge >> nodevice vr >> nodevice wb >> nodevice xl >> nodevice cs >> nodevice ed >> nodevice ex >> nodevice ep >> nodevice fe >> nodevice sn >> nodevice xe >> nodevice wlan >> nooptions IEEE80211_DEBUG >> nooptions IEEE80211_AMPDU_AGE >> nooptions IEEE80211_SUPPORT_MESH >> nodevice wlan_wep >> nodevice wlan_ccmp >> nodevice wlan_tkip >> nodevice wlan_amrr >> nodevice an >> nodevice ath >> nodevice ath_pci >> nodevice ath_hal >> nooptions AH_SUPPORT_AR5416 >> nodevice ath_rate_sample >> nodevice ipw >> nodevice iwi >> nodevice iwn >> nodevice malo >> nodevice mwl >> nodevice ral >> nodevice wi >> nodevice wpi >> nodevice md >> nooption USB_DEBUG >> nodevice uhci >> nodevice ohci >> nodevice ehci >> nodevice xhci >> nodevice usb >> nodevice uhid >> nodevice ukbd >> nodevice ulpt >> nodevice umass >> nodevice ums >> nodevice urio >> nodevice u3g >> nodevice uark >> nodevice ubsa >> nodevice uftdi >> nodevice uipaq >> nodevice uplcom >> nodevice uslcom >> nodevice uvisor >> nodevice uvscom >> nodevice aue >> nodevice axe >> nodevice cdce >> nodevice cue >> nodevice kue >> nodevice rue >> nodevice udav >> nodevice rum >> nodevice run >> nodevice uath >> nodevice upgt >> nodevice ural >> nodevice urtw >> nodevice zyd >> #nodevice firewire >> nodevice fwe >> nodevice fwip >> #nodevice dcons >> #nodevice dcons_rom >> nodevice sound >> nodevice snd_es137x >> nodevice snd_hda >> nodevice snd_ich >> nodevice snd_uaudio >> nodevice snd_via8233 >> >> World was also rebuilt as recommended by the handbook. As you can see I >> was rebuilding for IPSEC (for testing purposes only note). I couldn't >> remove dcons (not sure why- missing defined references), and that pulled >> in firewire too. >> >> The result was surprising: a 14M kernel became 6.3M, and when running I >> found it only used 19M used for wired (whoopee!) as opposed to 35M. No >> services were running per se, only the usual suspects in base: >> >> vpn-test# ps ax >> PID TT STAT TIME COMMAND >> 0 ?? DLs 0:00.11 [kernel] >> 1 ?? ILs 0:00.01 /sbin/init -- >> 2 ?? DL 0:00.00 [crypto] >> 3 ?? DL 0:00.00 [crypto returns] >> 4 ?? DL 0:00.00 [sctp_iterator] >> 5 ?? DL 0:00.00 [xpt_thrd] >> 6 ?? DL 0:00.10 [pagedaemon] >> 7 ?? DL 0:00.00 [vmdaemon] >> 8 ?? DL 0:00.01 [pagezero] >> 9 ?? DL 0:00.30 [bufdaemon] >> 10 ?? DL 0:00.00 [audit] >> 11 ?? RL 589:34.00 [idle] >> 12 ?? WL 0:38.64 [intr] >> 13 ?? DL 0:12.21 [geom] >> 14 ?? DL 0:03.30 [yarrow] >> 15 ?? DL 0:04.40 [syncer] >> 16 ?? DL 0:00.63 [vnlru] >> 17 ?? DL 0:00.53 [softdepflush] >> 104 ?? Is 0:00.00 adjkerntz -i >> 582 ?? Is 0:00.00 /sbin/devd >> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >> /var/run/ntpd.pid >> 977 ?? Is 0:00.00 /usr/sbin/sshd >> 984 ?? Ss 0:00.81 sendmail: accepting connections (sendmail) >> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >> /var/spool/client >> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >> 1052 v0 Is 0:00.01 login [pam] (login) >> 1060 v0 I+ 0:00.02 -csh (csh) >> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >> 2065 0 Is 0:00.02 -csh (csh) >> 2068 0 I 0:00.01 su >> 2069 0 S 0:00.04 _su (csh) >> 2414 0 R+ 0:00.00 ps ax >> >> After some minutes though, the usage went up to 39M. WTF? >> >> So I'm now thoroughly confused. Google didn't really show up any real >> answers either. Aside from discovering the true nature of what was >> discussed in the posts, my hypothetical theorising is for my own >> academics as well; and I'm trying to slim down my kernels to see if I >> can improve performance with low memory systems. >> >> Can process structures cause this much ballooning? I find that hard to >> believe given not much is running here. My only other thought would be >> pipe or network structures? Anything I'm missing? >> >> FWIW, my trimmed down, slim and slender, aerodynamic kernel can boot in >> seconds as opposed to minutes. Sweet! Although compiling clang took >> years... and gcc was built as well :/ >> >> Cheers >> ______________________________**_________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >> freebsd.org " >> >> ______________________________**_________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** > freebsd.org " > ______________________________**_________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" I'm fowarding this thread in the event the individual, "da Rock" will be able to receive more help. From owner-freebsd-emulation@FreeBSD.ORG Tue Mar 13 15:33:02 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDEA0106564A for ; Tue, 13 Mar 2012 15:33:02 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id AE9338FC18 for ; Tue, 13 Mar 2012 15:33:02 +0000 (UTC) Received: by ggnk4 with SMTP id k4so850727ggn.13 for ; Tue, 13 Mar 2012 08:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NpFrjtAj8BcUdLhAw16LyZxqkA+HYyrNfK6mD5TMw8w=; b=XftygoO09ulllfuNrrWe7+IkgIUSBkRXs3Cn+ve67VJkx3Mrm1iTYn3BbLX7wW0qNX CbIMNMxHiAjb8UUTYi9aSNGPbMfpMy+gW3qB2vzTpgsTgiVlk7yNdTcnYy7RMwNXmdqp adeU3Ju7NPD3XToU3Adu9dWMXUVLzXlBhOt+Zo8G02wBEzeakaHkjFYbXbJ9byzA9Rf1 WRxoVikOwyl5/GR25GEWINDAy53OBaoFnl9s0iroF0+E7+ZjuINM/6d0dxw2Sn8zyr81 R3tCmlKWsDuBMccPX+puhWAjJVo23k8mUO6RS5xhQr6UIrwT4JEkUaXxRGXXUpyEhN2/ 5qcg== MIME-Version: 1.0 Received: by 10.68.218.130 with SMTP id pg2mr6544375pbc.155.1331652781860; Tue, 13 Mar 2012 08:33:01 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Tue, 13 Mar 2012 08:33:01 -0700 (PDT) Date: Tue, 13 Mar 2012 11:33:01 -0400 Message-ID: From: Super Bisquit To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Linuxlator on PowerPC X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 15:33:03 -0000 Has Linux emulation on PowerPC been tested? Also, if the required dependencies are downloaded, would the creation of a $PATH/Linux directory be sufficient for the executing of binaries? From owner-freebsd-emulation@FreeBSD.ORG Wed Mar 14 06:20:32 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B378106568D for ; Wed, 14 Mar 2012 06:20:32 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 029398FC08 for ; Wed, 14 Mar 2012 06:20:31 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so5356109wib.13 for ; Tue, 13 Mar 2012 23:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VX1q/xouFr03v7Sy6Xhlwf1fqmaOX1A4uEARORSDIdE=; b=xUzrdkLDjBrbPeg2AymDn23GCPvGDyH+IhT+MNH78iDeQ5QukazrHvbYzk5ko6+636 h4tJJ7VfQAfjjwKM4xhWnzYEnG8VOryWzEwHy4MRVn4LSBl86D+YyDNREp19ITF4ZeU5 uPKmpQldgExDtx0mWcFn0YkhbhLPoxBWNvCpKlinmnpbzKapFo6L3kEbZ0HfzlVo56vJ dMt+BTqpwDZrXwRxINqwVKO11UNK7Vmwacgygfwa/9hUYf+jLuI+lxSUtZYABr36TLOE rP7aae3icQ0aBPmnd8d+I23Ta9Ups0Dmb3BcgXneSQVrMkLHSk3Df5LoWr27av9L3vjs VZXQ== MIME-Version: 1.0 Received: by 10.180.8.164 with SMTP id s4mr3271855wia.6.1331706031002; Tue, 13 Mar 2012 23:20:31 -0700 (PDT) Received: by 10.180.102.6 with HTTP; Tue, 13 Mar 2012 23:20:30 -0700 (PDT) Date: Wed, 14 Mar 2012 02:20:30 -0400 Message-ID: From: grarpamp To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: VirtualBox missing from pkg FTP X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 06:20:32 -0000 Hey all. Just noting that VirtualBox has gone missing from the stable dirs other than packages-9-stable. There are still some various VBox components and versions present in the various -stable and -release FTP dirs. But in general, it seems something broke? Besides being outdated itself (3.2.12 vs. 4.1.10, or even 4.0.16 or 3.2.14)... I'm hesitant to use say the 8.2-release (3.2.12) since all my pkgs are 8-stable, and looking its release pkgdeps, it looks like it might bring in a lot of older packages from back then (libs and things)? From owner-freebsd-emulation@FreeBSD.ORG Wed Mar 14 09:36:12 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D97CD1065670 for ; Wed, 14 Mar 2012 09:36:11 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8097F8FC12 for ; Wed, 14 Mar 2012 09:36:11 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC423CA.dip.t-dialin.net [79.196.35.202]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 477CC844754; Wed, 14 Mar 2012 10:35:40 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 96C602397; Wed, 14 Mar 2012 10:35:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1331717737; bh=a66M5+S7hLahG74u7DYIpWUWLN407lU3r5ePZDaDEXU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=GUFj4oJ+3l8pfOXoitU88usiHVwr3z034kkMGoLOAv4EXJlipL9OODqet8YckNO0H Evnypmw7aAlPFJGZNrUFKfkWaQmRo8mo1Pg59spzA/bN9EYw2n36GRjLWn6fJeQlwe YSvY3tF3Lf5OGxxeFze52VRW6d9LOUHD4TAu2Akw1BXIasXkQJs3moOc10EbqU5WwX Ic5tFznoNX5p+0VKgiZhl2Ft4q1sPBt1OB4klTO0eyVW/KgpotVdA3IZ12w+SjftzA eQcm1tDirxRmUGPNE36lPiUHrIA6N7fLU1tYwQMsRrvCgBBxAfRneY7Oy/jBhc39Z5 emGX37VwaZZVw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q2E9Zbe1016743; Wed, 14 Mar 2012 10:35:37 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.20 ([85.94.224.20]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 14 Mar 2012 10:35:37 +0100 Date: Wed, 14 Mar 2012 10:35:37 +0100 Message-ID: <20120314103537.Horde.F0EGBpjmRSRPYGZpB4p0FhA@webmail.leidinger.net> From: Alexander Leidinger To: Super Bisquit References: In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 477CC844754.AEEC8 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.082, required 6, autolearn=disabled, AWL -1.42, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RCVD_IN_SORBS 1.00, RCVD_IN_SORBS_WEB 0.61, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1332322541.54323@3JbnKSltIyRGSRPNAg0VVg X-EBL-Spam-Status: No Cc: freebsd-emulation@freebsd.org Subject: Re: Linuxlator on PowerPC X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:36:12 -0000 Quoting Super Bisquit (from Tue, 13 Mar 2012 11:33:01 -0400): > Has Linux emulation on PowerPC been tested? > Also, if the required dependencies are downloaded, would the creation of a > $PATH/Linux directory be sufficient for the executing of binaries? I don't know about the kernel side on PowerPC (there was no discussion about this on emulation@, I've just seen some SVN commits regarding it, but I don't remember to have seen it going into HEAD), but the userland side should not be $PATH/Linux, it's /compat/linux (which normally should be a symlink to /usr/compat/linux). And it is not as easy as "downloading it", if you really talk about a linux_base like behavior. If you just want to give it a try (e.g. in a chroot), a copy of an existing linux system would be a good start. Bye, Alexander. -- Two can Live as Cheaply as One for Half as Long. -- Howard Kandel http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-emulation@FreeBSD.ORG Wed Mar 14 12:59:21 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6127D1065672; Wed, 14 Mar 2012 12:59:21 +0000 (UTC) (envelope-from sanpei@sanpei.org) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 29A028FC08; Wed, 14 Mar 2012 12:59:20 +0000 (UTC) Received: from cherry2.sanpei.org (j069113.ppp.asahi-net.or.jp [61.213.69.113]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id AFECE1364BB; Wed, 14 Mar 2012 21:59:11 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by cherry2.sanpei.org (8.14.4/8.14.3) with ESMTP id q2ECx8mj025541; Wed, 14 Mar 2012 21:59:09 +0900 (JST) (envelope-from sanpei@sanpei.org) Date: Wed, 14 Mar 2012 21:59:08 +0900 (JST) Message-Id: <20120314.215908.1291465837804728646.sanpei@sanpei.org> To: freebsd-emulation@freebsd.org, freebsd-net@freebsd.org From: MIHIRA Sanpei Yoshiro In-Reply-To: <20120304184529.GA57370@psconsult.nl> References: <20120304184529.GA57370@psconsult.nl> X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (cherry2.sanpei.org [127.0.0.1]); Wed, 14 Mar 2012 21:59:11 +0900 (JST) Cc: Subject: Re: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:59:21 -0000 Hi, I also have this problem. My environment is below - FreeBSD-8.2-RELEASE/amd64 and FreeBSD-10-current/i386 - Virtualbox 4.0.14(now I'm compiling new version 4.1.8) - WI-FI HOSTAP mode(if_bridge) I hope to use both function(VirtualBox and if_bridge) at same. Please let us to know the appropriate settings. >I just noticed that when running Virtualbox 4.1.8 with a bridged network >interface, I loose connectivity to another virtual host running in qemu >whose network interface is bridged to my ethernet interface. After >stopping the Virtualbox instance, I regain connection to the virtual >host under qemu. Ifconfig doesn't give a clue. Has anyone seen this >behaviour or, even better, have a solution? --- MIHIRA, Sanpei Yoshiro Tokyo, Japan. From owner-freebsd-emulation@FreeBSD.ORG Wed Mar 14 13:06:42 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E611065670; Wed, 14 Mar 2012 13:06:42 +0000 (UTC) (envelope-from flo@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E374B8FC1C; Wed, 14 Mar 2012 13:06:41 +0000 (UTC) Received: from bender.solomo.local (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2ED6dQq084673; Wed, 14 Mar 2012 13:06:40 GMT (envelope-from flo@freebsd.org) Message-ID: <4F6097DF.8000400@freebsd.org> Date: Wed, 14 Mar 2012 14:06:39 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2 MIME-Version: 1.0 To: MIHIRA Sanpei Yoshiro References: <20120304184529.GA57370@psconsult.nl> <20120314.215908.1291465837804728646.sanpei@sanpei.org> In-Reply-To: <20120314.215908.1291465837804728646.sanpei@sanpei.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:06:42 -0000 On 14.03.2012 13:59, MIHIRA Sanpei Yoshiro wrote: > Hi, > > I also have this problem. > My environment is below > - FreeBSD-8.2-RELEASE/amd64 and FreeBSD-10-current/i386 > - Virtualbox 4.0.14(now I'm compiling new version 4.1.8) > - WI-FI HOSTAP mode(if_bridge) > > I hope to use both function(VirtualBox and if_bridge) at same. > Please let us to know the appropriate settings. > >> I just noticed that when running Virtualbox 4.1.8 with a bridged network >> interface, I loose connectivity to another virtual host running in qemu >> whose network interface is bridged to my ethernet interface. After >> stopping the Virtualbox instance, I regain connection to the virtual >> host under qemu. Ifconfig doesn't give a clue. Has anyone seen this >> behaviour or, even better, have a solution? > What i did was create another tap interface add that to the bridge and configure VirtualBox to use the tap interface. Seems to work for me. HTH, Florian From owner-freebsd-emulation@FreeBSD.ORG Wed Mar 14 15:57:12 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2868F106566C for ; Wed, 14 Mar 2012 15:57:12 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id B387D8FC0C for ; Wed, 14 Mar 2012 15:57:11 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 28643D; Wed, 14 Mar 2012 16:57:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 14 Mar 2012 16:57:03 +0100 From: Bernhard Froehlich To: grarpamp In-Reply-To: References: Message-ID: <97c592043bf97ec52552d9ea20669b7d@bluelife.at> X-Sender: decke@bluelife.at User-Agent: Roundcube Webmail/0.7.1 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0208.4F60BFCF.018C,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: freebsd-emulation@freebsd.org Subject: Re: VirtualBox missing from pkg FTP X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:57:12 -0000 On 14.03.2012 07:20, grarpamp wrote: > Hey all. Just noting that VirtualBox has gone > missing from the stable dirs other than > packages-9-stable. There are still some various > VBox components and versions present in the > various -stable and -release FTP dirs. But in > general, it seems something broke? > > Besides being outdated itself (3.2.12 vs. 4.1.10, or > even 4.0.16 or 3.2.14)... > I'm hesitant to use say the 8.2-release (3.2.12) since > all my pkgs are 8-stable, and looking its release > pkgdeps, it looks like it might bring in a lot of older > packages from back then (libs and things)? I honestly don't know what you are complaining about. Is it that 4.1.10 was released less than 24h ago and the ports are not updated yet? Sorry for that, I was traveling yesterday so I was unable to have a look at it yet. Is it because 4.1.8 packages for 8-stable are not available? ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/emulators/ ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/emulators/ Is it because the packages are not identical to the current ports? The binary packages are currently generated on a low frequency so it will take a few weeks until they are updated. -- Bernhard Fröhlich http://www.bluelife.at/ From owner-freebsd-emulation@FreeBSD.ORG Wed Mar 14 20:35:57 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67A271065670 for ; Wed, 14 Mar 2012 20:35:57 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id F3D528FC14 for ; Wed, 14 Mar 2012 20:35:56 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so2655862wib.13 for ; Wed, 14 Mar 2012 13:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6/XWJn3vdmxhZB68S2TIQ8nsvzcLfhcD+6Q0PsFtpR4=; b=dOGTUNpR8IppEGWiIzqo4MGG2XisLSZnY3Hq6Q+uFQQSp7DZVS9E59xWrY7MyKUX5E r73A1ADBvWv3Ar34q0qIBnjp5OlqftR6zS06HZqDWANWVd2k9v7Qu9sCeBGPUv4zoSU3 A0iFx1pqs0F9t/s7gBualCMXzgIMkzeNyedMi9+0jv3MUcRvPEqIr7G/VbeV1T9DmpVi Tv7Tf7DI/nAUiE9ISqSLzX9aQBY5o+K5zB/OFPANsKQgaaZr9ZrHvuDUTA8dQv8OdPAV wMklj0SuCgTpTTQMJHo4TkklDPJiLn1mHMQ/Q++SmIjmfO7aUV3oHyO7ioDPKlVfxyq8 MibQ== MIME-Version: 1.0 Received: by 10.216.133.234 with SMTP id q84mr2388715wei.102.1331757355947; Wed, 14 Mar 2012 13:35:55 -0700 (PDT) Received: by 10.180.102.6 with HTTP; Wed, 14 Mar 2012 13:35:55 -0700 (PDT) In-Reply-To: <97c592043bf97ec52552d9ea20669b7d@bluelife.at> References: <97c592043bf97ec52552d9ea20669b7d@bluelife.at> Date: Wed, 14 Mar 2012 16:35:55 -0400 Message-ID: From: grarpamp To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: VirtualBox missing from pkg FTP X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:35:57 -0000 > Is it that 4.1.10 was released less than 24h ago and the ports > are not updated yet? Not at all, just an inventory. Lag time on new releases is totally understandable. They need ported and tested. And life is first priority :) > Is it because 4.1.8 packages for 8-stable are not available? Using the packages-major-stable example for 8 and 9, we have this FTP index. Notably, RELENG_8 i386 is missing the base 'virtualbox-ose' package. I think it used to be there last month. 8sa: 69174652 Mar 08 02:43 virtualbox-ose-4.1.8.tbz 8sa: 1039991 Mar 08 22:58 virtualbox-ose-additions-4.1.8.tbz 8sa: 110285 Mar 07 22:13 virtualbox-ose-kmod-4.1.8_1.tbz 8sa: 107500 Mar 08 02:12 virtualbox-ose-kmod-legacy-4.0.16.tbz 8si: 953365 Feb 29 14:33 virtualbox-ose-additions-4.1.8.tbz 8si: 109301 Feb 28 20:41 virtualbox-ose-kmod-4.1.8_1.tbz 8si: 106336 Feb 29 01:05 virtualbox-ose-kmod-legacy-4.0.16.tbz 9sa: 69315786 Mar 05 22:56 virtualbox-ose-4.1.8.tbz 9sa: 1062649 Mar 06 09:15 virtualbox-ose-additions-4.1.8.tbz 9sa: 110743 Mar 05 17:46 virtualbox-ose-kmod-4.1.8_1.tbz 9sa: 108026 Mar 05 22:33 virtualbox-ose-kmod-legacy-4.0.16.tbz 9si: 64462589 Feb 08 10:42 virtualbox-ose-4.0.14.tbz 9si: 1052081 Feb 09 06:06 virtualbox-ose-additions-4.0.14.tbz 9si: 106199 Jan 30 18:51 virtualbox-ose-kmod-4.0.14.tbz 9si: 96474 Jan 30 20:32 virtualbox-ose-kmod-legacy-3.2.12_3.tbz 9si: 53094010 Feb 09 07:13 virtualbox-ose-legacy-3.2.12_3.tbz > Is it because the packages are not identical to the current ports? The svn port -> FTP building process is presumed to have some delay. Likely because, even though parallelism might yield a complete build of all ports in a few days, it is surely and rightly checkpointed by humans to prevent automated mayhem :) From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 15 02:59:56 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF01D1065670 for ; Thu, 15 Mar 2012 02:59:56 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (unknown [IPv6:2607:fa80:40::6]) by mx1.freebsd.org (Postfix) with ESMTP id A88A18FC12 for ; Thu, 15 Mar 2012 02:59:56 +0000 (UTC) Received: from [192.168.1.10] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) (authenticated bits=0) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id q2F2xjAt005821 for ; Wed, 14 Mar 2012 19:59:52 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4F615B0B.3060902@mittelstaedt.us> Date: Wed, 14 Mar 2012 19:59:23 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0) Gecko/20110929 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Subject: Re: VirtualBox missing from pkg FTP X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 02:59:57 -0000 On 3/13/2012 11:20 PM, grarpamp wrote: > Hey all. Just noting that VirtualBox has gone > missing from the stable dirs other than > packages-9-stable. There are still some various > VBox components and versions present in the > various -stable and -release FTP dirs. But in > general, it seems something broke? > > Besides being outdated itself (3.2.12 vs. 4.1.10, or > even 4.0.16 or 3.2.14)... > I'm hesitant to use say the 8.2-release (3.2.12) since > all my pkgs are 8-stable, and looking its release > pkgdeps, it looks like it might bring in a lot of older > packages from back then (libs and things)? What I have learned with FreeBSD is when building a new server based on RELEASE, to build it, then do a cvsup on the ports directory, then build all ports. From that point on don't add more ports until your ready to do a make world and update everything. (and many times I just build a new server on new hardware when I hit that point) If you try to use the ports directories from the RELEASE iso's without doing a cvsup on the ports directories you will run into much grief. Ted From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 15 03:08:23 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2296B106566B for ; Thu, 15 Mar 2012 03:08:23 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (unknown [IPv6:2607:fa80:40::6]) by mx1.freebsd.org (Postfix) with ESMTP id 97B308FC15 for ; Thu, 15 Mar 2012 03:08:22 +0000 (UTC) Received: from [192.168.1.10] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) (authenticated bits=0) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id q2F38Fgh005869; Wed, 14 Mar 2012 20:08:16 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4F615D09.8030009@mittelstaedt.us> Date: Wed, 14 Mar 2012 20:07:53 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0) Gecko/20110929 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Cc: Subject: Re: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 03:08:23 -0000 What do you regard as a "low memory" machine? Ted On 3/13/2012 8:30 AM, Super Bisquit wrote: > ---------- Forwarded message ---------- > From: Da Rock<9Phackers@herveybayaustralia.com.au> > Date: Tue, Mar 13, 2012 at 7:17 AM > Subject: Re: Kernel memory usage > To: freebsd-hackers@freebsd.org > > > On 03/13/12 05:40, Super Bisquit wrote: > >> CPU architecture and model have a lot to do with performance. >> You will also get different results if you used qemu in place of >> VirtualBox. Qemu allows you to choose different emulated >> architectures, CPUs, and machine bases. What's the downside? You have >> to use the command line. >> Install qemu and run a series of virtual machines. >> Embedded devices also include Power(PC), ARMv?, Coldfire, et al; >> you're only dealing with i386 and/or the 64 bit extension (AMD64). >> CISC- which does not contain any hardware modification to be a RISC >> replacement- runs fewer instructions than RISC due to the limited >> number of registers. Take this into consideration every time a >> program runs. >> Everything else also matters on real and emulated systems: >> Is it ide, scsi, sdd, flashdevice for the hard drive? >> What type of RAM? >> Dedicated or shared disk? >> > I'm a little confused by the response, I was interested if someone knew > what determines the size of kernel in memory (or wired); I only considered > the embedded list because they have a greater interest in the memory size > working with so little. > > It is academic as I'm trying to understand the kernel internals, as well as > understand what works with low memory so I can tune accordingly. I > understand the different CPU instruction sets (roughly), although I would > be interested as to the size of the kernel in each. > > What my question was about was the wired memory size and what makes it grow > (to put it super simply :) ). I know some growth would be expected, but > this seems obese; how would I find out how much memory a process structure > takes? Or else what am I missing? > > That said I'll have a crack at what you suggest as that follows a whole new > interesting tangent :) I have used qemu before, but found VBox a bit more > responsive (and, I will admit, easier...) > > >> On 3/11/12, Da Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>> >> wrote: >> >>> I may be required to move this to embedded, but I am only looking for >>> generalisation. >>> >>> Recently a thread came up on questions regarding memory usage, and a >>> post was made regarding wired memory being nearly all kernel- something >>> I was ready to dispute, but then I thought I'd better make sure. >>> >>> So I tested a few theories first off: >>> >>> 1. Comparing memory usage across machines >>> >>> I checked servers and desktops as well as vm's for memory usage, and I >>> found some interesting results. On a firewall with no apps installed >>> only 35M wired is used, on a desktop up to 700M~ can be used. Even as a >>> dedicated server with a few services used it remains around 35M. >>> >>> Surely this means that the wired memory used is not just kernel? But I >>> held off my assumptions as it was still plausible that the structures >>> used by the kernel could balloon that far, too. >>> >>> 2. Stripped down, lean mean, kernel machine >>> >>> I then (using a vm I was building a kernel for anyway) stripped down a >>> kernel in a VBox VM using le drivers for network to see what could be >>> achieved. This is my kernel conf: >>> >>> include GENERIC >>> ident VPN >>> options IPSEC >>> options IPSEC_DEBUG >>> options IPSEC_NAT_T >>> device crypto >>> device enc >>> >>> # minimise kernel >>> nooptions UFS_GJOURNAL >>> nooptions MD_ROOT >>> nooptions NFSCL >>> nooptions NFSD >>> nooptions NFSLOCKD >>> nooptions NFS_ROOT >>> nooptions MSDOSFS >>> nooptions CD9660 >>> nooptions PROCFS >>> nooptions PSEUDOFS >>> nodevice fdc >>> nodevice mvs >>> nodevice siis >>> nodevice ahc >>> nodevice ahd >>> nodevice esp >>> nodevice hptiop >>> nodevice isp >>> nodevice mpt >>> nodevice mps >>> nodevice sym >>> nodevice trm >>> nodevice adv >>> nodevice adw >>> nodevice aic >>> nodevice bt >>> nodevice ses >>> nodevice amr >>> nodevice arcmsr >>> nodevice ciss >>> nodevice dpt >>> nodevice hptmv >>> nodevice hptrr >>> nodevice irr >>> nodevice ips >>> nodevice mly >>> nodevice twa >>> nodevice aac >>> nodevice aacp >>> nodevice ida >>> nodevice mfi >>> nodevice mlx >>> nodevice twe >>> nodevice tws >>> nodevice splash >>> nodevice cbb >>> nodevice pccard >>> nodevice cardbus >>> nodevice uart >>> nodevice ppc >>> nodevice ppbus >>> nodevice lpt >>> nodevice plip >>> nodevice ppi >>> nodevice puc >>> nodevice bxe >>> nodevice de >>> nodevice em >>> nodevice igb >>> nodevice ixgbe >>> nodevice ti >>> nodevice txp >>> nodevice vx >>> nodevice miibus >>> nodevice ae >>> nodevice age >>> nodevice alc >>> nodevice ale >>> nodevice bce >>> nodevice bfe >>> nodevice bge >>> nodevice dc >>> nodevice et >>> nodevice fxp >>> nodevice jme >>> nodevice lge >>> nodevice msk >>> nodevice nfe >>> nodevice nge >>> nodevice pcn >>> nodevice re >>> nodevice rl >>> nodevice sf >>> nodevice sge >>> nodevice sis >>> nodevice sk >>> nodevice ste >>> nodevice stge >>> nodevice tl >>> nodevice tx >>> nodevice vge >>> nodevice vr >>> nodevice wb >>> nodevice xl >>> nodevice cs >>> nodevice ed >>> nodevice ex >>> nodevice ep >>> nodevice fe >>> nodevice sn >>> nodevice xe >>> nodevice wlan >>> nooptions IEEE80211_DEBUG >>> nooptions IEEE80211_AMPDU_AGE >>> nooptions IEEE80211_SUPPORT_MESH >>> nodevice wlan_wep >>> nodevice wlan_ccmp >>> nodevice wlan_tkip >>> nodevice wlan_amrr >>> nodevice an >>> nodevice ath >>> nodevice ath_pci >>> nodevice ath_hal >>> nooptions AH_SUPPORT_AR5416 >>> nodevice ath_rate_sample >>> nodevice ipw >>> nodevice iwi >>> nodevice iwn >>> nodevice malo >>> nodevice mwl >>> nodevice ral >>> nodevice wi >>> nodevice wpi >>> nodevice md >>> nooption USB_DEBUG >>> nodevice uhci >>> nodevice ohci >>> nodevice ehci >>> nodevice xhci >>> nodevice usb >>> nodevice uhid >>> nodevice ukbd >>> nodevice ulpt >>> nodevice umass >>> nodevice ums >>> nodevice urio >>> nodevice u3g >>> nodevice uark >>> nodevice ubsa >>> nodevice uftdi >>> nodevice uipaq >>> nodevice uplcom >>> nodevice uslcom >>> nodevice uvisor >>> nodevice uvscom >>> nodevice aue >>> nodevice axe >>> nodevice cdce >>> nodevice cue >>> nodevice kue >>> nodevice rue >>> nodevice udav >>> nodevice rum >>> nodevice run >>> nodevice uath >>> nodevice upgt >>> nodevice ural >>> nodevice urtw >>> nodevice zyd >>> #nodevice firewire >>> nodevice fwe >>> nodevice fwip >>> #nodevice dcons >>> #nodevice dcons_rom >>> nodevice sound >>> nodevice snd_es137x >>> nodevice snd_hda >>> nodevice snd_ich >>> nodevice snd_uaudio >>> nodevice snd_via8233 >>> >>> World was also rebuilt as recommended by the handbook. As you can see I >>> was rebuilding for IPSEC (for testing purposes only note). I couldn't >>> remove dcons (not sure why- missing defined references), and that pulled >>> in firewire too. >>> >>> The result was surprising: a 14M kernel became 6.3M, and when running I >>> found it only used 19M used for wired (whoopee!) as opposed to 35M. No >>> services were running per se, only the usual suspects in base: >>> >>> vpn-test# ps ax >>> PID TT STAT TIME COMMAND >>> 0 ?? DLs 0:00.11 [kernel] >>> 1 ?? ILs 0:00.01 /sbin/init -- >>> 2 ?? DL 0:00.00 [crypto] >>> 3 ?? DL 0:00.00 [crypto returns] >>> 4 ?? DL 0:00.00 [sctp_iterator] >>> 5 ?? DL 0:00.00 [xpt_thrd] >>> 6 ?? DL 0:00.10 [pagedaemon] >>> 7 ?? DL 0:00.00 [vmdaemon] >>> 8 ?? DL 0:00.01 [pagezero] >>> 9 ?? DL 0:00.30 [bufdaemon] >>> 10 ?? DL 0:00.00 [audit] >>> 11 ?? RL 589:34.00 [idle] >>> 12 ?? WL 0:38.64 [intr] >>> 13 ?? DL 0:12.21 [geom] >>> 14 ?? DL 0:03.30 [yarrow] >>> 15 ?? DL 0:04.40 [syncer] >>> 16 ?? DL 0:00.63 [vnlru] >>> 17 ?? DL 0:00.53 [softdepflush] >>> 104 ?? Is 0:00.00 adjkerntz -i >>> 582 ?? Is 0:00.00 /sbin/devd >>> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >>> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >>> /var/run/ntpd.pid >>> 977 ?? Is 0:00.00 /usr/sbin/sshd >>> 984 ?? Ss 0:00.81 sendmail: accepting connections (sendmail) >>> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >>> /var/spool/client >>> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >>> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >>> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >>> 1052 v0 Is 0:00.01 login [pam] (login) >>> 1060 v0 I+ 0:00.02 -csh (csh) >>> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >>> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >>> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >>> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >>> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >>> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >>> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >>> 2065 0 Is 0:00.02 -csh (csh) >>> 2068 0 I 0:00.01 su >>> 2069 0 S 0:00.04 _su (csh) >>> 2414 0 R+ 0:00.00 ps ax >>> >>> After some minutes though, the usage went up to 39M. WTF? >>> >>> So I'm now thoroughly confused. Google didn't really show up any real >>> answers either. Aside from discovering the true nature of what was >>> discussed in the posts, my hypothetical theorising is for my own >>> academics as well; and I'm trying to slim down my kernels to see if I >>> can improve performance with low memory systems. >>> >>> Can process structures cause this much ballooning? I find that hard to >>> believe given not much is running here. My only other thought would be >>> pipe or network structures? Anything I'm missing? >>> >>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can boot in >>> seconds as opposed to minutes. Sweet! Although compiling clang took >>> years... and gcc was built as well :/ >>> >>> Cheers >>> ______________________________**_________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>> freebsd.org" >>> >>> ______________________________**_________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >> freebsd.org" >> > > ______________________________**_________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > I'm fowarding this thread in the event the individual, "da Rock" will be > able to receive more help. > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org" > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: 03/14/12 From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 15 04:03:54 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C75E106564A for ; Thu, 15 Mar 2012 04:03:54 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD1DC8FC15 for ; Thu, 15 Mar 2012 04:03:53 +0000 (UTC) Received: by yenl9 with SMTP id l9so3172956yen.13 for ; Wed, 14 Mar 2012 21:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yCAj/gGxmh64KRCs3N0fSa9E+RtKVGR0CnNb5rfoV/M=; b=N+7F5sdQ7ng1nwmm2RHIBn6F2fa+uATrCbGLFjq1BoNLcsHF1eQmcbDMu+298fIRs/ m48cEUIZUQpP7hFdBcNw4T0Tqzh17TLVx+pT+sx0LAvlxdshRrv/uXiuucGTdTObWnV7 XTipZhkLlfnekIBlwxtSLELjpoZtce0SuiBgI3JKGjm9Z3Lay7ZmGd1otV5A6VlBJHkT cFXYOQD7xJxiuPFvMVg5pqnFY781CZvsoDz8obuTOpa3N3C2HoXF8z55HuDjsRLeb7uP nYvGvgzhRvjt85Q0Vd4PgvB1TpG/omsh1Aq8MJf4hdkL3JaYwQp+oxjafuc4TXSy/xHN rQqw== MIME-Version: 1.0 Received: by 10.68.132.41 with SMTP id or9mr1680414pbb.8.1331784232768; Wed, 14 Mar 2012 21:03:52 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Wed, 14 Mar 2012 21:03:52 -0700 (PDT) In-Reply-To: <4F615D09.8030009@mittelstaedt.us> References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> <4F615D09.8030009@mittelstaedt.us> Date: Thu, 15 Mar 2012 00:03:52 -0400 Message-ID: From: Super Bisquit To: Ted Mittelstaedt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-emulation@freebsd.org Subject: Re: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 04:03:54 -0000 On 3/14/12, Ted Mittelstaedt wrote: > What do you regard as a "low memory" machine? On real hardware I've used: HTC Apache 64/128 ROM/RAM Embedded 486 with 5M RAM Older tower maxed at 128M I'd say anything less than 64M RAM for normal hardware, less than 32 for embedded. Some systems do not have small memory modules. I have two SunBlade 1000s that can be stripped down to 128M. I'm also aware that the environment limits what the machine can have installed. There are older systems and embedded devices which run/ran on 16kb of RAM. I'm certain that the oldest electronic led calculators used even less memory. I digress. > > Ted > > On 3/13/2012 8:30 AM, Super Bisquit wrote: >> ---------- Forwarded message ---------- >> From: Da Rock<9Phackers@herveybayaustralia.com.au> >> Date: Tue, Mar 13, 2012 at 7:17 AM >> Subject: Re: Kernel memory usage >> To: freebsd-hackers@freebsd.org >> >> >> On 03/13/12 05:40, Super Bisquit wrote: >> >>> CPU architecture and model have a lot to do with performance. >>> You will also get different results if you used qemu in place of >>> VirtualBox. Qemu allows you to choose different emulated >>> architectures, CPUs, and machine bases. What's the downside? You have >>> to use the command line. >>> Install qemu and run a series of virtual machines. >>> Embedded devices also include Power(PC), ARMv?, Coldfire, et al; >>> you're only dealing with i386 and/or the 64 bit extension (AMD64). >>> CISC- which does not contain any hardware modification to be a RISC >>> replacement- runs fewer instructions than RISC due to the limited >>> number of registers. Take this into consideration every time a >>> program runs. >>> Everything else also matters on real and emulated systems: >>> Is it ide, scsi, sdd, flashdevice for the hard drive? >>> What type of RAM? >>> Dedicated or shared disk? >>> >> I'm a little confused by the response, I was interested if someone knew >> what determines the size of kernel in memory (or wired); I only considered >> the embedded list because they have a greater interest in the memory size >> working with so little. >> >> It is academic as I'm trying to understand the kernel internals, as well >> as >> understand what works with low memory so I can tune accordingly. I >> understand the different CPU instruction sets (roughly), although I would >> be interested as to the size of the kernel in each. >> >> What my question was about was the wired memory size and what makes it >> grow >> (to put it super simply :) ). I know some growth would be expected, but >> this seems obese; how would I find out how much memory a process structure >> takes? Or else what am I missing? >> >> That said I'll have a crack at what you suggest as that follows a whole >> new >> interesting tangent :) I have used qemu before, but found VBox a bit more >> responsive (and, I will admit, easier...) >> >> >>> On 3/11/12, Da >>> Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>> >>> wrote: >>> >>>> I may be required to move this to embedded, but I am only looking for >>>> generalisation. >>>> >>>> Recently a thread came up on questions regarding memory usage, and a >>>> post was made regarding wired memory being nearly all kernel- something >>>> I was ready to dispute, but then I thought I'd better make sure. >>>> >>>> So I tested a few theories first off: >>>> >>>> 1. Comparing memory usage across machines >>>> >>>> I checked servers and desktops as well as vm's for memory usage, and I >>>> found some interesting results. On a firewall with no apps installed >>>> only 35M wired is used, on a desktop up to 700M~ can be used. Even as a >>>> dedicated server with a few services used it remains around 35M. >>>> >>>> Surely this means that the wired memory used is not just kernel? But I >>>> held off my assumptions as it was still plausible that the structures >>>> used by the kernel could balloon that far, too. >>>> >>>> 2. Stripped down, lean mean, kernel machine >>>> >>>> I then (using a vm I was building a kernel for anyway) stripped down a >>>> kernel in a VBox VM using le drivers for network to see what could be >>>> achieved. This is my kernel conf: >>>> >>>> include GENERIC >>>> ident VPN >>>> options IPSEC >>>> options IPSEC_DEBUG >>>> options IPSEC_NAT_T >>>> device crypto >>>> device enc >>>> >>>> # minimise kernel >>>> nooptions UFS_GJOURNAL >>>> nooptions MD_ROOT >>>> nooptions NFSCL >>>> nooptions NFSD >>>> nooptions NFSLOCKD >>>> nooptions NFS_ROOT >>>> nooptions MSDOSFS >>>> nooptions CD9660 >>>> nooptions PROCFS >>>> nooptions PSEUDOFS >>>> nodevice fdc >>>> nodevice mvs >>>> nodevice siis >>>> nodevice ahc >>>> nodevice ahd >>>> nodevice esp >>>> nodevice hptiop >>>> nodevice isp >>>> nodevice mpt >>>> nodevice mps >>>> nodevice sym >>>> nodevice trm >>>> nodevice adv >>>> nodevice adw >>>> nodevice aic >>>> nodevice bt >>>> nodevice ses >>>> nodevice amr >>>> nodevice arcmsr >>>> nodevice ciss >>>> nodevice dpt >>>> nodevice hptmv >>>> nodevice hptrr >>>> nodevice irr >>>> nodevice ips >>>> nodevice mly >>>> nodevice twa >>>> nodevice aac >>>> nodevice aacp >>>> nodevice ida >>>> nodevice mfi >>>> nodevice mlx >>>> nodevice twe >>>> nodevice tws >>>> nodevice splash >>>> nodevice cbb >>>> nodevice pccard >>>> nodevice cardbus >>>> nodevice uart >>>> nodevice ppc >>>> nodevice ppbus >>>> nodevice lpt >>>> nodevice plip >>>> nodevice ppi >>>> nodevice puc >>>> nodevice bxe >>>> nodevice de >>>> nodevice em >>>> nodevice igb >>>> nodevice ixgbe >>>> nodevice ti >>>> nodevice txp >>>> nodevice vx >>>> nodevice miibus >>>> nodevice ae >>>> nodevice age >>>> nodevice alc >>>> nodevice ale >>>> nodevice bce >>>> nodevice bfe >>>> nodevice bge >>>> nodevice dc >>>> nodevice et >>>> nodevice fxp >>>> nodevice jme >>>> nodevice lge >>>> nodevice msk >>>> nodevice nfe >>>> nodevice nge >>>> nodevice pcn >>>> nodevice re >>>> nodevice rl >>>> nodevice sf >>>> nodevice sge >>>> nodevice sis >>>> nodevice sk >>>> nodevice ste >>>> nodevice stge >>>> nodevice tl >>>> nodevice tx >>>> nodevice vge >>>> nodevice vr >>>> nodevice wb >>>> nodevice xl >>>> nodevice cs >>>> nodevice ed >>>> nodevice ex >>>> nodevice ep >>>> nodevice fe >>>> nodevice sn >>>> nodevice xe >>>> nodevice wlan >>>> nooptions IEEE80211_DEBUG >>>> nooptions IEEE80211_AMPDU_AGE >>>> nooptions IEEE80211_SUPPORT_MESH >>>> nodevice wlan_wep >>>> nodevice wlan_ccmp >>>> nodevice wlan_tkip >>>> nodevice wlan_amrr >>>> nodevice an >>>> nodevice ath >>>> nodevice ath_pci >>>> nodevice ath_hal >>>> nooptions AH_SUPPORT_AR5416 >>>> nodevice ath_rate_sample >>>> nodevice ipw >>>> nodevice iwi >>>> nodevice iwn >>>> nodevice malo >>>> nodevice mwl >>>> nodevice ral >>>> nodevice wi >>>> nodevice wpi >>>> nodevice md >>>> nooption USB_DEBUG >>>> nodevice uhci >>>> nodevice ohci >>>> nodevice ehci >>>> nodevice xhci >>>> nodevice usb >>>> nodevice uhid >>>> nodevice ukbd >>>> nodevice ulpt >>>> nodevice umass >>>> nodevice ums >>>> nodevice urio >>>> nodevice u3g >>>> nodevice uark >>>> nodevice ubsa >>>> nodevice uftdi >>>> nodevice uipaq >>>> nodevice uplcom >>>> nodevice uslcom >>>> nodevice uvisor >>>> nodevice uvscom >>>> nodevice aue >>>> nodevice axe >>>> nodevice cdce >>>> nodevice cue >>>> nodevice kue >>>> nodevice rue >>>> nodevice udav >>>> nodevice rum >>>> nodevice run >>>> nodevice uath >>>> nodevice upgt >>>> nodevice ural >>>> nodevice urtw >>>> nodevice zyd >>>> #nodevice firewire >>>> nodevice fwe >>>> nodevice fwip >>>> #nodevice dcons >>>> #nodevice dcons_rom >>>> nodevice sound >>>> nodevice snd_es137x >>>> nodevice snd_hda >>>> nodevice snd_ich >>>> nodevice snd_uaudio >>>> nodevice snd_via8233 >>>> >>>> World was also rebuilt as recommended by the handbook. As you can see I >>>> was rebuilding for IPSEC (for testing purposes only note). I couldn't >>>> remove dcons (not sure why- missing defined references), and that pulled >>>> in firewire too. >>>> >>>> The result was surprising: a 14M kernel became 6.3M, and when running I >>>> found it only used 19M used for wired (whoopee!) as opposed to 35M. No >>>> services were running per se, only the usual suspects in base: >>>> >>>> vpn-test# ps ax >>>> PID TT STAT TIME COMMAND >>>> 0 ?? DLs 0:00.11 [kernel] >>>> 1 ?? ILs 0:00.01 /sbin/init -- >>>> 2 ?? DL 0:00.00 [crypto] >>>> 3 ?? DL 0:00.00 [crypto returns] >>>> 4 ?? DL 0:00.00 [sctp_iterator] >>>> 5 ?? DL 0:00.00 [xpt_thrd] >>>> 6 ?? DL 0:00.10 [pagedaemon] >>>> 7 ?? DL 0:00.00 [vmdaemon] >>>> 8 ?? DL 0:00.01 [pagezero] >>>> 9 ?? DL 0:00.30 [bufdaemon] >>>> 10 ?? DL 0:00.00 [audit] >>>> 11 ?? RL 589:34.00 [idle] >>>> 12 ?? WL 0:38.64 [intr] >>>> 13 ?? DL 0:12.21 [geom] >>>> 14 ?? DL 0:03.30 [yarrow] >>>> 15 ?? DL 0:04.40 [syncer] >>>> 16 ?? DL 0:00.63 [vnlru] >>>> 17 ?? DL 0:00.53 [softdepflush] >>>> 104 ?? Is 0:00.00 adjkerntz -i >>>> 582 ?? Is 0:00.00 /sbin/devd >>>> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >>>> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >>>> /var/run/ntpd.pid >>>> 977 ?? Is 0:00.00 /usr/sbin/sshd >>>> 984 ?? Ss 0:00.81 sendmail: accepting connections (sendmail) >>>> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >>>> /var/spool/client >>>> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >>>> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >>>> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >>>> 1052 v0 Is 0:00.01 login [pam] (login) >>>> 1060 v0 I+ 0:00.02 -csh (csh) >>>> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >>>> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >>>> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >>>> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >>>> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >>>> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >>>> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >>>> 2065 0 Is 0:00.02 -csh (csh) >>>> 2068 0 I 0:00.01 su >>>> 2069 0 S 0:00.04 _su (csh) >>>> 2414 0 R+ 0:00.00 ps ax >>>> >>>> After some minutes though, the usage went up to 39M. WTF? >>>> >>>> So I'm now thoroughly confused. Google didn't really show up any real >>>> answers either. Aside from discovering the true nature of what was >>>> discussed in the posts, my hypothetical theorising is for my own >>>> academics as well; and I'm trying to slim down my kernels to see if I >>>> can improve performance with low memory systems. >>>> >>>> Can process structures cause this much ballooning? I find that hard to >>>> believe given not much is running here. My only other thought would be >>>> pipe or network structures? Anything I'm missing? >>>> >>>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can boot in >>>> seconds as opposed to minutes. Sweet! Although compiling clang took >>>> years... and gcc was built as well :/ >>>> >>>> Cheers >>>> ______________________________**_________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>> freebsd.org" >>>> >>>> ______________________________**_________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>> freebsd.org" >>> >> >> ______________________________**_________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> I'm fowarding this thread in the event the individual, "da Rock" will be >> able to receive more help. >> _______________________________________________ >> freebsd-emulation@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation >> To unsubscribe, send any mail to >> "freebsd-emulation-unsubscribe@freebsd.org" >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: 03/14/12 > > From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 15 04:07:21 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12F56106566C for ; Thu, 15 Mar 2012 04:07:21 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id D94FF8FC14 for ; Thu, 15 Mar 2012 04:07:20 +0000 (UTC) Received: by dadp14 with SMTP id p14so11146741dad.18 for ; Wed, 14 Mar 2012 21:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lySRMOZBYLkGmaySGa1M4gUFL8pRTNX4Ejrr8O4iTcs=; b=KSHoeWzueWcwx+G9g46HquRPuMARhDphkZ0J+uelZ57MTCLPWmi0rtpYAI9xmxY8Ki I1ikb7K/RnitxVwgNkruX6NbBolkywq6Q1Xjm9dO/Q93Z22/pi/sIRwmYRtkKuHk0YCX jh6B0GFcLZB1II+SlWwFK1RD+LzM4L0r/6WiGNGf0F7yhilYZONEYS3+hn9wdElEirZR B90Fpkbxweq2+XECPYCU6KNkO+ryzgGGPbxeDsWEdp+pkm6hJKz/Nliflymnwm9udxk1 6YBzAOMBD/w0vQmk/IGnz/dpOXsmge0rDs61nH0OjQ62l6VeZLOsQzgLVh0u8n/aw2H+ pMzw== MIME-Version: 1.0 Received: by 10.68.223.230 with SMTP id qx6mr1649890pbc.29.1331784440246; Wed, 14 Mar 2012 21:07:20 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Wed, 14 Mar 2012 21:07:20 -0700 (PDT) In-Reply-To: References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> <4F615D09.8030009@mittelstaedt.us> Date: Thu, 15 Mar 2012 00:07:20 -0400 Message-ID: From: Super Bisquit To: Ted Mittelstaedt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-emulation@freebsd.org Subject: Re: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 04:07:21 -0000 Apologies for that response. I read the message again. You may want to cc da Rock with your reply. Again, sorry about that. On 3/15/12, Super Bisquit wrote: > On 3/14/12, Ted Mittelstaedt wrote: >> What do you regard as a "low memory" machine? > On real hardware I've used: > HTC Apache 64/128 ROM/RAM > Embedded 486 with 5M RAM > Older tower maxed at 128M > > I'd say anything less than 64M RAM for normal hardware, less than 32 > for embedded. > > Some systems do not have small memory modules. I have two SunBlade > 1000s that can be stripped down to 128M. > > I'm also aware that the environment limits what the machine can have > installed. > > There are older systems and embedded devices which run/ran on 16kb of > RAM. I'm certain that the oldest electronic led calculators used even > less memory. > I digress. > > > > >> >> Ted >> >> On 3/13/2012 8:30 AM, Super Bisquit wrote: >>> ---------- Forwarded message ---------- >>> From: Da Rock<9Phackers@herveybayaustralia.com.au> >>> Date: Tue, Mar 13, 2012 at 7:17 AM >>> Subject: Re: Kernel memory usage >>> To: freebsd-hackers@freebsd.org >>> >>> >>> On 03/13/12 05:40, Super Bisquit wrote: >>> >>>> CPU architecture and model have a lot to do with performance. >>>> You will also get different results if you used qemu in place of >>>> VirtualBox. Qemu allows you to choose different emulated >>>> architectures, CPUs, and machine bases. What's the downside? You have >>>> to use the command line. >>>> Install qemu and run a series of virtual machines. >>>> Embedded devices also include Power(PC), ARMv?, Coldfire, et al; >>>> you're only dealing with i386 and/or the 64 bit extension (AMD64). >>>> CISC- which does not contain any hardware modification to be a RISC >>>> replacement- runs fewer instructions than RISC due to the limited >>>> number of registers. Take this into consideration every time a >>>> program runs. >>>> Everything else also matters on real and emulated systems: >>>> Is it ide, scsi, sdd, flashdevice for the hard drive? >>>> What type of RAM? >>>> Dedicated or shared disk? >>>> >>> I'm a little confused by the response, I was interested if someone knew >>> what determines the size of kernel in memory (or wired); I only >>> considered >>> the embedded list because they have a greater interest in the memory >>> size >>> working with so little. >>> >>> It is academic as I'm trying to understand the kernel internals, as well >>> as >>> understand what works with low memory so I can tune accordingly. I >>> understand the different CPU instruction sets (roughly), although I >>> would >>> be interested as to the size of the kernel in each. >>> >>> What my question was about was the wired memory size and what makes it >>> grow >>> (to put it super simply :) ). I know some growth would be expected, but >>> this seems obese; how would I find out how much memory a process >>> structure >>> takes? Or else what am I missing? >>> >>> That said I'll have a crack at what you suggest as that follows a whole >>> new >>> interesting tangent :) I have used qemu before, but found VBox a bit >>> more >>> responsive (and, I will admit, easier...) >>> >>> >>>> On 3/11/12, Da >>>> Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>> >>>> wrote: >>>> >>>>> I may be required to move this to embedded, but I am only looking for >>>>> generalisation. >>>>> >>>>> Recently a thread came up on questions regarding memory usage, and a >>>>> post was made regarding wired memory being nearly all kernel- >>>>> something >>>>> I was ready to dispute, but then I thought I'd better make sure. >>>>> >>>>> So I tested a few theories first off: >>>>> >>>>> 1. Comparing memory usage across machines >>>>> >>>>> I checked servers and desktops as well as vm's for memory usage, and I >>>>> found some interesting results. On a firewall with no apps installed >>>>> only 35M wired is used, on a desktop up to 700M~ can be used. Even as >>>>> a >>>>> dedicated server with a few services used it remains around 35M. >>>>> >>>>> Surely this means that the wired memory used is not just kernel? But I >>>>> held off my assumptions as it was still plausible that the structures >>>>> used by the kernel could balloon that far, too. >>>>> >>>>> 2. Stripped down, lean mean, kernel machine >>>>> >>>>> I then (using a vm I was building a kernel for anyway) stripped down a >>>>> kernel in a VBox VM using le drivers for network to see what could be >>>>> achieved. This is my kernel conf: >>>>> >>>>> include GENERIC >>>>> ident VPN >>>>> options IPSEC >>>>> options IPSEC_DEBUG >>>>> options IPSEC_NAT_T >>>>> device crypto >>>>> device enc >>>>> >>>>> # minimise kernel >>>>> nooptions UFS_GJOURNAL >>>>> nooptions MD_ROOT >>>>> nooptions NFSCL >>>>> nooptions NFSD >>>>> nooptions NFSLOCKD >>>>> nooptions NFS_ROOT >>>>> nooptions MSDOSFS >>>>> nooptions CD9660 >>>>> nooptions PROCFS >>>>> nooptions PSEUDOFS >>>>> nodevice fdc >>>>> nodevice mvs >>>>> nodevice siis >>>>> nodevice ahc >>>>> nodevice ahd >>>>> nodevice esp >>>>> nodevice hptiop >>>>> nodevice isp >>>>> nodevice mpt >>>>> nodevice mps >>>>> nodevice sym >>>>> nodevice trm >>>>> nodevice adv >>>>> nodevice adw >>>>> nodevice aic >>>>> nodevice bt >>>>> nodevice ses >>>>> nodevice amr >>>>> nodevice arcmsr >>>>> nodevice ciss >>>>> nodevice dpt >>>>> nodevice hptmv >>>>> nodevice hptrr >>>>> nodevice irr >>>>> nodevice ips >>>>> nodevice mly >>>>> nodevice twa >>>>> nodevice aac >>>>> nodevice aacp >>>>> nodevice ida >>>>> nodevice mfi >>>>> nodevice mlx >>>>> nodevice twe >>>>> nodevice tws >>>>> nodevice splash >>>>> nodevice cbb >>>>> nodevice pccard >>>>> nodevice cardbus >>>>> nodevice uart >>>>> nodevice ppc >>>>> nodevice ppbus >>>>> nodevice lpt >>>>> nodevice plip >>>>> nodevice ppi >>>>> nodevice puc >>>>> nodevice bxe >>>>> nodevice de >>>>> nodevice em >>>>> nodevice igb >>>>> nodevice ixgbe >>>>> nodevice ti >>>>> nodevice txp >>>>> nodevice vx >>>>> nodevice miibus >>>>> nodevice ae >>>>> nodevice age >>>>> nodevice alc >>>>> nodevice ale >>>>> nodevice bce >>>>> nodevice bfe >>>>> nodevice bge >>>>> nodevice dc >>>>> nodevice et >>>>> nodevice fxp >>>>> nodevice jme >>>>> nodevice lge >>>>> nodevice msk >>>>> nodevice nfe >>>>> nodevice nge >>>>> nodevice pcn >>>>> nodevice re >>>>> nodevice rl >>>>> nodevice sf >>>>> nodevice sge >>>>> nodevice sis >>>>> nodevice sk >>>>> nodevice ste >>>>> nodevice stge >>>>> nodevice tl >>>>> nodevice tx >>>>> nodevice vge >>>>> nodevice vr >>>>> nodevice wb >>>>> nodevice xl >>>>> nodevice cs >>>>> nodevice ed >>>>> nodevice ex >>>>> nodevice ep >>>>> nodevice fe >>>>> nodevice sn >>>>> nodevice xe >>>>> nodevice wlan >>>>> nooptions IEEE80211_DEBUG >>>>> nooptions IEEE80211_AMPDU_AGE >>>>> nooptions IEEE80211_SUPPORT_MESH >>>>> nodevice wlan_wep >>>>> nodevice wlan_ccmp >>>>> nodevice wlan_tkip >>>>> nodevice wlan_amrr >>>>> nodevice an >>>>> nodevice ath >>>>> nodevice ath_pci >>>>> nodevice ath_hal >>>>> nooptions AH_SUPPORT_AR5416 >>>>> nodevice ath_rate_sample >>>>> nodevice ipw >>>>> nodevice iwi >>>>> nodevice iwn >>>>> nodevice malo >>>>> nodevice mwl >>>>> nodevice ral >>>>> nodevice wi >>>>> nodevice wpi >>>>> nodevice md >>>>> nooption USB_DEBUG >>>>> nodevice uhci >>>>> nodevice ohci >>>>> nodevice ehci >>>>> nodevice xhci >>>>> nodevice usb >>>>> nodevice uhid >>>>> nodevice ukbd >>>>> nodevice ulpt >>>>> nodevice umass >>>>> nodevice ums >>>>> nodevice urio >>>>> nodevice u3g >>>>> nodevice uark >>>>> nodevice ubsa >>>>> nodevice uftdi >>>>> nodevice uipaq >>>>> nodevice uplcom >>>>> nodevice uslcom >>>>> nodevice uvisor >>>>> nodevice uvscom >>>>> nodevice aue >>>>> nodevice axe >>>>> nodevice cdce >>>>> nodevice cue >>>>> nodevice kue >>>>> nodevice rue >>>>> nodevice udav >>>>> nodevice rum >>>>> nodevice run >>>>> nodevice uath >>>>> nodevice upgt >>>>> nodevice ural >>>>> nodevice urtw >>>>> nodevice zyd >>>>> #nodevice firewire >>>>> nodevice fwe >>>>> nodevice fwip >>>>> #nodevice dcons >>>>> #nodevice dcons_rom >>>>> nodevice sound >>>>> nodevice snd_es137x >>>>> nodevice snd_hda >>>>> nodevice snd_ich >>>>> nodevice snd_uaudio >>>>> nodevice snd_via8233 >>>>> >>>>> World was also rebuilt as recommended by the handbook. As you can see >>>>> I >>>>> was rebuilding for IPSEC (for testing purposes only note). I couldn't >>>>> remove dcons (not sure why- missing defined references), and that >>>>> pulled >>>>> in firewire too. >>>>> >>>>> The result was surprising: a 14M kernel became 6.3M, and when running >>>>> I >>>>> found it only used 19M used for wired (whoopee!) as opposed to 35M. No >>>>> services were running per se, only the usual suspects in base: >>>>> >>>>> vpn-test# ps ax >>>>> PID TT STAT TIME COMMAND >>>>> 0 ?? DLs 0:00.11 [kernel] >>>>> 1 ?? ILs 0:00.01 /sbin/init -- >>>>> 2 ?? DL 0:00.00 [crypto] >>>>> 3 ?? DL 0:00.00 [crypto returns] >>>>> 4 ?? DL 0:00.00 [sctp_iterator] >>>>> 5 ?? DL 0:00.00 [xpt_thrd] >>>>> 6 ?? DL 0:00.10 [pagedaemon] >>>>> 7 ?? DL 0:00.00 [vmdaemon] >>>>> 8 ?? DL 0:00.01 [pagezero] >>>>> 9 ?? DL 0:00.30 [bufdaemon] >>>>> 10 ?? DL 0:00.00 [audit] >>>>> 11 ?? RL 589:34.00 [idle] >>>>> 12 ?? WL 0:38.64 [intr] >>>>> 13 ?? DL 0:12.21 [geom] >>>>> 14 ?? DL 0:03.30 [yarrow] >>>>> 15 ?? DL 0:04.40 [syncer] >>>>> 16 ?? DL 0:00.63 [vnlru] >>>>> 17 ?? DL 0:00.53 [softdepflush] >>>>> 104 ?? Is 0:00.00 adjkerntz -i >>>>> 582 ?? Is 0:00.00 /sbin/devd >>>>> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >>>>> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >>>>> /var/run/ntpd.pid >>>>> 977 ?? Is 0:00.00 /usr/sbin/sshd >>>>> 984 ?? Ss 0:00.81 sendmail: accepting connections (sendmail) >>>>> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >>>>> /var/spool/client >>>>> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >>>>> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >>>>> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >>>>> 1052 v0 Is 0:00.01 login [pam] (login) >>>>> 1060 v0 I+ 0:00.02 -csh (csh) >>>>> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >>>>> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >>>>> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >>>>> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >>>>> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >>>>> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >>>>> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >>>>> 2065 0 Is 0:00.02 -csh (csh) >>>>> 2068 0 I 0:00.01 su >>>>> 2069 0 S 0:00.04 _su (csh) >>>>> 2414 0 R+ 0:00.00 ps ax >>>>> >>>>> After some minutes though, the usage went up to 39M. WTF? >>>>> >>>>> So I'm now thoroughly confused. Google didn't really show up any real >>>>> answers either. Aside from discovering the true nature of what was >>>>> discussed in the posts, my hypothetical theorising is for my own >>>>> academics as well; and I'm trying to slim down my kernels to see if I >>>>> can improve performance with low memory systems. >>>>> >>>>> Can process structures cause this much ballooning? I find that hard to >>>>> believe given not much is running here. My only other thought would be >>>>> pipe or network structures? Anything I'm missing? >>>>> >>>>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can boot >>>>> in >>>>> seconds as opposed to minutes. Sweet! Although compiling clang took >>>>> years... and gcc was built as well :/ >>>>> >>>>> Cheers >>>>> ______________________________**_________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>>> freebsd.org" >>>>> >>>>> ______________________________**_________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>> freebsd.org" >>>> >>> >>> ______________________________**_________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >>> >>> I'm fowarding this thread in the event the individual, "da Rock" will be >>> able to receive more help. >>> _______________________________________________ >>> freebsd-emulation@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation >>> To unsubscribe, send any mail to >>> "freebsd-emulation-unsubscribe@freebsd.org" >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: >>> 03/14/12 >> >> > From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 15 04:33:07 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF214106564A for ; Thu, 15 Mar 2012 04:33:07 +0000 (UTC) (envelope-from freebsd-emulation@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 05B698FC18 for ; Thu, 15 Mar 2012 04:33:06 +0000 (UTC) Received: from mail.unitedinsong.com.au (bell.herveybayaustralia.com.au [192.168.0.40]) by mail.unitedinsong.com.au (Postfix) with ESMTP id 08F0A5C28 for ; Thu, 15 Mar 2012 14:46:37 +1000 (EST) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 7F3775C22 for ; Thu, 15 Mar 2012 14:46:37 +1000 (EST) Message-ID: <4F616FC2.4090106@herveybayaustralia.com.au> Date: Thu, 15 Mar 2012 14:27:46 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> <4F615D09.8030009@mittelstaedt.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-emulation@freebsd.org List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 04:33:08 -0000 On 03/15/12 14:07, Super Bisquit wrote: > Apologies for that response. I read the message again. You may want to > cc da Rock with your reply. > > Again, sorry about that. Thats cool. I'm here too :) > > On 3/15/12, Super Bisquit wrote: >> On 3/14/12, Ted Mittelstaedt wrote: >>> What do you regard as a "low memory" machine? >> On real hardware I've used: >> HTC Apache 64/128 ROM/RAM >> Embedded 486 with 5M RAM >> Older tower maxed at 128M >> >> I'd say anything less than 64M RAM for normal hardware, less than 32 >> for embedded. >> >> Some systems do not have small memory modules. I have two SunBlade >> 1000s that can be stripped down to 128M. >> >> I'm also aware that the environment limits what the machine can have >> installed. >> >> There are older systems and embedded devices which run/ran on 16kb of >> RAM. I'm certain that the oldest electronic led calculators used even >> less memory. >> I digress. >> >> >> >> >>> Ted >>> >>> On 3/13/2012 8:30 AM, Super Bisquit wrote: >>>> ---------- Forwarded message ---------- >>>> From: Da Rock<9Phackers@herveybayaustralia.com.au> >>>> Date: Tue, Mar 13, 2012 at 7:17 AM >>>> Subject: Re: Kernel memory usage >>>> To: freebsd-hackers@freebsd.org >>>> >>>> >>>> On 03/13/12 05:40, Super Bisquit wrote: >>>> >>>>> CPU architecture and model have a lot to do with performance. >>>>> You will also get different results if you used qemu in place of >>>>> VirtualBox. Qemu allows you to choose different emulated >>>>> architectures, CPUs, and machine bases. What's the downside? You have >>>>> to use the command line. >>>>> Install qemu and run a series of virtual machines. >>>>> Embedded devices also include Power(PC), ARMv?, Coldfire, et al; >>>>> you're only dealing with i386 and/or the 64 bit extension (AMD64). >>>>> CISC- which does not contain any hardware modification to be a RISC >>>>> replacement- runs fewer instructions than RISC due to the limited >>>>> number of registers. Take this into consideration every time a >>>>> program runs. >>>>> Everything else also matters on real and emulated systems: >>>>> Is it ide, scsi, sdd, flashdevice for the hard drive? >>>>> What type of RAM? >>>>> Dedicated or shared disk? >>>>> >>>> I'm a little confused by the response, I was interested if someone knew >>>> what determines the size of kernel in memory (or wired); I only >>>> considered >>>> the embedded list because they have a greater interest in the memory >>>> size >>>> working with so little. >>>> >>>> It is academic as I'm trying to understand the kernel internals, as well >>>> as >>>> understand what works with low memory so I can tune accordingly. I >>>> understand the different CPU instruction sets (roughly), although I >>>> would >>>> be interested as to the size of the kernel in each. >>>> >>>> What my question was about was the wired memory size and what makes it >>>> grow >>>> (to put it super simply :) ). I know some growth would be expected, but >>>> this seems obese; how would I find out how much memory a process >>>> structure >>>> takes? Or else what am I missing? >>>> >>>> That said I'll have a crack at what you suggest as that follows a whole >>>> new >>>> interesting tangent :) I have used qemu before, but found VBox a bit >>>> more >>>> responsive (and, I will admit, easier...) >>>> >>>> >>>>> On 3/11/12, Da >>>>> Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>> >>>>> wrote: >>>>> >>>>>> I may be required to move this to embedded, but I am only looking for >>>>>> generalisation. >>>>>> >>>>>> Recently a thread came up on questions regarding memory usage, and a >>>>>> post was made regarding wired memory being nearly all kernel- >>>>>> something >>>>>> I was ready to dispute, but then I thought I'd better make sure. >>>>>> >>>>>> So I tested a few theories first off: >>>>>> >>>>>> 1. Comparing memory usage across machines >>>>>> >>>>>> I checked servers and desktops as well as vm's for memory usage, and I >>>>>> found some interesting results. On a firewall with no apps installed >>>>>> only 35M wired is used, on a desktop up to 700M~ can be used. Even as >>>>>> a >>>>>> dedicated server with a few services used it remains around 35M. >>>>>> >>>>>> Surely this means that the wired memory used is not just kernel? But I >>>>>> held off my assumptions as it was still plausible that the structures >>>>>> used by the kernel could balloon that far, too. >>>>>> >>>>>> 2. Stripped down, lean mean, kernel machine >>>>>> >>>>>> I then (using a vm I was building a kernel for anyway) stripped down a >>>>>> kernel in a VBox VM using le drivers for network to see what could be >>>>>> achieved. This is my kernel conf: >>>>>> >>>>>> include GENERIC >>>>>> ident VPN >>>>>> options IPSEC >>>>>> options IPSEC_DEBUG >>>>>> options IPSEC_NAT_T >>>>>> device crypto >>>>>> device enc >>>>>> >>>>>> # minimise kernel >>>>>> nooptions UFS_GJOURNAL >>>>>> nooptions MD_ROOT >>>>>> nooptions NFSCL >>>>>> nooptions NFSD >>>>>> nooptions NFSLOCKD >>>>>> nooptions NFS_ROOT >>>>>> nooptions MSDOSFS >>>>>> nooptions CD9660 >>>>>> nooptions PROCFS >>>>>> nooptions PSEUDOFS >>>>>> nodevice fdc >>>>>> nodevice mvs >>>>>> nodevice siis >>>>>> nodevice ahc >>>>>> nodevice ahd >>>>>> nodevice esp >>>>>> nodevice hptiop >>>>>> nodevice isp >>>>>> nodevice mpt >>>>>> nodevice mps >>>>>> nodevice sym >>>>>> nodevice trm >>>>>> nodevice adv >>>>>> nodevice adw >>>>>> nodevice aic >>>>>> nodevice bt >>>>>> nodevice ses >>>>>> nodevice amr >>>>>> nodevice arcmsr >>>>>> nodevice ciss >>>>>> nodevice dpt >>>>>> nodevice hptmv >>>>>> nodevice hptrr >>>>>> nodevice irr >>>>>> nodevice ips >>>>>> nodevice mly >>>>>> nodevice twa >>>>>> nodevice aac >>>>>> nodevice aacp >>>>>> nodevice ida >>>>>> nodevice mfi >>>>>> nodevice mlx >>>>>> nodevice twe >>>>>> nodevice tws >>>>>> nodevice splash >>>>>> nodevice cbb >>>>>> nodevice pccard >>>>>> nodevice cardbus >>>>>> nodevice uart >>>>>> nodevice ppc >>>>>> nodevice ppbus >>>>>> nodevice lpt >>>>>> nodevice plip >>>>>> nodevice ppi >>>>>> nodevice puc >>>>>> nodevice bxe >>>>>> nodevice de >>>>>> nodevice em >>>>>> nodevice igb >>>>>> nodevice ixgbe >>>>>> nodevice ti >>>>>> nodevice txp >>>>>> nodevice vx >>>>>> nodevice miibus >>>>>> nodevice ae >>>>>> nodevice age >>>>>> nodevice alc >>>>>> nodevice ale >>>>>> nodevice bce >>>>>> nodevice bfe >>>>>> nodevice bge >>>>>> nodevice dc >>>>>> nodevice et >>>>>> nodevice fxp >>>>>> nodevice jme >>>>>> nodevice lge >>>>>> nodevice msk >>>>>> nodevice nfe >>>>>> nodevice nge >>>>>> nodevice pcn >>>>>> nodevice re >>>>>> nodevice rl >>>>>> nodevice sf >>>>>> nodevice sge >>>>>> nodevice sis >>>>>> nodevice sk >>>>>> nodevice ste >>>>>> nodevice stge >>>>>> nodevice tl >>>>>> nodevice tx >>>>>> nodevice vge >>>>>> nodevice vr >>>>>> nodevice wb >>>>>> nodevice xl >>>>>> nodevice cs >>>>>> nodevice ed >>>>>> nodevice ex >>>>>> nodevice ep >>>>>> nodevice fe >>>>>> nodevice sn >>>>>> nodevice xe >>>>>> nodevice wlan >>>>>> nooptions IEEE80211_DEBUG >>>>>> nooptions IEEE80211_AMPDU_AGE >>>>>> nooptions IEEE80211_SUPPORT_MESH >>>>>> nodevice wlan_wep >>>>>> nodevice wlan_ccmp >>>>>> nodevice wlan_tkip >>>>>> nodevice wlan_amrr >>>>>> nodevice an >>>>>> nodevice ath >>>>>> nodevice ath_pci >>>>>> nodevice ath_hal >>>>>> nooptions AH_SUPPORT_AR5416 >>>>>> nodevice ath_rate_sample >>>>>> nodevice ipw >>>>>> nodevice iwi >>>>>> nodevice iwn >>>>>> nodevice malo >>>>>> nodevice mwl >>>>>> nodevice ral >>>>>> nodevice wi >>>>>> nodevice wpi >>>>>> nodevice md >>>>>> nooption USB_DEBUG >>>>>> nodevice uhci >>>>>> nodevice ohci >>>>>> nodevice ehci >>>>>> nodevice xhci >>>>>> nodevice usb >>>>>> nodevice uhid >>>>>> nodevice ukbd >>>>>> nodevice ulpt >>>>>> nodevice umass >>>>>> nodevice ums >>>>>> nodevice urio >>>>>> nodevice u3g >>>>>> nodevice uark >>>>>> nodevice ubsa >>>>>> nodevice uftdi >>>>>> nodevice uipaq >>>>>> nodevice uplcom >>>>>> nodevice uslcom >>>>>> nodevice uvisor >>>>>> nodevice uvscom >>>>>> nodevice aue >>>>>> nodevice axe >>>>>> nodevice cdce >>>>>> nodevice cue >>>>>> nodevice kue >>>>>> nodevice rue >>>>>> nodevice udav >>>>>> nodevice rum >>>>>> nodevice run >>>>>> nodevice uath >>>>>> nodevice upgt >>>>>> nodevice ural >>>>>> nodevice urtw >>>>>> nodevice zyd >>>>>> #nodevice firewire >>>>>> nodevice fwe >>>>>> nodevice fwip >>>>>> #nodevice dcons >>>>>> #nodevice dcons_rom >>>>>> nodevice sound >>>>>> nodevice snd_es137x >>>>>> nodevice snd_hda >>>>>> nodevice snd_ich >>>>>> nodevice snd_uaudio >>>>>> nodevice snd_via8233 >>>>>> >>>>>> World was also rebuilt as recommended by the handbook. As you can see >>>>>> I >>>>>> was rebuilding for IPSEC (for testing purposes only note). I couldn't >>>>>> remove dcons (not sure why- missing defined references), and that >>>>>> pulled >>>>>> in firewire too. >>>>>> >>>>>> The result was surprising: a 14M kernel became 6.3M, and when running >>>>>> I >>>>>> found it only used 19M used for wired (whoopee!) as opposed to 35M. No >>>>>> services were running per se, only the usual suspects in base: >>>>>> >>>>>> vpn-test# ps ax >>>>>> PID TT STAT TIME COMMAND >>>>>> 0 ?? DLs 0:00.11 [kernel] >>>>>> 1 ?? ILs 0:00.01 /sbin/init -- >>>>>> 2 ?? DL 0:00.00 [crypto] >>>>>> 3 ?? DL 0:00.00 [crypto returns] >>>>>> 4 ?? DL 0:00.00 [sctp_iterator] >>>>>> 5 ?? DL 0:00.00 [xpt_thrd] >>>>>> 6 ?? DL 0:00.10 [pagedaemon] >>>>>> 7 ?? DL 0:00.00 [vmdaemon] >>>>>> 8 ?? DL 0:00.01 [pagezero] >>>>>> 9 ?? DL 0:00.30 [bufdaemon] >>>>>> 10 ?? DL 0:00.00 [audit] >>>>>> 11 ?? RL 589:34.00 [idle] >>>>>> 12 ?? WL 0:38.64 [intr] >>>>>> 13 ?? DL 0:12.21 [geom] >>>>>> 14 ?? DL 0:03.30 [yarrow] >>>>>> 15 ?? DL 0:04.40 [syncer] >>>>>> 16 ?? DL 0:00.63 [vnlru] >>>>>> 17 ?? DL 0:00.53 [softdepflush] >>>>>> 104 ?? Is 0:00.00 adjkerntz -i >>>>>> 582 ?? Is 0:00.00 /sbin/devd >>>>>> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >>>>>> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >>>>>> /var/run/ntpd.pid >>>>>> 977 ?? Is 0:00.00 /usr/sbin/sshd >>>>>> 984 ?? Ss 0:00.81 sendmail: accepting connections (sendmail) >>>>>> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >>>>>> /var/spool/client >>>>>> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >>>>>> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >>>>>> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >>>>>> 1052 v0 Is 0:00.01 login [pam] (login) >>>>>> 1060 v0 I+ 0:00.02 -csh (csh) >>>>>> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >>>>>> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >>>>>> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >>>>>> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >>>>>> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >>>>>> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >>>>>> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >>>>>> 2065 0 Is 0:00.02 -csh (csh) >>>>>> 2068 0 I 0:00.01 su >>>>>> 2069 0 S 0:00.04 _su (csh) >>>>>> 2414 0 R+ 0:00.00 ps ax >>>>>> >>>>>> After some minutes though, the usage went up to 39M. WTF? >>>>>> >>>>>> So I'm now thoroughly confused. Google didn't really show up any real >>>>>> answers either. Aside from discovering the true nature of what was >>>>>> discussed in the posts, my hypothetical theorising is for my own >>>>>> academics as well; and I'm trying to slim down my kernels to see if I >>>>>> can improve performance with low memory systems. >>>>>> >>>>>> Can process structures cause this much ballooning? I find that hard to >>>>>> believe given not much is running here. My only other thought would be >>>>>> pipe or network structures? Anything I'm missing? >>>>>> >>>>>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can boot >>>>>> in >>>>>> seconds as opposed to minutes. Sweet! Although compiling clang took >>>>>> years... and gcc was built as well :/ >>>>>> >>>>>> Cheers >>>>>> ______________________________**_________________ >>>>>> freebsd-hackers@freebsd.org mailing list >>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>>>> freebsd.org" >>>>>> >>>>>> ______________________________**_________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>>> freebsd.org" >>>>> >>>> ______________________________**_________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>> To unsubscribe, send any mail to >>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>> >>>> I'm fowarding this thread in the event the individual, "da Rock" will be >>>> able to receive more help. >>>> _______________________________________________ >>>> freebsd-emulation@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation >>>> To unsubscribe, send any mail to >>>> "freebsd-emulation-unsubscribe@freebsd.org" >>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: >>>> 03/14/12 >>> > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 15 05:22:18 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77345106566C for ; Thu, 15 Mar 2012 05:22:18 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (unknown [IPv6:2607:fa80:40::6]) by mx1.freebsd.org (Postfix) with ESMTP id 13CCA8FC0C for ; Thu, 15 Mar 2012 05:22:18 +0000 (UTC) Received: from [192.168.1.10] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) (authenticated bits=0) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id q2F5M1nk006318; Wed, 14 Mar 2012 22:22:11 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4F617C63.9030106@mittelstaedt.us> Date: Wed, 14 Mar 2012 22:21:39 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0) Gecko/20110929 Thunderbird/7.0 MIME-Version: 1.0 To: Super Bisquit References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> <4F615D09.8030009@mittelstaedt.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Cc: freebsd-emulation@freebsd.org Subject: Re: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 05:22:18 -0000 A number of FreeBSD kernel structures are dynamically created at boot time - based on the amount of ram in the system. I would guess if you boot your stripped BSD image on a virtual system with 64Mb of ram you wouldn't see the kernel grow to 32MB It would be interesting to see FreeBSD running on a Smartphone. Ted On 3/14/2012 9:03 PM, Super Bisquit wrote: > On 3/14/12, Ted Mittelstaedt wrote: >> What do you regard as a "low memory" machine? > On real hardware I've used: > HTC Apache 64/128 ROM/RAM > Embedded 486 with 5M RAM > Older tower maxed at 128M > > I'd say anything less than 64M RAM for normal hardware, less than 32 > for embedded. > > Some systems do not have small memory modules. I have two SunBlade > 1000s that can be stripped down to 128M. > > I'm also aware that the environment limits what the machine can have installed. > > There are older systems and embedded devices which run/ran on 16kb of > RAM. I'm certain that the oldest electronic led calculators used even > less memory. > I digress. > > > > >> >> Ted >> >> On 3/13/2012 8:30 AM, Super Bisquit wrote: >>> ---------- Forwarded message ---------- >>> From: Da Rock<9Phackers@herveybayaustralia.com.au> >>> Date: Tue, Mar 13, 2012 at 7:17 AM >>> Subject: Re: Kernel memory usage >>> To: freebsd-hackers@freebsd.org >>> >>> >>> On 03/13/12 05:40, Super Bisquit wrote: >>> >>>> CPU architecture and model have a lot to do with performance. >>>> You will also get different results if you used qemu in place of >>>> VirtualBox. Qemu allows you to choose different emulated >>>> architectures, CPUs, and machine bases. What's the downside? You have >>>> to use the command line. >>>> Install qemu and run a series of virtual machines. >>>> Embedded devices also include Power(PC), ARMv?, Coldfire, et al; >>>> you're only dealing with i386 and/or the 64 bit extension (AMD64). >>>> CISC- which does not contain any hardware modification to be a RISC >>>> replacement- runs fewer instructions than RISC due to the limited >>>> number of registers. Take this into consideration every time a >>>> program runs. >>>> Everything else also matters on real and emulated systems: >>>> Is it ide, scsi, sdd, flashdevice for the hard drive? >>>> What type of RAM? >>>> Dedicated or shared disk? >>>> >>> I'm a little confused by the response, I was interested if someone knew >>> what determines the size of kernel in memory (or wired); I only considered >>> the embedded list because they have a greater interest in the memory size >>> working with so little. >>> >>> It is academic as I'm trying to understand the kernel internals, as well >>> as >>> understand what works with low memory so I can tune accordingly. I >>> understand the different CPU instruction sets (roughly), although I would >>> be interested as to the size of the kernel in each. >>> >>> What my question was about was the wired memory size and what makes it >>> grow >>> (to put it super simply :) ). I know some growth would be expected, but >>> this seems obese; how would I find out how much memory a process structure >>> takes? Or else what am I missing? >>> >>> That said I'll have a crack at what you suggest as that follows a whole >>> new >>> interesting tangent :) I have used qemu before, but found VBox a bit more >>> responsive (and, I will admit, easier...) >>> >>> >>>> On 3/11/12, Da >>>> Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>> >>>> wrote: >>>> >>>>> I may be required to move this to embedded, but I am only looking for >>>>> generalisation. >>>>> >>>>> Recently a thread came up on questions regarding memory usage, and a >>>>> post was made regarding wired memory being nearly all kernel- something >>>>> I was ready to dispute, but then I thought I'd better make sure. >>>>> >>>>> So I tested a few theories first off: >>>>> >>>>> 1. Comparing memory usage across machines >>>>> >>>>> I checked servers and desktops as well as vm's for memory usage, and I >>>>> found some interesting results. On a firewall with no apps installed >>>>> only 35M wired is used, on a desktop up to 700M~ can be used. Even as a >>>>> dedicated server with a few services used it remains around 35M. >>>>> >>>>> Surely this means that the wired memory used is not just kernel? But I >>>>> held off my assumptions as it was still plausible that the structures >>>>> used by the kernel could balloon that far, too. >>>>> >>>>> 2. Stripped down, lean mean, kernel machine >>>>> >>>>> I then (using a vm I was building a kernel for anyway) stripped down a >>>>> kernel in a VBox VM using le drivers for network to see what could be >>>>> achieved. This is my kernel conf: >>>>> >>>>> include GENERIC >>>>> ident VPN >>>>> options IPSEC >>>>> options IPSEC_DEBUG >>>>> options IPSEC_NAT_T >>>>> device crypto >>>>> device enc >>>>> >>>>> # minimise kernel >>>>> nooptions UFS_GJOURNAL >>>>> nooptions MD_ROOT >>>>> nooptions NFSCL >>>>> nooptions NFSD >>>>> nooptions NFSLOCKD >>>>> nooptions NFS_ROOT >>>>> nooptions MSDOSFS >>>>> nooptions CD9660 >>>>> nooptions PROCFS >>>>> nooptions PSEUDOFS >>>>> nodevice fdc >>>>> nodevice mvs >>>>> nodevice siis >>>>> nodevice ahc >>>>> nodevice ahd >>>>> nodevice esp >>>>> nodevice hptiop >>>>> nodevice isp >>>>> nodevice mpt >>>>> nodevice mps >>>>> nodevice sym >>>>> nodevice trm >>>>> nodevice adv >>>>> nodevice adw >>>>> nodevice aic >>>>> nodevice bt >>>>> nodevice ses >>>>> nodevice amr >>>>> nodevice arcmsr >>>>> nodevice ciss >>>>> nodevice dpt >>>>> nodevice hptmv >>>>> nodevice hptrr >>>>> nodevice irr >>>>> nodevice ips >>>>> nodevice mly >>>>> nodevice twa >>>>> nodevice aac >>>>> nodevice aacp >>>>> nodevice ida >>>>> nodevice mfi >>>>> nodevice mlx >>>>> nodevice twe >>>>> nodevice tws >>>>> nodevice splash >>>>> nodevice cbb >>>>> nodevice pccard >>>>> nodevice cardbus >>>>> nodevice uart >>>>> nodevice ppc >>>>> nodevice ppbus >>>>> nodevice lpt >>>>> nodevice plip >>>>> nodevice ppi >>>>> nodevice puc >>>>> nodevice bxe >>>>> nodevice de >>>>> nodevice em >>>>> nodevice igb >>>>> nodevice ixgbe >>>>> nodevice ti >>>>> nodevice txp >>>>> nodevice vx >>>>> nodevice miibus >>>>> nodevice ae >>>>> nodevice age >>>>> nodevice alc >>>>> nodevice ale >>>>> nodevice bce >>>>> nodevice bfe >>>>> nodevice bge >>>>> nodevice dc >>>>> nodevice et >>>>> nodevice fxp >>>>> nodevice jme >>>>> nodevice lge >>>>> nodevice msk >>>>> nodevice nfe >>>>> nodevice nge >>>>> nodevice pcn >>>>> nodevice re >>>>> nodevice rl >>>>> nodevice sf >>>>> nodevice sge >>>>> nodevice sis >>>>> nodevice sk >>>>> nodevice ste >>>>> nodevice stge >>>>> nodevice tl >>>>> nodevice tx >>>>> nodevice vge >>>>> nodevice vr >>>>> nodevice wb >>>>> nodevice xl >>>>> nodevice cs >>>>> nodevice ed >>>>> nodevice ex >>>>> nodevice ep >>>>> nodevice fe >>>>> nodevice sn >>>>> nodevice xe >>>>> nodevice wlan >>>>> nooptions IEEE80211_DEBUG >>>>> nooptions IEEE80211_AMPDU_AGE >>>>> nooptions IEEE80211_SUPPORT_MESH >>>>> nodevice wlan_wep >>>>> nodevice wlan_ccmp >>>>> nodevice wlan_tkip >>>>> nodevice wlan_amrr >>>>> nodevice an >>>>> nodevice ath >>>>> nodevice ath_pci >>>>> nodevice ath_hal >>>>> nooptions AH_SUPPORT_AR5416 >>>>> nodevice ath_rate_sample >>>>> nodevice ipw >>>>> nodevice iwi >>>>> nodevice iwn >>>>> nodevice malo >>>>> nodevice mwl >>>>> nodevice ral >>>>> nodevice wi >>>>> nodevice wpi >>>>> nodevice md >>>>> nooption USB_DEBUG >>>>> nodevice uhci >>>>> nodevice ohci >>>>> nodevice ehci >>>>> nodevice xhci >>>>> nodevice usb >>>>> nodevice uhid >>>>> nodevice ukbd >>>>> nodevice ulpt >>>>> nodevice umass >>>>> nodevice ums >>>>> nodevice urio >>>>> nodevice u3g >>>>> nodevice uark >>>>> nodevice ubsa >>>>> nodevice uftdi >>>>> nodevice uipaq >>>>> nodevice uplcom >>>>> nodevice uslcom >>>>> nodevice uvisor >>>>> nodevice uvscom >>>>> nodevice aue >>>>> nodevice axe >>>>> nodevice cdce >>>>> nodevice cue >>>>> nodevice kue >>>>> nodevice rue >>>>> nodevice udav >>>>> nodevice rum >>>>> nodevice run >>>>> nodevice uath >>>>> nodevice upgt >>>>> nodevice ural >>>>> nodevice urtw >>>>> nodevice zyd >>>>> #nodevice firewire >>>>> nodevice fwe >>>>> nodevice fwip >>>>> #nodevice dcons >>>>> #nodevice dcons_rom >>>>> nodevice sound >>>>> nodevice snd_es137x >>>>> nodevice snd_hda >>>>> nodevice snd_ich >>>>> nodevice snd_uaudio >>>>> nodevice snd_via8233 >>>>> >>>>> World was also rebuilt as recommended by the handbook. As you can see I >>>>> was rebuilding for IPSEC (for testing purposes only note). I couldn't >>>>> remove dcons (not sure why- missing defined references), and that pulled >>>>> in firewire too. >>>>> >>>>> The result was surprising: a 14M kernel became 6.3M, and when running I >>>>> found it only used 19M used for wired (whoopee!) as opposed to 35M. No >>>>> services were running per se, only the usual suspects in base: >>>>> >>>>> vpn-test# ps ax >>>>> PID TT STAT TIME COMMAND >>>>> 0 ?? DLs 0:00.11 [kernel] >>>>> 1 ?? ILs 0:00.01 /sbin/init -- >>>>> 2 ?? DL 0:00.00 [crypto] >>>>> 3 ?? DL 0:00.00 [crypto returns] >>>>> 4 ?? DL 0:00.00 [sctp_iterator] >>>>> 5 ?? DL 0:00.00 [xpt_thrd] >>>>> 6 ?? DL 0:00.10 [pagedaemon] >>>>> 7 ?? DL 0:00.00 [vmdaemon] >>>>> 8 ?? DL 0:00.01 [pagezero] >>>>> 9 ?? DL 0:00.30 [bufdaemon] >>>>> 10 ?? DL 0:00.00 [audit] >>>>> 11 ?? RL 589:34.00 [idle] >>>>> 12 ?? WL 0:38.64 [intr] >>>>> 13 ?? DL 0:12.21 [geom] >>>>> 14 ?? DL 0:03.30 [yarrow] >>>>> 15 ?? DL 0:04.40 [syncer] >>>>> 16 ?? DL 0:00.63 [vnlru] >>>>> 17 ?? DL 0:00.53 [softdepflush] >>>>> 104 ?? Is 0:00.00 adjkerntz -i >>>>> 582 ?? Is 0:00.00 /sbin/devd >>>>> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >>>>> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >>>>> /var/run/ntpd.pid >>>>> 977 ?? Is 0:00.00 /usr/sbin/sshd >>>>> 984 ?? Ss 0:00.81 sendmail: accepting connections (sendmail) >>>>> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >>>>> /var/spool/client >>>>> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >>>>> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >>>>> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >>>>> 1052 v0 Is 0:00.01 login [pam] (login) >>>>> 1060 v0 I+ 0:00.02 -csh (csh) >>>>> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >>>>> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >>>>> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >>>>> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >>>>> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >>>>> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >>>>> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >>>>> 2065 0 Is 0:00.02 -csh (csh) >>>>> 2068 0 I 0:00.01 su >>>>> 2069 0 S 0:00.04 _su (csh) >>>>> 2414 0 R+ 0:00.00 ps ax >>>>> >>>>> After some minutes though, the usage went up to 39M. WTF? >>>>> >>>>> So I'm now thoroughly confused. Google didn't really show up any real >>>>> answers either. Aside from discovering the true nature of what was >>>>> discussed in the posts, my hypothetical theorising is for my own >>>>> academics as well; and I'm trying to slim down my kernels to see if I >>>>> can improve performance with low memory systems. >>>>> >>>>> Can process structures cause this much ballooning? I find that hard to >>>>> believe given not much is running here. My only other thought would be >>>>> pipe or network structures? Anything I'm missing? >>>>> >>>>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can boot in >>>>> seconds as opposed to minutes. Sweet! Although compiling clang took >>>>> years... and gcc was built as well :/ >>>>> >>>>> Cheers >>>>> ______________________________**_________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>>> freebsd.org" >>>>> >>>>> ______________________________**_________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>> freebsd.org" >>>> >>> >>> ______________________________**_________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> >>> I'm fowarding this thread in the event the individual, "da Rock" will be >>> able to receive more help. >>> _______________________________________________ >>> freebsd-emulation@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation >>> To unsubscribe, send any mail to >>> "freebsd-emulation-unsubscribe@freebsd.org" >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: 03/14/12 >> >> > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: 03/14/12 From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 15 05:52:21 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 750551065670 for ; Thu, 15 Mar 2012 05:52:21 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0A65D8FC16 for ; Thu, 15 Mar 2012 05:52:20 +0000 (UTC) Received: by wern13 with SMTP id n13so3179544wer.13 for ; Wed, 14 Mar 2012 22:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/OOz1zhgPHJPr7FKK8MDTQDue5mQXpic2UXxKtWngrQ=; b=WACwQierGKyVO3qy6+pILRgj/TELsSSnFXzFOQOgbX60mm+TmqnUTjj6Q9gQtiJq60 dVu4x7Lg1vnlP+qA8JOIhmP1mqqSS4GQJ/kRtvlmjkpukJ+70knTmqvZcrm+/TMPtkLP 77JZJDju8/LOpR1kPNjet9SuVZvmL2PvSqQrG88B/oak96YPBJBH5FLM1h+v8TurWW0N ggfYHf+8H9J5PZ0JQ9nCJIQE6BROxKvEqbU7gRLDJ1PC+08kAj/dbRBiWcKCgPnkGs9C SXuoNSIcG21VJef4oWLcELi8HK4Jv1dSMHInTzkdsWG77LDEA03DBM7KK6mZ2aQcYklZ 63UA== MIME-Version: 1.0 Received: by 10.180.8.164 with SMTP id s4mr12514897wia.6.1331790740001; Wed, 14 Mar 2012 22:52:20 -0700 (PDT) Received: by 10.180.102.6 with HTTP; Wed, 14 Mar 2012 22:52:19 -0700 (PDT) Date: Thu, 15 Mar 2012 01:52:19 -0400 Message-ID: From: grarpamp To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: VirtualBox missing from pkg FTP X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 05:52:21 -0000 > Ted wrote in effect > ... building ports from port src ... Hopefully it was pretty clear that I'm referring solely to binary packages here, not building ports from src. Those aware of base vs. ports/pkgs should expect issues when backtracking branches and 'not do that', it's not supported. However in 17 days, the new legacy team will kickoff by first providing full support for those still running 2.2.10-RELEASE. Now that it's known to be missing from the dirlist, I'm sure the VBox base _binary_package_ will show up again in a week or so. From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 15 06:47:14 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4085106566C for ; Thu, 15 Mar 2012 06:47:14 +0000 (UTC) (envelope-from freebsd-emulation@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id DBF0F8FC0C for ; Thu, 15 Mar 2012 06:47:13 +0000 (UTC) Received: from mail.unitedinsong.com.au (bell.herveybayaustralia.com.au [192.168.0.40]) by mail.unitedinsong.com.au (Postfix) with ESMTP id A8FC35C28 for ; Thu, 15 Mar 2012 17:00:38 +1000 (EST) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 35C4A5C22 for ; Thu, 15 Mar 2012 17:00:38 +1000 (EST) Message-ID: <4F618F2B.7040709@herveybayaustralia.com.au> Date: Thu, 15 Mar 2012 16:41:47 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> <4F615D09.8030009@mittelstaedt.us> <4F617C63.9030106@mittelstaedt.us> In-Reply-To: <4F617C63.9030106@mittelstaedt.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-emulation@freebsd.org List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 06:47:15 -0000 On 03/15/12 15:21, Ted Mittelstaedt wrote: > A number of FreeBSD kernel structures are dynamically created at > boot time - based on the amount of ram in the system. I would guess > if you boot your stripped BSD image on a virtual system with 64Mb of > ram you wouldn't see the kernel grow to 32MB So how do I find out how large the "kernel" is then in memory? And how did this conversation make it to emulation@? :) Actually, another question comes to mind: is it possible to limit how large the kernel structures grow? > > It would be interesting to see FreeBSD running on a Smartphone. Thats what I'm interested in for the long term, but not necessarily in this instance. This really has become an interesting thread... for every answer there are more questions- a hydra ;) > > Ted > > On 3/14/2012 9:03 PM, Super Bisquit wrote: >> On 3/14/12, Ted Mittelstaedt wrote: >>> What do you regard as a "low memory" machine? >> On real hardware I've used: >> HTC Apache 64/128 ROM/RAM >> Embedded 486 with 5M RAM >> Older tower maxed at 128M >> >> I'd say anything less than 64M RAM for normal hardware, less than 32 >> for embedded. >> >> Some systems do not have small memory modules. I have two SunBlade >> 1000s that can be stripped down to 128M. >> >> I'm also aware that the environment limits what the machine can have >> installed. >> >> There are older systems and embedded devices which run/ran on 16kb of >> RAM. I'm certain that the oldest electronic led calculators used even >> less memory. >> I digress. >> >> >> >> >>> >>> Ted >>> >>> On 3/13/2012 8:30 AM, Super Bisquit wrote: >>>> ---------- Forwarded message ---------- >>>> From: Da Rock<9Phackers@herveybayaustralia.com.au> >>>> Date: Tue, Mar 13, 2012 at 7:17 AM >>>> Subject: Re: Kernel memory usage >>>> To: freebsd-hackers@freebsd.org >>>> >>>> >>>> On 03/13/12 05:40, Super Bisquit wrote: >>>> >>>>> CPU architecture and model have a lot to do with performance. >>>>> You will also get different results if you used qemu in place of >>>>> VirtualBox. Qemu allows you to choose different emulated >>>>> architectures, CPUs, and machine bases. What's the downside? You have >>>>> to use the command line. >>>>> Install qemu and run a series of virtual machines. >>>>> Embedded devices also include Power(PC), ARMv?, Coldfire, et al; >>>>> you're only dealing with i386 and/or the 64 bit extension (AMD64). >>>>> CISC- which does not contain any hardware modification to be a RISC >>>>> replacement- runs fewer instructions than RISC due to the limited >>>>> number of registers. Take this into consideration every time a >>>>> program runs. >>>>> Everything else also matters on real and emulated systems: >>>>> Is it ide, scsi, sdd, flashdevice for the hard drive? >>>>> What type of RAM? >>>>> Dedicated or shared disk? >>>>> >>>> I'm a little confused by the response, I was interested if someone >>>> knew >>>> what determines the size of kernel in memory (or wired); I only >>>> considered >>>> the embedded list because they have a greater interest in the >>>> memory size >>>> working with so little. >>>> >>>> It is academic as I'm trying to understand the kernel internals, as >>>> well >>>> as >>>> understand what works with low memory so I can tune accordingly. I >>>> understand the different CPU instruction sets (roughly), although I >>>> would >>>> be interested as to the size of the kernel in each. >>>> >>>> What my question was about was the wired memory size and what makes it >>>> grow >>>> (to put it super simply :) ). I know some growth would be expected, >>>> but >>>> this seems obese; how would I find out how much memory a process >>>> structure >>>> takes? Or else what am I missing? >>>> >>>> That said I'll have a crack at what you suggest as that follows a >>>> whole >>>> new >>>> interesting tangent :) I have used qemu before, but found VBox a >>>> bit more >>>> responsive (and, I will admit, easier...) >>>> >>>> >>>>> On 3/11/12, Da >>>>> Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>> >>>>> >>>>> wrote: >>>>> >>>>>> I may be required to move this to embedded, but I am only looking >>>>>> for >>>>>> generalisation. >>>>>> >>>>>> Recently a thread came up on questions regarding memory usage, and a >>>>>> post was made regarding wired memory being nearly all kernel- >>>>>> something >>>>>> I was ready to dispute, but then I thought I'd better make sure. >>>>>> >>>>>> So I tested a few theories first off: >>>>>> >>>>>> 1. Comparing memory usage across machines >>>>>> >>>>>> I checked servers and desktops as well as vm's for memory usage, >>>>>> and I >>>>>> found some interesting results. On a firewall with no apps installed >>>>>> only 35M wired is used, on a desktop up to 700M~ can be used. >>>>>> Even as a >>>>>> dedicated server with a few services used it remains around 35M. >>>>>> >>>>>> Surely this means that the wired memory used is not just kernel? >>>>>> But I >>>>>> held off my assumptions as it was still plausible that the >>>>>> structures >>>>>> used by the kernel could balloon that far, too. >>>>>> >>>>>> 2. Stripped down, lean mean, kernel machine >>>>>> >>>>>> I then (using a vm I was building a kernel for anyway) stripped >>>>>> down a >>>>>> kernel in a VBox VM using le drivers for network to see what >>>>>> could be >>>>>> achieved. This is my kernel conf: >>>>>> >>>>>> include GENERIC >>>>>> ident VPN >>>>>> options IPSEC >>>>>> options IPSEC_DEBUG >>>>>> options IPSEC_NAT_T >>>>>> device crypto >>>>>> device enc >>>>>> >>>>>> # minimise kernel >>>>>> nooptions UFS_GJOURNAL >>>>>> nooptions MD_ROOT >>>>>> nooptions NFSCL >>>>>> nooptions NFSD >>>>>> nooptions NFSLOCKD >>>>>> nooptions NFS_ROOT >>>>>> nooptions MSDOSFS >>>>>> nooptions CD9660 >>>>>> nooptions PROCFS >>>>>> nooptions PSEUDOFS >>>>>> nodevice fdc >>>>>> nodevice mvs >>>>>> nodevice siis >>>>>> nodevice ahc >>>>>> nodevice ahd >>>>>> nodevice esp >>>>>> nodevice hptiop >>>>>> nodevice isp >>>>>> nodevice mpt >>>>>> nodevice mps >>>>>> nodevice sym >>>>>> nodevice trm >>>>>> nodevice adv >>>>>> nodevice adw >>>>>> nodevice aic >>>>>> nodevice bt >>>>>> nodevice ses >>>>>> nodevice amr >>>>>> nodevice arcmsr >>>>>> nodevice ciss >>>>>> nodevice dpt >>>>>> nodevice hptmv >>>>>> nodevice hptrr >>>>>> nodevice irr >>>>>> nodevice ips >>>>>> nodevice mly >>>>>> nodevice twa >>>>>> nodevice aac >>>>>> nodevice aacp >>>>>> nodevice ida >>>>>> nodevice mfi >>>>>> nodevice mlx >>>>>> nodevice twe >>>>>> nodevice tws >>>>>> nodevice splash >>>>>> nodevice cbb >>>>>> nodevice pccard >>>>>> nodevice cardbus >>>>>> nodevice uart >>>>>> nodevice ppc >>>>>> nodevice ppbus >>>>>> nodevice lpt >>>>>> nodevice plip >>>>>> nodevice ppi >>>>>> nodevice puc >>>>>> nodevice bxe >>>>>> nodevice de >>>>>> nodevice em >>>>>> nodevice igb >>>>>> nodevice ixgbe >>>>>> nodevice ti >>>>>> nodevice txp >>>>>> nodevice vx >>>>>> nodevice miibus >>>>>> nodevice ae >>>>>> nodevice age >>>>>> nodevice alc >>>>>> nodevice ale >>>>>> nodevice bce >>>>>> nodevice bfe >>>>>> nodevice bge >>>>>> nodevice dc >>>>>> nodevice et >>>>>> nodevice fxp >>>>>> nodevice jme >>>>>> nodevice lge >>>>>> nodevice msk >>>>>> nodevice nfe >>>>>> nodevice nge >>>>>> nodevice pcn >>>>>> nodevice re >>>>>> nodevice rl >>>>>> nodevice sf >>>>>> nodevice sge >>>>>> nodevice sis >>>>>> nodevice sk >>>>>> nodevice ste >>>>>> nodevice stge >>>>>> nodevice tl >>>>>> nodevice tx >>>>>> nodevice vge >>>>>> nodevice vr >>>>>> nodevice wb >>>>>> nodevice xl >>>>>> nodevice cs >>>>>> nodevice ed >>>>>> nodevice ex >>>>>> nodevice ep >>>>>> nodevice fe >>>>>> nodevice sn >>>>>> nodevice xe >>>>>> nodevice wlan >>>>>> nooptions IEEE80211_DEBUG >>>>>> nooptions IEEE80211_AMPDU_AGE >>>>>> nooptions IEEE80211_SUPPORT_MESH >>>>>> nodevice wlan_wep >>>>>> nodevice wlan_ccmp >>>>>> nodevice wlan_tkip >>>>>> nodevice wlan_amrr >>>>>> nodevice an >>>>>> nodevice ath >>>>>> nodevice ath_pci >>>>>> nodevice ath_hal >>>>>> nooptions AH_SUPPORT_AR5416 >>>>>> nodevice ath_rate_sample >>>>>> nodevice ipw >>>>>> nodevice iwi >>>>>> nodevice iwn >>>>>> nodevice malo >>>>>> nodevice mwl >>>>>> nodevice ral >>>>>> nodevice wi >>>>>> nodevice wpi >>>>>> nodevice md >>>>>> nooption USB_DEBUG >>>>>> nodevice uhci >>>>>> nodevice ohci >>>>>> nodevice ehci >>>>>> nodevice xhci >>>>>> nodevice usb >>>>>> nodevice uhid >>>>>> nodevice ukbd >>>>>> nodevice ulpt >>>>>> nodevice umass >>>>>> nodevice ums >>>>>> nodevice urio >>>>>> nodevice u3g >>>>>> nodevice uark >>>>>> nodevice ubsa >>>>>> nodevice uftdi >>>>>> nodevice uipaq >>>>>> nodevice uplcom >>>>>> nodevice uslcom >>>>>> nodevice uvisor >>>>>> nodevice uvscom >>>>>> nodevice aue >>>>>> nodevice axe >>>>>> nodevice cdce >>>>>> nodevice cue >>>>>> nodevice kue >>>>>> nodevice rue >>>>>> nodevice udav >>>>>> nodevice rum >>>>>> nodevice run >>>>>> nodevice uath >>>>>> nodevice upgt >>>>>> nodevice ural >>>>>> nodevice urtw >>>>>> nodevice zyd >>>>>> #nodevice firewire >>>>>> nodevice fwe >>>>>> nodevice fwip >>>>>> #nodevice dcons >>>>>> #nodevice dcons_rom >>>>>> nodevice sound >>>>>> nodevice snd_es137x >>>>>> nodevice snd_hda >>>>>> nodevice snd_ich >>>>>> nodevice snd_uaudio >>>>>> nodevice snd_via8233 >>>>>> >>>>>> World was also rebuilt as recommended by the handbook. As you can >>>>>> see I >>>>>> was rebuilding for IPSEC (for testing purposes only note). I >>>>>> couldn't >>>>>> remove dcons (not sure why- missing defined references), and that >>>>>> pulled >>>>>> in firewire too. >>>>>> >>>>>> The result was surprising: a 14M kernel became 6.3M, and when >>>>>> running I >>>>>> found it only used 19M used for wired (whoopee!) as opposed to >>>>>> 35M. No >>>>>> services were running per se, only the usual suspects in base: >>>>>> >>>>>> vpn-test# ps ax >>>>>> PID TT STAT TIME COMMAND >>>>>> 0 ?? DLs 0:00.11 [kernel] >>>>>> 1 ?? ILs 0:00.01 /sbin/init -- >>>>>> 2 ?? DL 0:00.00 [crypto] >>>>>> 3 ?? DL 0:00.00 [crypto returns] >>>>>> 4 ?? DL 0:00.00 [sctp_iterator] >>>>>> 5 ?? DL 0:00.00 [xpt_thrd] >>>>>> 6 ?? DL 0:00.10 [pagedaemon] >>>>>> 7 ?? DL 0:00.00 [vmdaemon] >>>>>> 8 ?? DL 0:00.01 [pagezero] >>>>>> 9 ?? DL 0:00.30 [bufdaemon] >>>>>> 10 ?? DL 0:00.00 [audit] >>>>>> 11 ?? RL 589:34.00 [idle] >>>>>> 12 ?? WL 0:38.64 [intr] >>>>>> 13 ?? DL 0:12.21 [geom] >>>>>> 14 ?? DL 0:03.30 [yarrow] >>>>>> 15 ?? DL 0:04.40 [syncer] >>>>>> 16 ?? DL 0:00.63 [vnlru] >>>>>> 17 ?? DL 0:00.53 [softdepflush] >>>>>> 104 ?? Is 0:00.00 adjkerntz -i >>>>>> 582 ?? Is 0:00.00 /sbin/devd >>>>>> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >>>>>> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >>>>>> /var/run/ntpd.pid >>>>>> 977 ?? Is 0:00.00 /usr/sbin/sshd >>>>>> 984 ?? Ss 0:00.81 sendmail: accepting connections >>>>>> (sendmail) >>>>>> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >>>>>> /var/spool/client >>>>>> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >>>>>> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >>>>>> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >>>>>> 1052 v0 Is 0:00.01 login [pam] (login) >>>>>> 1060 v0 I+ 0:00.02 -csh (csh) >>>>>> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >>>>>> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >>>>>> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >>>>>> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >>>>>> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >>>>>> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >>>>>> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >>>>>> 2065 0 Is 0:00.02 -csh (csh) >>>>>> 2068 0 I 0:00.01 su >>>>>> 2069 0 S 0:00.04 _su (csh) >>>>>> 2414 0 R+ 0:00.00 ps ax >>>>>> >>>>>> After some minutes though, the usage went up to 39M. WTF? >>>>>> >>>>>> So I'm now thoroughly confused. Google didn't really show up any >>>>>> real >>>>>> answers either. Aside from discovering the true nature of what was >>>>>> discussed in the posts, my hypothetical theorising is for my own >>>>>> academics as well; and I'm trying to slim down my kernels to see >>>>>> if I >>>>>> can improve performance with low memory systems. >>>>>> >>>>>> Can process structures cause this much ballooning? I find that >>>>>> hard to >>>>>> believe given not much is running here. My only other thought >>>>>> would be >>>>>> pipe or network structures? Anything I'm missing? >>>>>> >>>>>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can >>>>>> boot in >>>>>> seconds as opposed to minutes. Sweet! Although compiling clang took >>>>>> years... and gcc was built as well :/ >>>>>> >>>>>> Cheers >>>>>> ______________________________**_________________ >>>>>> freebsd-hackers@freebsd.org mailing list >>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>>> >>>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>>>> freebsd.org" >>>>>> >>>>>> ______________________________**_________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>> >>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>>> freebsd.org" >>>>> >>>> >>>> ______________________________**_________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>> >>>> To unsubscribe, send any mail to >>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>> >>>> I'm fowarding this thread in the event the individual, "da Rock" >>>> will be >>>> able to receive more help. >>>> _______________________________________________ >>>> freebsd-emulation@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation >>>> To unsubscribe, send any mail to >>>> "freebsd-emulation-unsubscribe@freebsd.org" >>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: >>>> 03/14/12 >>> >>> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: >> 03/14/12 > > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-emulation@FreeBSD.ORG Fri Mar 16 11:51:46 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BACA3106564A for ; Fri, 16 Mar 2012 11:51:46 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 41D408FC0C for ; Fri, 16 Mar 2012 11:51:46 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3893721bkc.13 for ; Fri, 16 Mar 2012 04:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=55IrNALTCTjKZ++eLkGOPaIC/92utSbemWEX+PHoxBc=; b=Sw00cwgc01RUTSCEIFfms89TP1TNHMVhA3xBu3NFOF3IsYb7vR/M/7K1t2qx5As+YX vyLwBaEaPxeb5xY4y1Q11ka4aw23nqZ+HrX+azE2OiBDYi9igFMn9ukNhPhIGQ5zMMr9 AlxmX2tH1/qujoTQv9AbjyzDHrqUwoyOudEe8UwYd2745Y6TUum/BvwnwTq05U6N01bX NW8oSdhw8ueY5OpBNFuCnK0n8c/P3Q9LrjpJ6Cg3nQ7kPDpMt85S9fhvQstMvLJI3+L9 KNCeVerSnnep//B4AzINtsJe4uu/aRsSvWK6m3R8ezr0Foaf7tVMdtM4u2Thn9dBcfhs 1fJA== Received: by 10.204.133.219 with SMTP id g27mr878177bkt.47.1331898705200; Fri, 16 Mar 2012 04:51:45 -0700 (PDT) Received: from green.tandem.local (246-212-92-178.pool.ukrtel.net. [178.92.212.246]) by mx.google.com with ESMTPS id h16sm9307591bkk.12.2012.03.16.04.51.42 (version=SSLv3 cipher=OTHER); Fri, 16 Mar 2012 04:51:43 -0700 (PDT) Message-ID: <4F63294C.8050309@gmail.com> Date: Fri, 16 Mar 2012 13:51:40 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: freebsd-emulation@FreeBSD.org References: <4F5E1C1D.2070204@gmail.com> In-Reply-To: <4F5E1C1D.2070204@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: emulators/virtualbox-ose fails to build after recent update (maybe devel/dev86 lockup) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 11:51:46 -0000 Volodymyr Kostyrko wrote: > Maybe not directly related to recent update though... > > # uname -a > FreeBSD limbo.lan 9.0-STABLE FreeBSD 9.0-STABLE #0 r232716: Fri Mar 9 > 22:38:03 EET 2012 arcade@limbo.lan:/usr/obj/usr/src/sys/MINIMALx32 i386 > > World and ports built with clang. > > When building port everything stop after: > > kBuild: Compiling PcBiosBin - > /tmp/ports/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.x86/release/obj/PcBiosBin/rombios1.s That's surely dev86 lockup. as86 hangs on i386 if compiled with clang and works if compiled with gcc46 / stock gcc. -- Sphinx of black quartz judge my vow. From owner-freebsd-emulation@FreeBSD.ORG Fri Mar 16 12:34:52 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DF54106566B; Fri, 16 Mar 2012 12:34:52 +0000 (UTC) (envelope-from sanpei@sanpei.org) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id D5B728FC0C; Fri, 16 Mar 2012 12:34:51 +0000 (UTC) Received: from cherry2.sanpei.org (j069113.ppp.asahi-net.or.jp [61.213.69.113]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id A1B3513686E; Fri, 16 Mar 2012 21:34:44 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by cherry2.sanpei.org (8.14.4/8.14.3) with ESMTP id q2GCYfCm005261; Fri, 16 Mar 2012 21:34:42 +0900 (JST) (envelope-from sanpei@sanpei.org) Date: Fri, 16 Mar 2012 21:34:41 +0900 (JST) Message-Id: <20120316.213441.1551145784576134237.sanpei@sanpei.org> To: flo@freebsd.org From: MIHIRA Sanpei Yoshiro In-Reply-To: <4F6097DF.8000400@freebsd.org> References: <20120304184529.GA57370@psconsult.nl> <20120314.215908.1291465837804728646.sanpei@sanpei.org> <4F6097DF.8000400@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (cherry2.sanpei.org [127.0.0.1]); Fri, 16 Mar 2012 21:34:44 +0900 (JST) Cc: freebsd-net@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:34:52 -0000 Hi, Thank you for your information. Now I can use both VirtualBox and WI-FI HOSTAP mode. I refered below URL for TAP setup. http://forums.freebsd.org/showthread.php?t=7153 1. load kernel modules kldload /boot/kernel/if_bridge.ko kldload /boot/kernel/if_tap.ko 2. setup tap interface sysctl net.link.tap.user_open=1 chown root:vboxusers /dev/tap0 chmod 660 /dev/tap0 3. create tap interface and bridge interface - I use bridge1 for tap, because I use bridge0 for WI-FI HOSTAP - net0 is for my ehternet network ifconfig bridge1 create ifconfig bridge1 addm net0 ifconfig tap0 192.168.1.111 netmask 255.255.255.0 ifconfig bridge1 addm tap0 ifconfig bridge1 up 4. start virtualbox and change bridge adapter to tap0 5. enable WI-FI with src/tools/tools/net80211/scripts/setup.wpa2 / Florian >On 14.03.2012 13:59, MIHIRA Sanpei Yoshiro wrote: >> Hi, >> >> I also have this problem. >> My environment is below >> - FreeBSD-8.2-RELEASE/amd64 and FreeBSD-10-current/i386 >> - Virtualbox 4.0.14(now I'm compiling new version 4.1.8) >> - WI-FI HOSTAP mode(if_bridge) >> >> I hope to use both function(VirtualBox and if_bridge) at same. >> Please let us to know the appropriate settings. >> >>> I just noticed that when running Virtualbox 4.1.8 with a bridged >>> network >>> interface, I loose connectivity to another virtual host running in >>> qemu >>> whose network interface is bridged to my ethernet interface. After >>> stopping the Virtualbox instance, I regain connection to the virtual >>> host under qemu. Ifconfig doesn't give a clue. Has anyone seen >>> this >>> behaviour or, even better, have a solution? >> > >What i did was create another tap interface add that to the bridge >and configure VirtualBox to use the tap interface. Seems to work for >me. From owner-freebsd-emulation@FreeBSD.ORG Fri Mar 16 14:04:12 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F0A910656D0; Fri, 16 Mar 2012 14:04:12 +0000 (UTC) (envelope-from sanpei@sanpei.org) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 25C948FC16; Fri, 16 Mar 2012 14:04:11 +0000 (UTC) Received: from cherry2.sanpei.org (j069113.ppp.asahi-net.or.jp [61.213.69.113]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 855B3134B61; Fri, 16 Mar 2012 23:04:09 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by cherry2.sanpei.org (8.14.4/8.14.3) with ESMTP id q2GE45RX006431; Fri, 16 Mar 2012 23:04:05 +0900 (JST) (envelope-from sanpei@sanpei.org) Date: Fri, 16 Mar 2012 23:04:04 +0900 (JST) Message-Id: <20120316.230404.1590768603250781725.sanpei@sanpei.org> To: flo@freebsd.org From: MIHIRA Sanpei Yoshiro In-Reply-To: <4F6097DF.8000400@freebsd.org> References: <20120304184529.GA57370@psconsult.nl> <20120314.215908.1291465837804728646.sanpei@sanpei.org> <4F6097DF.8000400@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (cherry2.sanpei.org [127.0.0.1]); Fri, 16 Mar 2012 23:04:09 +0900 (JST) Cc: freebsd-net@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:04:12 -0000 Hi, Thank you for your information. I mistake bridge interface settings. I use only one bridge interface(bridge0) and add ethernet, wi-fi and tap interfaces. Now I can use both VirtualBox and WI-FI HOSTAP mode. I refered below URL for TAP setup. http://forums.freebsd.org/showthread.php?t=7153 1. load kernel modules kldload /boot/kernel/if_bridge.ko kldload /boot/kernel/if_tap.ko 2. setup tap interface sysctl net.link.tap.user_open=1 chown root:vboxusers /dev/tap0 chmod 660 /dev/tap0 3. create tap interface and bridge interface - wlan0 is for WI-FI interface - net0 is for my ehternet network ifconfig bridge0 create ifconfig bridge0 addm net0 ifconfig tap0 192.168.1.111 netmask 255.255.255.0 ifconfig bridge0 addm tap0 ifconfig bridge0 addm wlan0 ifconfig bridge0 up 4. start virtualbox and change bridge adapter to tap0 5. enable WI-FI with src/tools/tools/net80211/scripts/setup.wpa2 / Florian >On 14.03.2012 13:59, MIHIRA Sanpei Yoshiro wrote: >> Hi, >> >> I also have this problem. >> My environment is below >> - FreeBSD-8.2-RELEASE/amd64 and FreeBSD-10-current/i386 >> - Virtualbox 4.0.14(now I'm compiling new version 4.1.8) >> - WI-FI HOSTAP mode(if_bridge) >> >> I hope to use both function(VirtualBox and if_bridge) at same. >> Please let us to know the appropriate settings. >> >>> I just noticed that when running Virtualbox 4.1.8 with a bridged >>> network >>> interface, I loose connectivity to another virtual host running in >>> qemu >>> whose network interface is bridged to my ethernet interface. After >>> stopping the Virtualbox instance, I regain connection to the virtual >>> host under qemu. Ifconfig doesn't give a clue. Has anyone seen >>> this >>> behaviour or, even better, have a solution? >> > >What i did was create another tap interface add that to the bridge >and configure VirtualBox to use the tap interface. Seems to work for >me. From owner-freebsd-emulation@FreeBSD.ORG Fri Mar 16 19:45:47 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7C40106566B; Fri, 16 Mar 2012 19:45:47 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 92E848FC12; Fri, 16 Mar 2012 19:45:47 +0000 (UTC) Received: by dald2 with SMTP id d2so6936124dal.13 for ; Fri, 16 Mar 2012 12:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3yHdZIKZiFFJkka9idPNDKeI2vJ1K1I8zNmmbLyLTWU=; b=xYM6I3aSzw86eRnzU7EllGVg8y07QoogD8OJkarAhrvpV8i5RneWEcowtMGqpaugGt 0Zv/zr8QG7hZuBAnBVe1IhwozkpianpHFYG0s/fHp0WGZFawr5OKfzSrQYU2jV2BmHYb y4Ge/f20JErn68+9mi8JXSz0+xJa86YzM0vDG1tEVZNbHu/zo2rymIb2e3K2jP+HDH1W XQ0WugfBEb26L4SB8DIQUNWY3E5t29gCZiwvWG1cmHmkbGq1V8NTh0xc0DI/rWW6WodE 1O91s2/Os7vEGF6C0sC7LiwSeazJFADdvmEPmv9HQtg3coMqdT0BlK8o+mduIPE9xaWi JxBA== MIME-Version: 1.0 Received: by 10.68.201.6 with SMTP id jw6mr10970489pbc.92.1331927147153; Fri, 16 Mar 2012 12:45:47 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Fri, 16 Mar 2012 12:45:47 -0700 (PDT) Date: Fri, 16 Mar 2012 15:45:47 -0400 Message-ID: From: Super Bisquit To: freebsd-emulation@freebsd.org, powerpc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ELF header adjusting X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 19:45:48 -0000 "Okay, what in the hell is he trying to do now?" The answer to your question is: I've looked at the header file for the bin/java and bin/java_vm in the ibm powerpc java binaries. There is a reference to /lib/ld.so.1 in a Linux installation which is very similar to /usr/libexec/ld-elf.so.1 in a FreeBSD installation. chipchop# pwd /tmp/install.dir.53010/Linux/resource/jre/bin chipchop# ls ControlPanel ikeyman java_vm jcontrol keytool ktab rmid unpack200 classic j9vm javaw jdmpview kinit pack200 rmiregistry ikeycmd java javaws jextract klist policytool tnameserv chipchop# elfedit --input-osabi=FreeBSD --output-osabi=FreeBSD java elfedit: Error: java: Unmatched EI_OSABI: 0 is not 9 chipchop# elfedit --input-osabi=FreeBSD --output-osabi=FreeBSD java_vm elfedit: Error: java_vm: Unmatched EI_OSABI: 0 is not 9 chipchop# elfedit --output-osabi=FreeBSD java_vm chipchop# elfedit --output-osabi=FreeBSD java chipchop# If in doubt about my finding for similarities between /lib/ld.so.1 and /usr/lbexec/ld-elf.so.1 then open the former with nano orvi and the latter with vi to see the headers. From owner-freebsd-emulation@FreeBSD.ORG Sat Mar 17 03:51:31 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01ED9106564A; Sat, 17 Mar 2012 03:51:31 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id C4C698FC18; Sat, 17 Mar 2012 03:51:30 +0000 (UTC) Received: by dald2 with SMTP id d2so7456528dal.13 for ; Fri, 16 Mar 2012 20:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lT6xrQS5NF96k5U4fZYkbFidn4Ja/eq/LhQQpvHifmI=; b=B/tXQoxY+xyCNdTKGkAfFb8p0LmsrSwmpE9WA0On7xIbfbTdHtcM2n8HeUc3MGsdT/ 9NHHc3hcEFRM8C000IGwUx6RheyZH6s12AtAJf2THvKBdmVp129Y4IjBCNi/3nbggomV tUKtlSHUmjDVnN2JM/qVjtr9aDYkVxmYN0M5UPNXVSYtmP7+6oieRT6hz484m9Zu4p7Q 12qG0l7YxseBR0Er5fF6wPRqh4E/DJrKqV9UM8i5MkMsStOIUSdcx+aztXzFHJB/e1ok LW1yh7Pv01hOG6vfug0TrV2THqrLlQEktNcURVxUiuFYd60UIlrsX/2993ZrnqYcMgMX 5jIg== MIME-Version: 1.0 Received: by 10.68.125.135 with SMTP id mq7mr11016764pbb.155.1331956290459; Fri, 16 Mar 2012 20:51:30 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Fri, 16 Mar 2012 20:51:30 -0700 (PDT) In-Reply-To: <20120316155901.77ca48ee@kan.dyndns.org> References: <20120316155901.77ca48ee@kan.dyndns.org> Date: Fri, 16 Mar 2012 23:51:30 -0400 Message-ID: From: Super Bisquit To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org, FreeBSD PowerPC ML Subject: Re: ELF header adjusting X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 03:51:31 -0000 On Fri, Mar 16, 2012 at 3:59 PM, Alexander Kabaev wrote: > On Fri, 16 Mar 2012 15:45:47 -0400 > Super Bisquit wrote: > > > "Okay, what in the hell is he trying to do now?" > > The answer to your question is: > > I've looked at the header file for the bin/java and bin/java_vm in > > the ibm powerpc java binaries. There is a reference to /lib/ld.so.1 > > in a Linux installation which is very similar > > to /usr/libexec/ld-elf.so.1 in a FreeBSD installation. > > > > chipchop# pwd > > /tmp/install.dir.53010/Linux/resource/jre/bin > > chipchop# ls > > ControlPanel ikeyman java_vm jcontrol keytool > > ktab rmid unpack200 > > classic j9vm javaw jdmpview kinit > > pack200 rmiregistry > > ikeycmd java javaws jextract klist > > policytool tnameserv > > chipchop# elfedit --input-osabi=FreeBSD --output-osabi=FreeBSD java > > elfedit: Error: java: Unmatched EI_OSABI: 0 is not 9 > > chipchop# elfedit --input-osabi=FreeBSD --output-osabi=FreeBSD java_vm > > elfedit: Error: java_vm: Unmatched EI_OSABI: 0 is not 9 > > chipchop# elfedit --output-osabi=FreeBSD java_vm > > chipchop# elfedit --output-osabi=FreeBSD java > > chipchop# > > > > If in doubt about my finding for similarities between /lib/ld.so.1 and > > /usr/lbexec/ld-elf.so.1 then open the former with nano orvi and the > > latter with vi to see the headers. > > Would it be a much of a shock to discover that two export largely > intersecting list of functions, both being ELF loaders? Would rewriting the header to use the FreeBSD equivalent to the Linux ones possibly work? Ignore - for the moment- the reference to ld-elf.so.1. /usr/lib/ld.so.1 FreeBSD /lib/ld.so.1 Linux. (I did a re-search)Both serve the same purpose. The binaries are obviously checking for the Linux path. > > Sadly, you > provide no answer to the question you yourself ask on the very first > line of own messages, so the point of your message is somewhat unclear > to me still. > > -- > Alexander Kabaev > Has anyone reported anything on changing the called for libraries and such in the file to use the FreeBSD path instead? From owner-freebsd-emulation@FreeBSD.ORG Sat Mar 17 06:22:05 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7861E106566C for ; Sat, 17 Mar 2012 06:22:05 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (unknown [IPv6:2607:fa80:40::6]) by mx1.freebsd.org (Postfix) with ESMTP id A4B158FC08 for ; Sat, 17 Mar 2012 06:22:04 +0000 (UTC) Received: from [192.168.1.10] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) (authenticated bits=0) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id q2H6LkCx026320 for ; Fri, 16 Mar 2012 23:21:56 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4F642D63.10600@mittelstaedt.us> Date: Fri, 16 Mar 2012 23:21:23 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0) Gecko/20110929 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> <4F615D09.8030009@mittelstaedt.us> <4F617C63.9030106@mittelstaedt.us> <4F618F2B.7040709@herveybayaustralia.com.au> In-Reply-To: <4F618F2B.7040709@herveybayaustralia.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Subject: Re: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 06:22:05 -0000 On 3/14/2012 11:41 PM, Da Rock wrote: > On 03/15/12 15:21, Ted Mittelstaedt wrote: >> A number of FreeBSD kernel structures are dynamically created at >> boot time - based on the amount of ram in the system. I would guess >> if you boot your stripped BSD image on a virtual system with 64Mb of >> ram you wouldn't see the kernel grow to 32MB > So how do I find out how large the "kernel" is then in memory? Boot it! From: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html "...The variable kern.maxusers is automatically sized at boot based on the amount of memory available in the system, and may be determined at run-time by inspecting the value of the read-only kern.maxusers sysctl..." A whole bunch of kernel parameters are calculated at boot based on this figure. Those make the kernel bigger or smaller. As to how "large" it is, the file descriptors, clusters and so on that are calculated at boot are considered part of the kernel from a memory standpoint. And how > did this conversation make it to emulation@? :) > beats me. > Actually, another question comes to mind: is it possible to limit how > large the kernel structures grow? The handbook seems to imply that once they are all setup the kernel doesn't grow. >> >> It would be interesting to see FreeBSD running on a Smartphone. > Thats what I'm interested in for the long term, but not necessarily in > this instance. This really has become an interesting thread... for every > answer there are more questions- a hydra ;) Heh. Ted >> >> Ted >> >> On 3/14/2012 9:03 PM, Super Bisquit wrote: >>> On 3/14/12, Ted Mittelstaedt wrote: >>>> What do you regard as a "low memory" machine? >>> On real hardware I've used: >>> HTC Apache 64/128 ROM/RAM >>> Embedded 486 with 5M RAM >>> Older tower maxed at 128M >>> >>> I'd say anything less than 64M RAM for normal hardware, less than 32 >>> for embedded. >>> >>> Some systems do not have small memory modules. I have two SunBlade >>> 1000s that can be stripped down to 128M. >>> >>> I'm also aware that the environment limits what the machine can have >>> installed. >>> >>> There are older systems and embedded devices which run/ran on 16kb of >>> RAM. I'm certain that the oldest electronic led calculators used even >>> less memory. >>> I digress. >>> >>> >>> >>> >>>> >>>> Ted >>>> >>>> On 3/13/2012 8:30 AM, Super Bisquit wrote: >>>>> ---------- Forwarded message ---------- >>>>> From: Da Rock<9Phackers@herveybayaustralia.com.au> >>>>> Date: Tue, Mar 13, 2012 at 7:17 AM >>>>> Subject: Re: Kernel memory usage >>>>> To: freebsd-hackers@freebsd.org >>>>> >>>>> >>>>> On 03/13/12 05:40, Super Bisquit wrote: >>>>> >>>>>> CPU architecture and model have a lot to do with performance. >>>>>> You will also get different results if you used qemu in place of >>>>>> VirtualBox. Qemu allows you to choose different emulated >>>>>> architectures, CPUs, and machine bases. What's the downside? You have >>>>>> to use the command line. >>>>>> Install qemu and run a series of virtual machines. >>>>>> Embedded devices also include Power(PC), ARMv?, Coldfire, et al; >>>>>> you're only dealing with i386 and/or the 64 bit extension (AMD64). >>>>>> CISC- which does not contain any hardware modification to be a RISC >>>>>> replacement- runs fewer instructions than RISC due to the limited >>>>>> number of registers. Take this into consideration every time a >>>>>> program runs. >>>>>> Everything else also matters on real and emulated systems: >>>>>> Is it ide, scsi, sdd, flashdevice for the hard drive? >>>>>> What type of RAM? >>>>>> Dedicated or shared disk? >>>>>> >>>>> I'm a little confused by the response, I was interested if someone >>>>> knew >>>>> what determines the size of kernel in memory (or wired); I only >>>>> considered >>>>> the embedded list because they have a greater interest in the >>>>> memory size >>>>> working with so little. >>>>> >>>>> It is academic as I'm trying to understand the kernel internals, as >>>>> well >>>>> as >>>>> understand what works with low memory so I can tune accordingly. I >>>>> understand the different CPU instruction sets (roughly), although I >>>>> would >>>>> be interested as to the size of the kernel in each. >>>>> >>>>> What my question was about was the wired memory size and what makes it >>>>> grow >>>>> (to put it super simply :) ). I know some growth would be expected, >>>>> but >>>>> this seems obese; how would I find out how much memory a process >>>>> structure >>>>> takes? Or else what am I missing? >>>>> >>>>> That said I'll have a crack at what you suggest as that follows a >>>>> whole >>>>> new >>>>> interesting tangent :) I have used qemu before, but found VBox a >>>>> bit more >>>>> responsive (and, I will admit, easier...) >>>>> >>>>> >>>>>> On 3/11/12, Da >>>>>> Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>> >>>>>> >>>>>> wrote: >>>>>> >>>>>>> I may be required to move this to embedded, but I am only looking >>>>>>> for >>>>>>> generalisation. >>>>>>> >>>>>>> Recently a thread came up on questions regarding memory usage, and a >>>>>>> post was made regarding wired memory being nearly all kernel- >>>>>>> something >>>>>>> I was ready to dispute, but then I thought I'd better make sure. >>>>>>> >>>>>>> So I tested a few theories first off: >>>>>>> >>>>>>> 1. Comparing memory usage across machines >>>>>>> >>>>>>> I checked servers and desktops as well as vm's for memory usage, >>>>>>> and I >>>>>>> found some interesting results. On a firewall with no apps installed >>>>>>> only 35M wired is used, on a desktop up to 700M~ can be used. >>>>>>> Even as a >>>>>>> dedicated server with a few services used it remains around 35M. >>>>>>> >>>>>>> Surely this means that the wired memory used is not just kernel? >>>>>>> But I >>>>>>> held off my assumptions as it was still plausible that the >>>>>>> structures >>>>>>> used by the kernel could balloon that far, too. >>>>>>> >>>>>>> 2. Stripped down, lean mean, kernel machine >>>>>>> >>>>>>> I then (using a vm I was building a kernel for anyway) stripped >>>>>>> down a >>>>>>> kernel in a VBox VM using le drivers for network to see what >>>>>>> could be >>>>>>> achieved. This is my kernel conf: >>>>>>> >>>>>>> include GENERIC >>>>>>> ident VPN >>>>>>> options IPSEC >>>>>>> options IPSEC_DEBUG >>>>>>> options IPSEC_NAT_T >>>>>>> device crypto >>>>>>> device enc >>>>>>> >>>>>>> # minimise kernel >>>>>>> nooptions UFS_GJOURNAL >>>>>>> nooptions MD_ROOT >>>>>>> nooptions NFSCL >>>>>>> nooptions NFSD >>>>>>> nooptions NFSLOCKD >>>>>>> nooptions NFS_ROOT >>>>>>> nooptions MSDOSFS >>>>>>> nooptions CD9660 >>>>>>> nooptions PROCFS >>>>>>> nooptions PSEUDOFS >>>>>>> nodevice fdc >>>>>>> nodevice mvs >>>>>>> nodevice siis >>>>>>> nodevice ahc >>>>>>> nodevice ahd >>>>>>> nodevice esp >>>>>>> nodevice hptiop >>>>>>> nodevice isp >>>>>>> nodevice mpt >>>>>>> nodevice mps >>>>>>> nodevice sym >>>>>>> nodevice trm >>>>>>> nodevice adv >>>>>>> nodevice adw >>>>>>> nodevice aic >>>>>>> nodevice bt >>>>>>> nodevice ses >>>>>>> nodevice amr >>>>>>> nodevice arcmsr >>>>>>> nodevice ciss >>>>>>> nodevice dpt >>>>>>> nodevice hptmv >>>>>>> nodevice hptrr >>>>>>> nodevice irr >>>>>>> nodevice ips >>>>>>> nodevice mly >>>>>>> nodevice twa >>>>>>> nodevice aac >>>>>>> nodevice aacp >>>>>>> nodevice ida >>>>>>> nodevice mfi >>>>>>> nodevice mlx >>>>>>> nodevice twe >>>>>>> nodevice tws >>>>>>> nodevice splash >>>>>>> nodevice cbb >>>>>>> nodevice pccard >>>>>>> nodevice cardbus >>>>>>> nodevice uart >>>>>>> nodevice ppc >>>>>>> nodevice ppbus >>>>>>> nodevice lpt >>>>>>> nodevice plip >>>>>>> nodevice ppi >>>>>>> nodevice puc >>>>>>> nodevice bxe >>>>>>> nodevice de >>>>>>> nodevice em >>>>>>> nodevice igb >>>>>>> nodevice ixgbe >>>>>>> nodevice ti >>>>>>> nodevice txp >>>>>>> nodevice vx >>>>>>> nodevice miibus >>>>>>> nodevice ae >>>>>>> nodevice age >>>>>>> nodevice alc >>>>>>> nodevice ale >>>>>>> nodevice bce >>>>>>> nodevice bfe >>>>>>> nodevice bge >>>>>>> nodevice dc >>>>>>> nodevice et >>>>>>> nodevice fxp >>>>>>> nodevice jme >>>>>>> nodevice lge >>>>>>> nodevice msk >>>>>>> nodevice nfe >>>>>>> nodevice nge >>>>>>> nodevice pcn >>>>>>> nodevice re >>>>>>> nodevice rl >>>>>>> nodevice sf >>>>>>> nodevice sge >>>>>>> nodevice sis >>>>>>> nodevice sk >>>>>>> nodevice ste >>>>>>> nodevice stge >>>>>>> nodevice tl >>>>>>> nodevice tx >>>>>>> nodevice vge >>>>>>> nodevice vr >>>>>>> nodevice wb >>>>>>> nodevice xl >>>>>>> nodevice cs >>>>>>> nodevice ed >>>>>>> nodevice ex >>>>>>> nodevice ep >>>>>>> nodevice fe >>>>>>> nodevice sn >>>>>>> nodevice xe >>>>>>> nodevice wlan >>>>>>> nooptions IEEE80211_DEBUG >>>>>>> nooptions IEEE80211_AMPDU_AGE >>>>>>> nooptions IEEE80211_SUPPORT_MESH >>>>>>> nodevice wlan_wep >>>>>>> nodevice wlan_ccmp >>>>>>> nodevice wlan_tkip >>>>>>> nodevice wlan_amrr >>>>>>> nodevice an >>>>>>> nodevice ath >>>>>>> nodevice ath_pci >>>>>>> nodevice ath_hal >>>>>>> nooptions AH_SUPPORT_AR5416 >>>>>>> nodevice ath_rate_sample >>>>>>> nodevice ipw >>>>>>> nodevice iwi >>>>>>> nodevice iwn >>>>>>> nodevice malo >>>>>>> nodevice mwl >>>>>>> nodevice ral >>>>>>> nodevice wi >>>>>>> nodevice wpi >>>>>>> nodevice md >>>>>>> nooption USB_DEBUG >>>>>>> nodevice uhci >>>>>>> nodevice ohci >>>>>>> nodevice ehci >>>>>>> nodevice xhci >>>>>>> nodevice usb >>>>>>> nodevice uhid >>>>>>> nodevice ukbd >>>>>>> nodevice ulpt >>>>>>> nodevice umass >>>>>>> nodevice ums >>>>>>> nodevice urio >>>>>>> nodevice u3g >>>>>>> nodevice uark >>>>>>> nodevice ubsa >>>>>>> nodevice uftdi >>>>>>> nodevice uipaq >>>>>>> nodevice uplcom >>>>>>> nodevice uslcom >>>>>>> nodevice uvisor >>>>>>> nodevice uvscom >>>>>>> nodevice aue >>>>>>> nodevice axe >>>>>>> nodevice cdce >>>>>>> nodevice cue >>>>>>> nodevice kue >>>>>>> nodevice rue >>>>>>> nodevice udav >>>>>>> nodevice rum >>>>>>> nodevice run >>>>>>> nodevice uath >>>>>>> nodevice upgt >>>>>>> nodevice ural >>>>>>> nodevice urtw >>>>>>> nodevice zyd >>>>>>> #nodevice firewire >>>>>>> nodevice fwe >>>>>>> nodevice fwip >>>>>>> #nodevice dcons >>>>>>> #nodevice dcons_rom >>>>>>> nodevice sound >>>>>>> nodevice snd_es137x >>>>>>> nodevice snd_hda >>>>>>> nodevice snd_ich >>>>>>> nodevice snd_uaudio >>>>>>> nodevice snd_via8233 >>>>>>> >>>>>>> World was also rebuilt as recommended by the handbook. As you can >>>>>>> see I >>>>>>> was rebuilding for IPSEC (for testing purposes only note). I >>>>>>> couldn't >>>>>>> remove dcons (not sure why- missing defined references), and that >>>>>>> pulled >>>>>>> in firewire too. >>>>>>> >>>>>>> The result was surprising: a 14M kernel became 6.3M, and when >>>>>>> running I >>>>>>> found it only used 19M used for wired (whoopee!) as opposed to >>>>>>> 35M. No >>>>>>> services were running per se, only the usual suspects in base: >>>>>>> >>>>>>> vpn-test# ps ax >>>>>>> PID TT STAT TIME COMMAND >>>>>>> 0 ?? DLs 0:00.11 [kernel] >>>>>>> 1 ?? ILs 0:00.01 /sbin/init -- >>>>>>> 2 ?? DL 0:00.00 [crypto] >>>>>>> 3 ?? DL 0:00.00 [crypto returns] >>>>>>> 4 ?? DL 0:00.00 [sctp_iterator] >>>>>>> 5 ?? DL 0:00.00 [xpt_thrd] >>>>>>> 6 ?? DL 0:00.10 [pagedaemon] >>>>>>> 7 ?? DL 0:00.00 [vmdaemon] >>>>>>> 8 ?? DL 0:00.01 [pagezero] >>>>>>> 9 ?? DL 0:00.30 [bufdaemon] >>>>>>> 10 ?? DL 0:00.00 [audit] >>>>>>> 11 ?? RL 589:34.00 [idle] >>>>>>> 12 ?? WL 0:38.64 [intr] >>>>>>> 13 ?? DL 0:12.21 [geom] >>>>>>> 14 ?? DL 0:03.30 [yarrow] >>>>>>> 15 ?? DL 0:04.40 [syncer] >>>>>>> 16 ?? DL 0:00.63 [vnlru] >>>>>>> 17 ?? DL 0:00.53 [softdepflush] >>>>>>> 104 ?? Is 0:00.00 adjkerntz -i >>>>>>> 582 ?? Is 0:00.00 /sbin/devd >>>>>>> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >>>>>>> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >>>>>>> /var/run/ntpd.pid >>>>>>> 977 ?? Is 0:00.00 /usr/sbin/sshd >>>>>>> 984 ?? Ss 0:00.81 sendmail: accepting connections (sendmail) >>>>>>> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >>>>>>> /var/spool/client >>>>>>> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >>>>>>> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >>>>>>> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >>>>>>> 1052 v0 Is 0:00.01 login [pam] (login) >>>>>>> 1060 v0 I+ 0:00.02 -csh (csh) >>>>>>> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >>>>>>> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >>>>>>> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >>>>>>> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >>>>>>> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >>>>>>> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >>>>>>> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >>>>>>> 2065 0 Is 0:00.02 -csh (csh) >>>>>>> 2068 0 I 0:00.01 su >>>>>>> 2069 0 S 0:00.04 _su (csh) >>>>>>> 2414 0 R+ 0:00.00 ps ax >>>>>>> >>>>>>> After some minutes though, the usage went up to 39M. WTF? >>>>>>> >>>>>>> So I'm now thoroughly confused. Google didn't really show up any >>>>>>> real >>>>>>> answers either. Aside from discovering the true nature of what was >>>>>>> discussed in the posts, my hypothetical theorising is for my own >>>>>>> academics as well; and I'm trying to slim down my kernels to see >>>>>>> if I >>>>>>> can improve performance with low memory systems. >>>>>>> >>>>>>> Can process structures cause this much ballooning? I find that >>>>>>> hard to >>>>>>> believe given not much is running here. My only other thought >>>>>>> would be >>>>>>> pipe or network structures? Anything I'm missing? >>>>>>> >>>>>>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can >>>>>>> boot in >>>>>>> seconds as opposed to minutes. Sweet! Although compiling clang took >>>>>>> years... and gcc was built as well :/ >>>>>>> >>>>>>> Cheers >>>>>>> ______________________________**_________________ >>>>>>> freebsd-hackers@freebsd.org mailing list >>>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>>>> >>>>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>>>>> freebsd.org" >>>>>>> >>>>>>> ______________________________**_________________ >>>>>> freebsd-hackers@freebsd.org mailing list >>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>>> >>>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** >>>>>> freebsd.org" >>>>>> >>>>> >>>>> ______________________________**_________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers >>>>> >>>>> To unsubscribe, send any mail to >>>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>>> >>>>> I'm fowarding this thread in the event the individual, "da Rock" >>>>> will be >>>>> able to receive more help. >>>>> _______________________________________________ >>>>> freebsd-emulation@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation >>>>> To unsubscribe, send any mail to >>>>> "freebsd-emulation-unsubscribe@freebsd.org" >>>>> >>>>> >>>>> ----- >>>>> No virus found in this message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: >>>>> 03/14/12 >>>> >>>> >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: >>> 03/14/12 >> >> _______________________________________________ >> freebsd-emulation@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation >> To unsubscribe, send any mail to >> "freebsd-emulation-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org" > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2114/4875 - Release Date: 03/16/12 From owner-freebsd-emulation@FreeBSD.ORG Sat Mar 17 14:26:07 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 605A1106564A; Sat, 17 Mar 2012 14:26:07 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DFF308FC0C; Sat, 17 Mar 2012 14:26:06 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so514321pbc.13 for ; Sat, 17 Mar 2012 07:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oE0CGy4ZuFfMYMuu9/ZDxc/7mFbXldAcG8fZx1alAgk=; b=Oolihk7lszTHIvVnFmZGOazGltzf44/a8PrnLehjEloSb5Id7Q/9kCEKBa7CoqRkvb rXWbKg442mOu6Gk4xz6bvtt4tu/9Ikrbi2ulfJsWxg83h0ErB0jPRVBsKbGfkPTJ6uei V9euw9OlGbcvXbBYYzLV/v1BOhYhJhKzkUhtxAUOgvoo/Uj7YI4ZzEOizwfHyvNYzqJl AmrfrE24fUIpgCJzg2MidSb2QhgrfVDJBduaSrNqLwoLpDpe+4/PTbQHJdY7ZZ0vKRD2 dTQ+oWWVGZEZx93QZpexsLSOEAKeRNgHUkpU17PbIKYFE1Hnq19VfmYRhJptYYXA87ig yuhQ== MIME-Version: 1.0 Received: by 10.68.132.41 with SMTP id or9mr24239403pbb.8.1331994366464; Sat, 17 Mar 2012 07:26:06 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Sat, 17 Mar 2012 07:26:06 -0700 (PDT) In-Reply-To: <20120317091952.2e8c4fcf@kan.dyndns.org> References: <20120316155901.77ca48ee@kan.dyndns.org> <20120317091952.2e8c4fcf@kan.dyndns.org> Date: Sat, 17 Mar 2012 10:26:06 -0400 Message-ID: From: Super Bisquit To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org, FreeBSD PowerPC ML Subject: Re: ELF header adjusting X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 14:26:07 -0000 On Sat, Mar 17, 2012 at 9:19 AM, Alexander Kabaev wrote: > On Fri, 16 Mar 2012 23:51:30 -0400 > Super Bisquit wrote: > > > On Fri, Mar 16, 2012 at 3:59 PM, Alexander Kabaev > > wrote: > > > > > On Fri, 16 Mar 2012 15:45:47 -0400 > > > Super Bisquit wrote: > > > > > > > "Okay, what in the hell is he trying to do now?" > > > > The answer to your question is: > > > > I've looked at the header file for the bin/java and bin/java_vm in > > > > the ibm powerpc java binaries. There is a reference > > > > to /lib/ld.so.1 in a Linux installation which is very similar > > > > to /usr/libexec/ld-elf.so.1 in a FreeBSD installation. > > > > > > > > chipchop# pwd > > > > /tmp/install.dir.53010/Linux/resource/jre/bin > > > > chipchop# ls > > > > ControlPanel ikeyman java_vm jcontrol keytool > > > > ktab rmid unpack200 > > > > classic j9vm javaw jdmpview kinit > > > > pack200 rmiregistry > > > > ikeycmd java javaws jextract klist > > > > policytool tnameserv > > > > chipchop# elfedit --input-osabi=FreeBSD --output-osabi=FreeBSD > > > > java elfedit: Error: java: Unmatched EI_OSABI: 0 is not 9 > > > > chipchop# elfedit --input-osabi=FreeBSD --output-osabi=FreeBSD > > > > java_vm elfedit: Error: java_vm: Unmatched EI_OSABI: 0 is not 9 > > > > chipchop# elfedit --output-osabi=FreeBSD java_vm > > > > chipchop# elfedit --output-osabi=FreeBSD java > > > > chipchop# > > > > > > > > If in doubt about my finding for similarities > > > > between /lib/ld.so.1 and /usr/lbexec/ld-elf.so.1 then open the > > > > former with nano orvi and the latter with vi to see the headers. > > > > > > Would it be a much of a shock to discover that two export largely > > > intersecting list of functions, both being ELF loaders? > > > > > > Would rewriting the header to use the FreeBSD equivalent to the Linux > > ones possibly work? > > Ignore - for the moment- the reference to ld-elf.so.1. > > /usr/lib/ld.so.1 FreeBSD /lib/ld.so.1 Linux. (I did a re-search)Both > > serve the same purpose. The binaries are obviously checking for the > > Linux path. > > > > > > Sadly, you > > > provide no answer to the question you yourself ask on the very first > > > line of own messages, so the point of your message is somewhat > > > unclear to me still. > > > > > > -- > > > Alexander Kabaev > > > > > > > Has anyone reported anything on changing the called for libraries and > > such in the file to use the FreeBSD path instead? > > No, this won't work. By rewriting headers you change the library to > _look_ like FreeBSD one, but you do not change what library _does_. > Linux and FreeBSD differ in how syscalls are processed and what > parameters they take, they setup floating point processing unitt in a > subtly different ways by default, and so on and so on. Linux ELF loader > expects an information from the kernel that FreeBSD kernel won't > provide and vice versa. If library were not communicating with outside > world at all, then it likely will be possible possible to rewrite its > headers and use it in FreeBSD, but that theoretical case is hardly > interesting in real world. > > -- > Alexander Kabaev > An honest thanks, man, for the feedback. Okay, I hope no one on either list gets pissed at my next questions and statements. I basically learn by pattern recognition- comparison, reverse engineering (I finally have to admit that's what I'm doing.), and such. I would ask to be pointed to a set of tutorials to learn disassembling elf files. I have elfkickers installed; is that set of programs enough to get started. I've seen references to elfutils; will having that program help? I realize that by learning how to edit makefiles and other config statements that I'm learning some about C and shell slowly; what would be some other FreeBSD projects that I can work with to learn more? This is what I am trying/doing right now related to FreeBSD. Porting to Xbox360 and wii: I'm missing the wireless controller to the wii and have to borrow one. I pulled the Xbox360 out of atrash heap and I'm ring to repair it. Making the ibm-java-binaries work on FreeBSD powerpc: That is what the conversation has been about. The project is being started at school and will be continued at the next one- community college now to a university later. Having more people know about FreeBSD: This is why I am introducing it at school. It is also why I try to make my tutorials thorough. From owner-freebsd-emulation@FreeBSD.ORG Sat Mar 17 14:49:16 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82CE2106564A for ; Sat, 17 Mar 2012 14:49:15 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0B98FC1A for ; Sat, 17 Mar 2012 14:49:15 +0000 (UTC) Received: by dald2 with SMTP id d2so8109342dal.13 for ; Sat, 17 Mar 2012 07:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yJD8gQx1RpHHWy38q+rfY5ymKgepq5BjXerUmLem3Og=; b=mGpF4TtS2CQJZ8aRFg6zRnXgh6BDh4CONxKoI4WSYvraaqYW6Tu8ql/L1SeoxAcGa7 k/wuH0EjQQHVLpGAtBvDR1DYWv33EyiYQWjfxPz6b3l8MrFztoEN40F1t+Q7OZUhNWQu todQubhRumno6PK21W0xzqs77GuzyOFRSQ6zjXHmfohoA9998+PM2l5aY5gdXJ1m8WQZ 9KBZ09JguMhNhWjbOqTw98nZwePkjArvcJn095RYPUW9dgXXBwjFSIp81bR0uco40Js2 1ysdc/khRcdrH59TEKdlk6N4qoM8cbOKWBKjsLzYSXApyBAaWE0i30CtQAb0X7OildwR EeVw== MIME-Version: 1.0 Received: by 10.68.189.5 with SMTP id ge5mr24616193pbc.50.1331995754678; Sat, 17 Mar 2012 07:49:14 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Sat, 17 Mar 2012 07:49:14 -0700 (PDT) In-Reply-To: <4F642D63.10600@mittelstaedt.us> References: <4F5D48E6.9010802@herveybayaustralia.com.au> <4F5F2CC5.80608@herveybayaustralia.com.au> <4F615D09.8030009@mittelstaedt.us> <4F617C63.9030106@mittelstaedt.us> <4F618F2B.7040709@herveybayaustralia.com.au> <4F642D63.10600@mittelstaedt.us> Date: Sat, 17 Mar 2012 10:49:14 -0400 Message-ID: From: Super Bisquit To: Ted Mittelstaedt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org Subject: Re: Fwd: Kernel memory usage X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 14:49:16 -0000 On Sat, Mar 17, 2012 at 2:21 AM, Ted Mittelstaedt wrote: > On 3/14/2012 11:41 PM, Da Rock wrote: > >> On 03/15/12 15:21, Ted Mittelstaedt wrote: >> >>> A number of FreeBSD kernel structures are dynamically created at >>> boot time - based on the amount of ram in the system. I would guess >>> if you boot your stripped BSD image on a virtual system with 64Mb of >>> ram you wouldn't see the kernel grow to 32MB >>> >> So how do I find out how large the "kernel" is then in memory? >> > > Boot it! From: > > http://www.freebsd.org/doc/en_**US.ISO8859-1/books/handbook/** > configtuning-kernel-limits.**html > > "...The variable kern.maxusers is automatically sized at boot based on > > the amount of memory available in the system, and may be determined at > > run-time by inspecting the value of the read-only kern.maxusers sysctl..." > > A whole bunch of kernel parameters are calculated at boot based on this > figure. Those make the kernel bigger or smaller. > > As to how "large" it is, the file descriptors, clusters and so on that > are calculated at boot are considered part of the kernel from a memory > standpoint. > > > And how > >> did this conversation make it to emulation@? :) >> >> > beats me. >From working with qemu, asking questions, researching. This seemed to be a better place for your situation. > > > Actually, another question comes to mind: is it possible to limit how >> large the kernel structures grow? >> > > The handbook seems to imply that once they are all setup the kernel > doesn't grow. > > > >>> It would be interesting to see FreeBSD running on a Smartphone. >>> >> Thats what I'm interested in for the long term, but not necessarily in >> this instance. This really has become an interesting thread... for every >> answer there are more questions- a hydra ;) >> > > Heh. > > Ted > > > >>> Ted >>> >>> On 3/14/2012 9:03 PM, Super Bisquit wrote: >>> >>>> On 3/14/12, Ted Mittelstaedt> >>>> wrote: >>>> >>>>> What do you regard as a "low memory" machine? >>>>> >>>> On real hardware I've used: >>>> HTC Apache 64/128 ROM/RAM >>>> Embedded 486 with 5M RAM >>>> Older tower maxed at 128M >>>> >>>> I'd say anything less than 64M RAM for normal hardware, less than 32 >>>> for embedded. >>>> >>>> Some systems do not have small memory modules. I have two SunBlade >>>> 1000s that can be stripped down to 128M. >>>> >>>> I'm also aware that the environment limits what the machine can have >>>> installed. >>>> >>>> There are older systems and embedded devices which run/ran on 16kb of >>>> RAM. I'm certain that the oldest electronic led calculators used even >>>> less memory. >>>> I digress. >>>> >>>> >>>> >>>> >>>> >>>>> Ted >>>>> >>>>> On 3/13/2012 8:30 AM, Super Bisquit wrote: >>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Da Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au> >>>>>> > >>>>>> Date: Tue, Mar 13, 2012 at 7:17 AM >>>>>> Subject: Re: Kernel memory usage >>>>>> To: freebsd-hackers@freebsd.org >>>>>> >>>>>> >>>>>> On 03/13/12 05:40, Super Bisquit wrote: >>>>>> >>>>>> CPU architecture and model have a lot to do with performance. >>>>>>> You will also get different results if you used qemu in place of >>>>>>> VirtualBox. Qemu allows you to choose different emulated >>>>>>> architectures, CPUs, and machine bases. What's the downside? You have >>>>>>> to use the command line. >>>>>>> Install qemu and run a series of virtual machines. >>>>>>> Embedded devices also include Power(PC), ARMv?, Coldfire, et al; >>>>>>> you're only dealing with i386 and/or the 64 bit extension (AMD64). >>>>>>> CISC- which does not contain any hardware modification to be a RISC >>>>>>> replacement- runs fewer instructions than RISC due to the limited >>>>>>> number of registers. Take this into consideration every time a >>>>>>> program runs. >>>>>>> Everything else also matters on real and emulated systems: >>>>>>> Is it ide, scsi, sdd, flashdevice for the hard drive? >>>>>>> What type of RAM? >>>>>>> Dedicated or shared disk? >>>>>>> >>>>>>> I'm a little confused by the response, I was interested if someone >>>>>> knew >>>>>> what determines the size of kernel in memory (or wired); I only >>>>>> considered >>>>>> the embedded list because they have a greater interest in the >>>>>> memory size >>>>>> working with so little. >>>>>> >>>>>> It is academic as I'm trying to understand the kernel internals, as >>>>>> well >>>>>> as >>>>>> understand what works with low memory so I can tune accordingly. I >>>>>> understand the different CPU instruction sets (roughly), although I >>>>>> would >>>>>> be interested as to the size of the kernel in each. >>>>>> >>>>>> What my question was about was the wired memory size and what makes it >>>>>> grow >>>>>> (to put it super simply :) ). I know some growth would be expected, >>>>>> but >>>>>> this seems obese; how would I find out how much memory a process >>>>>> structure >>>>>> takes? Or else what am I missing? >>>>>> >>>>>> That said I'll have a crack at what you suggest as that follows a >>>>>> whole >>>>>> new >>>>>> interesting tangent :) I have used qemu before, but found VBox a >>>>>> bit more >>>>>> responsive (and, I will admit, easier...) >>>>>> >>>>>> >>>>>> On 3/11/12, Da >>>>>>> Rock<9Phackers@**herveybayaust**ralia.com.au >>>>>>> <9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au> >>>>>>> >> >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> I may be required to move this to embedded, but I am only looking >>>>>>>> for >>>>>>>> generalisation. >>>>>>>> >>>>>>>> Recently a thread came up on questions regarding memory usage, and a >>>>>>>> post was made regarding wired memory being nearly all kernel- >>>>>>>> something >>>>>>>> I was ready to dispute, but then I thought I'd better make sure. >>>>>>>> >>>>>>>> So I tested a few theories first off: >>>>>>>> >>>>>>>> 1. Comparing memory usage across machines >>>>>>>> >>>>>>>> I checked servers and desktops as well as vm's for memory usage, >>>>>>>> and I >>>>>>>> found some interesting results. On a firewall with no apps installed >>>>>>>> only 35M wired is used, on a desktop up to 700M~ can be used. >>>>>>>> Even as a >>>>>>>> dedicated server with a few services used it remains around 35M. >>>>>>>> >>>>>>>> Surely this means that the wired memory used is not just kernel? >>>>>>>> But I >>>>>>>> held off my assumptions as it was still plausible that the >>>>>>>> structures >>>>>>>> used by the kernel could balloon that far, too. >>>>>>>> >>>>>>>> 2. Stripped down, lean mean, kernel machine >>>>>>>> >>>>>>>> I then (using a vm I was building a kernel for anyway) stripped >>>>>>>> down a >>>>>>>> kernel in a VBox VM using le drivers for network to see what >>>>>>>> could be >>>>>>>> achieved. This is my kernel conf: >>>>>>>> >>>>>>>> include GENERIC >>>>>>>> ident VPN >>>>>>>> options IPSEC >>>>>>>> options IPSEC_DEBUG >>>>>>>> options IPSEC_NAT_T >>>>>>>> device crypto >>>>>>>> device enc >>>>>>>> >>>>>>>> # minimise kernel >>>>>>>> nooptions UFS_GJOURNAL >>>>>>>> nooptions MD_ROOT >>>>>>>> nooptions NFSCL >>>>>>>> nooptions NFSD >>>>>>>> nooptions NFSLOCKD >>>>>>>> nooptions NFS_ROOT >>>>>>>> nooptions MSDOSFS >>>>>>>> nooptions CD9660 >>>>>>>> nooptions PROCFS >>>>>>>> nooptions PSEUDOFS >>>>>>>> nodevice fdc >>>>>>>> nodevice mvs >>>>>>>> nodevice siis >>>>>>>> nodevice ahc >>>>>>>> nodevice ahd >>>>>>>> nodevice esp >>>>>>>> nodevice hptiop >>>>>>>> nodevice isp >>>>>>>> nodevice mpt >>>>>>>> nodevice mps >>>>>>>> nodevice sym >>>>>>>> nodevice trm >>>>>>>> nodevice adv >>>>>>>> nodevice adw >>>>>>>> nodevice aic >>>>>>>> nodevice bt >>>>>>>> nodevice ses >>>>>>>> nodevice amr >>>>>>>> nodevice arcmsr >>>>>>>> nodevice ciss >>>>>>>> nodevice dpt >>>>>>>> nodevice hptmv >>>>>>>> nodevice hptrr >>>>>>>> nodevice irr >>>>>>>> nodevice ips >>>>>>>> nodevice mly >>>>>>>> nodevice twa >>>>>>>> nodevice aac >>>>>>>> nodevice aacp >>>>>>>> nodevice ida >>>>>>>> nodevice mfi >>>>>>>> nodevice mlx >>>>>>>> nodevice twe >>>>>>>> nodevice tws >>>>>>>> nodevice splash >>>>>>>> nodevice cbb >>>>>>>> nodevice pccard >>>>>>>> nodevice cardbus >>>>>>>> nodevice uart >>>>>>>> nodevice ppc >>>>>>>> nodevice ppbus >>>>>>>> nodevice lpt >>>>>>>> nodevice plip >>>>>>>> nodevice ppi >>>>>>>> nodevice puc >>>>>>>> nodevice bxe >>>>>>>> nodevice de >>>>>>>> nodevice em >>>>>>>> nodevice igb >>>>>>>> nodevice ixgbe >>>>>>>> nodevice ti >>>>>>>> nodevice txp >>>>>>>> nodevice vx >>>>>>>> nodevice miibus >>>>>>>> nodevice ae >>>>>>>> nodevice age >>>>>>>> nodevice alc >>>>>>>> nodevice ale >>>>>>>> nodevice bce >>>>>>>> nodevice bfe >>>>>>>> nodevice bge >>>>>>>> nodevice dc >>>>>>>> nodevice et >>>>>>>> nodevice fxp >>>>>>>> nodevice jme >>>>>>>> nodevice lge >>>>>>>> nodevice msk >>>>>>>> nodevice nfe >>>>>>>> nodevice nge >>>>>>>> nodevice pcn >>>>>>>> nodevice re >>>>>>>> nodevice rl >>>>>>>> nodevice sf >>>>>>>> nodevice sge >>>>>>>> nodevice sis >>>>>>>> nodevice sk >>>>>>>> nodevice ste >>>>>>>> nodevice stge >>>>>>>> nodevice tl >>>>>>>> nodevice tx >>>>>>>> nodevice vge >>>>>>>> nodevice vr >>>>>>>> nodevice wb >>>>>>>> nodevice xl >>>>>>>> nodevice cs >>>>>>>> nodevice ed >>>>>>>> nodevice ex >>>>>>>> nodevice ep >>>>>>>> nodevice fe >>>>>>>> nodevice sn >>>>>>>> nodevice xe >>>>>>>> nodevice wlan >>>>>>>> nooptions IEEE80211_DEBUG >>>>>>>> nooptions IEEE80211_AMPDU_AGE >>>>>>>> nooptions IEEE80211_SUPPORT_MESH >>>>>>>> nodevice wlan_wep >>>>>>>> nodevice wlan_ccmp >>>>>>>> nodevice wlan_tkip >>>>>>>> nodevice wlan_amrr >>>>>>>> nodevice an >>>>>>>> nodevice ath >>>>>>>> nodevice ath_pci >>>>>>>> nodevice ath_hal >>>>>>>> nooptions AH_SUPPORT_AR5416 >>>>>>>> nodevice ath_rate_sample >>>>>>>> nodevice ipw >>>>>>>> nodevice iwi >>>>>>>> nodevice iwn >>>>>>>> nodevice malo >>>>>>>> nodevice mwl >>>>>>>> nodevice ral >>>>>>>> nodevice wi >>>>>>>> nodevice wpi >>>>>>>> nodevice md >>>>>>>> nooption USB_DEBUG >>>>>>>> nodevice uhci >>>>>>>> nodevice ohci >>>>>>>> nodevice ehci >>>>>>>> nodevice xhci >>>>>>>> nodevice usb >>>>>>>> nodevice uhid >>>>>>>> nodevice ukbd >>>>>>>> nodevice ulpt >>>>>>>> nodevice umass >>>>>>>> nodevice ums >>>>>>>> nodevice urio >>>>>>>> nodevice u3g >>>>>>>> nodevice uark >>>>>>>> nodevice ubsa >>>>>>>> nodevice uftdi >>>>>>>> nodevice uipaq >>>>>>>> nodevice uplcom >>>>>>>> nodevice uslcom >>>>>>>> nodevice uvisor >>>>>>>> nodevice uvscom >>>>>>>> nodevice aue >>>>>>>> nodevice axe >>>>>>>> nodevice cdce >>>>>>>> nodevice cue >>>>>>>> nodevice kue >>>>>>>> nodevice rue >>>>>>>> nodevice udav >>>>>>>> nodevice rum >>>>>>>> nodevice run >>>>>>>> nodevice uath >>>>>>>> nodevice upgt >>>>>>>> nodevice ural >>>>>>>> nodevice urtw >>>>>>>> nodevice zyd >>>>>>>> #nodevice firewire >>>>>>>> nodevice fwe >>>>>>>> nodevice fwip >>>>>>>> #nodevice dcons >>>>>>>> #nodevice dcons_rom >>>>>>>> nodevice sound >>>>>>>> nodevice snd_es137x >>>>>>>> nodevice snd_hda >>>>>>>> nodevice snd_ich >>>>>>>> nodevice snd_uaudio >>>>>>>> nodevice snd_via8233 >>>>>>>> >>>>>>>> World was also rebuilt as recommended by the handbook. As you can >>>>>>>> see I >>>>>>>> was rebuilding for IPSEC (for testing purposes only note). I >>>>>>>> couldn't >>>>>>>> remove dcons (not sure why- missing defined references), and that >>>>>>>> pulled >>>>>>>> in firewire too. >>>>>>>> >>>>>>>> The result was surprising: a 14M kernel became 6.3M, and when >>>>>>>> running I >>>>>>>> found it only used 19M used for wired (whoopee!) as opposed to >>>>>>>> 35M. No >>>>>>>> services were running per se, only the usual suspects in base: >>>>>>>> >>>>>>>> vpn-test# ps ax >>>>>>>> PID TT STAT TIME COMMAND >>>>>>>> 0 ?? DLs 0:00.11 [kernel] >>>>>>>> 1 ?? ILs 0:00.01 /sbin/init -- >>>>>>>> 2 ?? DL 0:00.00 [crypto] >>>>>>>> 3 ?? DL 0:00.00 [crypto returns] >>>>>>>> 4 ?? DL 0:00.00 [sctp_iterator] >>>>>>>> 5 ?? DL 0:00.00 [xpt_thrd] >>>>>>>> 6 ?? DL 0:00.10 [pagedaemon] >>>>>>>> 7 ?? DL 0:00.00 [vmdaemon] >>>>>>>> 8 ?? DL 0:00.01 [pagezero] >>>>>>>> 9 ?? DL 0:00.30 [bufdaemon] >>>>>>>> 10 ?? DL 0:00.00 [audit] >>>>>>>> 11 ?? RL 589:34.00 [idle] >>>>>>>> 12 ?? WL 0:38.64 [intr] >>>>>>>> 13 ?? DL 0:12.21 [geom] >>>>>>>> 14 ?? DL 0:03.30 [yarrow] >>>>>>>> 15 ?? DL 0:04.40 [syncer] >>>>>>>> 16 ?? DL 0:00.63 [vnlru] >>>>>>>> 17 ?? DL 0:00.53 [softdepflush] >>>>>>>> 104 ?? Is 0:00.00 adjkerntz -i >>>>>>>> 582 ?? Is 0:00.00 /sbin/devd >>>>>>>> 737 ?? Ss 0:00.09 /usr/sbin/syslogd -s >>>>>>>> 912 ?? Ss 0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p >>>>>>>> /var/run/ntpd.pid >>>>>>>> 977 ?? Is 0:00.00 /usr/sbin/sshd >>>>>>>> 984 ?? Ss 0:00.81 sendmail: accepting connections (sendmail) >>>>>>>> 988 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for >>>>>>>> /var/spool/client >>>>>>>> 994 ?? Ss 0:00.12 /usr/sbin/cron -s >>>>>>>> 2061 ?? Is 0:00.03 sshd: admin [priv] (sshd) >>>>>>>> 2064 ?? S 0:00.04 sshd: admin@pts/0 (sshd) >>>>>>>> 1052 v0 Is 0:00.01 login [pam] (login) >>>>>>>> 1060 v0 I+ 0:00.02 -csh (csh) >>>>>>>> 1053 v1 Is+ 0:00.00 /usr/libexec/getty Pc ttyv1 >>>>>>>> 1054 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2 >>>>>>>> 1055 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3 >>>>>>>> 1056 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4 >>>>>>>> 1057 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5 >>>>>>>> 1058 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6 >>>>>>>> 1059 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7 >>>>>>>> 2065 0 Is 0:00.02 -csh (csh) >>>>>>>> 2068 0 I 0:00.01 su >>>>>>>> 2069 0 S 0:00.04 _su (csh) >>>>>>>> 2414 0 R+ 0:00.00 ps ax >>>>>>>> >>>>>>>> After some minutes though, the usage went up to 39M. WTF? >>>>>>>> >>>>>>>> So I'm now thoroughly confused. Google didn't really show up any >>>>>>>> real >>>>>>>> answers either. Aside from discovering the true nature of what was >>>>>>>> discussed in the posts, my hypothetical theorising is for my own >>>>>>>> academics as well; and I'm trying to slim down my kernels to see >>>>>>>> if I >>>>>>>> can improve performance with low memory systems. >>>>>>>> >>>>>>>> Can process structures cause this much ballooning? I find that >>>>>>>> hard to >>>>>>>> believe given not much is running here. My only other thought >>>>>>>> would be >>>>>>>> pipe or network structures? Anything I'm missing? >>>>>>>> >>>>>>>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can >>>>>>>> boot in >>>>>>>> seconds as opposed to minutes. Sweet! Although compiling clang took >>>>>>>> years... and gcc was built as well :/ >>>>>>>> >>>>>>>> Cheers >>>>>>>> ______________________________****_________________ >>>>>>>> freebsd-hackers@freebsd.org mailing list >>>>>>>> http://lists.freebsd.org/****mailman/listinfo/freebsd-****hackers >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@**** >>>>>>>> freebsd.org >>>>>>>> >" >>>>>>>> >>>>>>>> ______________________________****_________________ >>>>>>>> >>>>>>> freebsd-hackers@freebsd.org mailing list >>>>>>> http://lists.freebsd.org/****mailman/listinfo/freebsd-****hackers >>>>>>> >>>>>>> > >>>>>>> >>>>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@**** >>>>>>> freebsd.org >>>>>>> >" >>>>>>> >>>>>>> >>>>>> ______________________________****_________________ >>>>>> freebsd-hackers@freebsd.org mailing list >>>>>> http://lists.freebsd.org/****mailman/listinfo/freebsd-****hackers >>>>>> >>>>>> > >>>>>> >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-hackers-unsubscribe@**freebsd.org >>>>>> " >>>>>> >>>>>> I'm fowarding this thread in the event the individual, "da Rock" >>>>>> will be >>>>>> able to receive more help. >>>>>> ______________________________**_________________ >>>>>> freebsd-emulation@freebsd.org mailing list >>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**emulation >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-emulation-**unsubscribe@freebsd.org >>>>>> " >>>>>> >>>>>> >>>>>> ----- >>>>>> No virus found in this message. >>>>>> Checked by AVG - www.avg.com >>>>>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: >>>>>> 03/14/12 >>>>>> >>>>> >>>>> >>>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: >>>> 03/14/12 >>>> >>> >>> ______________________________**_________________ >>> freebsd-emulation@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**emulation >>> To unsubscribe, send any mail to >>> "freebsd-emulation-**unsubscribe@freebsd.org >>> " >>> >> >> ______________________________**_________________ >> freebsd-emulation@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**emulation >> To unsubscribe, send any mail to >> "freebsd-emulation-**unsubscribe@freebsd.org >> " >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2012.0.1913 / Virus Database: 2114/4875 - Release Date: 03/16/12 >> > > ______________________________**_________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**emulation > To unsubscribe, send any mail to "freebsd-emulation-** > unsubscribe@freebsd.org " >