From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 00:21:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A1CA1065670; Sun, 14 Feb 2010 00:21:30 +0000 (UTC) (envelope-from npapke@acm.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 576D78FC08; Sun, 14 Feb 2010 00:21:30 +0000 (UTC) Received: from pd3ml1so-ssvc.prod.shaw.ca ([10.0.141.140]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 13 Feb 2010 17:21:29 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=ymFRpTLrexEA:10 a=VF9RaR9bft6c8SsOr3WyFg==:17 a=wNSq58qLikDXTUDwgCcA:9 a=TtEtxLw1_FKF6WH-PrAA:7 a=2wOHmvp32O22Ql_x2akgZBgJCxEA:4 Received: from unknown (HELO proven.lan.provenpath.ca) ([24.85.241.34]) by pd3ml1so-dmz.prod.shaw.ca with ESMTP; 13 Feb 2010 17:21:29 -0700 Received: from proven.lan.provenpath.ca (localhost [127.0.0.1]) by proven.lan.provenpath.ca (8.14.4/8.14.4) with ESMTP id o1E0LTtp002364; Sat, 13 Feb 2010 16:21:29 -0800 (PST) (envelope-from npapke@acm.org) Received: (from npapke@localhost) by proven.lan.provenpath.ca (8.14.4/8.14.4/Submit) id o1E0LTNM002363; Sat, 13 Feb 2010 16:21:29 -0800 (PST) (envelope-from npapke@acm.org) X-Authentication-Warning: proven.lan.provenpath.ca: npapke set sender to npapke@acm.org using -f From: Norbert Papke To: freebsd-stable@freebsd.org Date: Sat, 13 Feb 2010 16:21:28 -0800 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; amd64; ; ) References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <1266096425.89452.30.camel@balrog.2hip.net> <201002131512.57040.npapke@acm.org> In-Reply-To: <201002131512.57040.npapke@acm.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201002131621.28970.npapke@acm.org> Cc: Robert Noland Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 00:21:30 -0000 On February 13, 2010, Norbert Papke wrote: > I will repeat the experiment a few more times. After quite a number of trials, I never managed to get any further with the radeon driver. I also tried the radeonhd driver. It seems to behave a little differently. I usually get to an X screen with some incompletely rendered windows before the system hangs. Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0106403, nr=0x03, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_irq_by_busid] 1:0:0 => IRQ 260 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x80086414, nr=0x14, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_irq_install] irq=260 Feb 13 15:51:51 proven kernel: drm0: [ITHREAD] Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x800c6455, nr=0x55, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x80106459, nr=0x59, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0106451, nr=0x51, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_cp_getparam] pid=1833 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x20006441, nr=0x41, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_cp_start] Feb 13 15:51:51 proven kernel: [drm:pid1833:r600_do_cp_start] Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0406429, nr=0x29, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_freelist_get] done_age = -559038737 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0406429, nr=0x29, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:radeon_freelist_get] done_age = -559038737 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 0000060000020000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 0000060000021000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 0000060000022000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 0000060000023000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 0000060000028000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc010644d, nr=0x4d, dev 0xffffff00026fb400, auth=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:radeon_cp_indirect] idx=2 s=0 e=14400 d=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:r600_cp_dispatch_indirect] dwords:3600 Feb 13 15:51:52 proven kernel: [drm:pid1833:r600_cp_dispatch_indirect] offset 0xf0222000 I am not sure what to make of this. Cheers, -- Norbert. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 00:24:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39C91106566C; Sun, 14 Feb 2010 00:24:32 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id BC4918FC08; Sun, 14 Feb 2010 00:24:31 +0000 (UTC) Received: by qyk29 with SMTP id 29so2099464qyk.13 for ; Sat, 13 Feb 2010 16:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=oRECKotooxJGM0JaHRfUl3lFOKI4KV29JBjCZEo5qXM=; b=PNA5sSqq4PkFqcRWNWx/Eo1srtIeO7VCZlG7SKDR0bvdHR0/UnIBaMrah2i6lm+qOF EPOuJn9J1xWVNfGp45/Iob6tmY6/usgBFwp1st7GsntAeplcNWXkMNITdYcZ49moH/xH Tmz+MtNRZoPI/fmoe9zWEYIbnV++dmHRCqmkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iBnd9inRb8XLMJytqeYn5PuCh5TkhINkMSw3BkVG67gzF7ui9v3WyILRvt6sJAiC6y y17dtu2VDxZ+BYPKUPivZ5CKsTvAq5MXwXoVEQtG3OnZQHkwL9GqDyRI2ebuWPaDc//+ H5EHfJQC0Ceisznfizk6iC+ZJdelZiGwPo4H8= MIME-Version: 1.0 Received: by 10.224.95.154 with SMTP id d26mr1592063qan.108.1266107070929; Sat, 13 Feb 2010 16:24:30 -0800 (PST) Date: Sun, 14 Feb 2010 02:24:30 +0200 Message-ID: From: Dan Naumov To: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: managing ZFS automatic mounts - FreeBSD deviates from Solaris? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 00:24:32 -0000 Hello >From the SUN ZFS Administration Guide: http://docs.sun.com/app/docs/doc/819-5461/gaztn?a=view "If ZFS is currently managing the file system but it is currently unmounted, and the mountpoint property is changed, the file system remains unmounted." This does not seem to be the case in FreeBSD (8.0-RELEASE): ================================= zfs get mounted tank/home NAME PROPERTY VALUE SOURCE tank/home mounted no - zfs set mountpoint=/mnt/home tank/home zfs get mounted tank/home NAME PROPERTY VALUE SOURCE tank/home mounted no - ================================= This might not look like a serious issue at first, until you try doing an installation of FreeBSD from FIXIT, trying to setup multiple filesystems and their mountpoints at the very end of the installation process. For example if you set the mountpoint of your poolname/rootfs/usr to /usr as one of the finishing touches to the system installation, it will immideately mount the filesystem, instantly breaking your FIXIT environment and you cannot proceed any further. Is this a known issue and/or should I submit a PR? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 00:27:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDC6710656D6; Sun, 14 Feb 2010 00:27:01 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6D74B8FC1F; Sun, 14 Feb 2010 00:27:01 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so226290qwh.7 for ; Sat, 13 Feb 2010 16:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hkLs5ojGyaJqoyTrHRxLavMOgdRXEDy0lqa7OIT+4I4=; b=fh4krHRTBGE7HSXp5U6IbTWKqmPQ02PXf51emhO0lCrxn9/9Siet9nOd/RiM9DWsYX Rui69xnWjLQ0cY8ER5W/G84cpXgodyh5RNqQu1Rmx/bQQ8fEoheMKwHJvgzjzzcr2PVd uxM6aJaTwFsmv7iyI4YX9ETK9sSedPuvvMTdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=qmOB+gAhtIhbi1KiJ4HLPO8q06YnJu4mUovG2lMD1dv3VoEHHFVy+4vQksFDBG612X 9qE7GzaxdyuVL+ePxfbxSP4J7v24vF9MeNJjHm/ESgB8wbqqL0xCnuqC/qN9alf9cvX2 q6tgwY+jxv/fpFg70QKJ8c5J+xZpzuqx1PEwU= MIME-Version: 1.0 Received: by 10.224.63.170 with SMTP id b42mr1595678qai.39.1266107220466; Sat, 13 Feb 2010 16:27:00 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2010 02:27:00 +0200 Message-ID: From: Dan Naumov To: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: managing ZFS automatic mounts - FreeBSD deviates from Solaris? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 00:27:02 -0000 On Sun, Feb 14, 2010 at 2:24 AM, Dan Naumov wrote: > Hello > > From the SUN ZFS Administration Guide: > http://docs.sun.com/app/docs/doc/819-5461/gaztn?a=3Dview > > "If ZFS is currently managing the file system but it is currently > unmounted, and the mountpoint property is changed, the file system > remains unmounted." > > This does not seem to be the case in FreeBSD (8.0-RELEASE): > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > zfs get mounted tank/home > NAME =A0 =A0 =A0 =A0 =A0 =A0PROPERTY =A0 =A0 =A0 =A0VALUE =A0 =A0 =A0 =A0= =A0 SOURCE > tank/home =A0 =A0 =A0 =A0 =A0 =A0 =A0 mounted =A0 =A0 =A0 =A0 no =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- > > zfs set mountpoint=3D/mnt/home tank/home > > zfs get mounted tank/home > NAME =A0 =A0 =A0 =A0 =A0 =A0PROPERTY =A0 =A0 =A0 =A0VALUE =A0 =A0 =A0 =A0= =A0 SOURCE > tank/home =A0 =A0 =A0 =A0 =A0 =A0 =A0 mounted =A0 =A0 =A0 =A0 no =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > This might not look like a serious issue at first, until you try doing > an installation of FreeBSD from FIXIT, trying to setup multiple > filesystems and their mountpoints at the very end of the installation > process. For example if you set the mountpoint of your > poolname/rootfs/usr to /usr as one of the finishing touches to the > system installation, it will immideately mount the filesystem, > instantly breaking your FIXIT environment and you cannot proceed any > further. Is this a known issue and/or should I submit a PR? Oops, I managed to screw up my previous email. My point was to show that "mounted" changes to YES after changing the mountpoint property :) - Dan From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 06:17:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CCDA1065670 for ; Sun, 14 Feb 2010 06:17:05 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id E76608FC08 for ; Sun, 14 Feb 2010 06:17:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 1D40D508B0 for ; Sun, 14 Feb 2010 06:17:04 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0FZvoRiA-+e for ; Sun, 14 Feb 2010 06:17:03 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 3B48E508A8 for ; Sun, 14 Feb 2010 06:17:03 +0000 (GMT) Message-ID: <4B779561.7000205@langille.org> Date: Sun, 14 Feb 2010 01:17:05 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: FreeBSD Stable References: <4B6F9A8D.4050907@langille.org> In-Reply-To: <4B6F9A8D.4050907@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 06:17:05 -0000 Dan Langille wrote: > Hi, > > I'm looking at creating a large home use storage machine. Budget is a > concern, but size and reliability are also a priority. Noise is also a > concern, since this will be at home, in the basement. That, and cost, > pretty much rules out a commercial case, such as a 3U case. It would be > nice, but it greatly inflates the budget. This pretty much restricts me > to a tower case. > > The primary use of this machine will be a backup server[1]. It will do > other secondary use will include minor tasks such as samba, CIFS, cvsup, > etc. > > I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] > with hot-swap bays[3], that seems interesting. I haven't looked at > power supplies, but given that number of drives, I expect something > beefy with a decent reputation is called for. > > Whether I use hardware or software RAID is undecided. I > > I think I am leaning towards software RAID, probably ZFS under FreeBSD > 8.x but I'm open to hardware RAID but I think the cost won't justify it > given ZFS. > > Given that, what motherboard and RAM configuration would you recommend > to work with FreeBSD [and probably ZFS]. The lists seems to indicate > that more RAM is better with ZFS. > > Thanks. > > > [1] - FYI running Bacula, but that's out of scope for this question > > [2] - http://www.newegg.com/Product/Product.aspx?Item=N82E16811192058 > > [3] - nice to have, especially for a failure. After creating three different system configurations (Athena, Supermicro, and HP), my configuration of choice is this Supermicro setup: 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) 2. SuperMicro 5046A $750 (+$43 shipping) 3. LSI SAS 3081E-R $235 4. SATA cables $60 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) 6. Xeon W3520 $310 Total price with shipping $1560 Details and links at http://dan.langille.org/2010/02/14/supermicro/ I'll probably start with 5 HDD in the ZFS array, 2x gmirror'd drives for the boot, and 1 optical drive (so 8 SATA ports). From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 07:05:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9830B106566B for ; Sun, 14 Feb 2010 07:05:26 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBEA8FC08 for ; Sun, 14 Feb 2010 07:05:25 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-157-119.lns6.adl6.internode.on.net [121.45.157.119]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o1E75L2x055463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 14 Feb 2010 17:35:21 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Sun, 14 Feb 2010 17:35:10 +1030 User-Agent: KMail/1.9.10 References: <4B6F9A8D.4050907@langille.org> <4B779561.7000205@langille.org> In-Reply-To: <4B779561.7000205@langille.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7237398.xUZyrWGPh4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002141735.18275.doconnor@gsoft.com.au> X-Spam-Score: -1.74 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 07:05:26 -0000 --nextPart7237398.xUZyrWGPh4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 14 Feb 2010, Dan Langille wrote: > After creating three different system configurations (Athena, > Supermicro, and HP), my configuration of choice is this Supermicro > setup: > > =A0 =A0 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) > =A0 =A0 2. SuperMicro 5046A $750 (+$43 shipping) > =A0 =A0 3. LSI SAS 3081E-R $235 > =A0 =A0 4. SATA cables $60 > =A0 =A0 5. Crucial 3=D72G ECC DDR3-1333 $191 (+ $6 shipping) > =A0 =A0 6. Xeon W3520 $310 > > Total price with shipping $1560 > > Details and links at http://dan.langille.org/2010/02/14/supermicro/ > > I'll probably start with 5 HDD in the ZFS array, 2x gmirror'd drives > for the boot, and 1 optical drive (so 8 SATA ports). That is f**king expensive for a home setup :) I priced a decent ZFS PC for a small business and it was AUD$2500=20 including the disks (5x750Gb), case, PSU etc.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart7237398.xUZyrWGPh4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLd6Cu5ZPcIHs/zowRAhueAJ9Ds9S+RaEA5/HvsM6jflY+hqD97wCfRuZ+ cWAC6TJbl7Fd9NyUqzqdvEs= =IRXE -----END PGP SIGNATURE----- --nextPart7237398.xUZyrWGPh4-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 07:08:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 483831065676 for ; Sun, 14 Feb 2010 07:08:50 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9748A8FC14 for ; Sun, 14 Feb 2010 07:08:49 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-157-119.lns6.adl6.internode.on.net [121.45.157.119]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o1E78k0E055518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 14 Feb 2010 17:38:47 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Sun, 14 Feb 2010 17:38:42 +1030 User-Agent: KMail/1.9.10 References: <4B6F9A8D.4050907@langille.org> <4B779561.7000205@langille.org> <201002141735.18275.doconnor@gsoft.com.au> In-Reply-To: <201002141735.18275.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1402951.YmuIJ6D4gs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002141738.44170.doconnor@gsoft.com.au> X-Spam-Score: -1.741 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 07:08:50 -0000 --nextPart1402951.YmuIJ6D4gs Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 14 Feb 2010, Daniel O'Connor wrote: > On Sun, 14 Feb 2010, Dan Langille wrote: > > After creating three different system configurations (Athena, > > Supermicro, and HP), my configuration of choice is this Supermicro > > setup: > > > > =C2=A0 =C2=A0 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) > > =C2=A0 =C2=A0 2. SuperMicro 5046A $750 (+$43 shipping) > > =C2=A0 =C2=A0 3. LSI SAS 3081E-R $235 > > =C2=A0 =C2=A0 4. SATA cables $60 > > =C2=A0 =C2=A0 5. Crucial 3=C3=972G ECC DDR3-1333 $191 (+ $6 shipping) > > =C2=A0 =C2=A0 6. Xeon W3520 $310 > > > > Total price with shipping $1560 > > > > Details and links at http://dan.langille.org/2010/02/14/supermicro/ > > > > I'll probably start with 5 HDD in the ZFS array, 2x gmirror'd > > drives for the boot, and 1 optical drive (so 8 SATA ports). > > That is f**king expensive for a home setup :) > > I priced a decent ZFS PC for a small business and it was AUD$2500 > including the disks (5x750Gb), case, PSU etc.. Also, that one booted off a 4Gb CF card (non RAID/mirror though). =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1402951.YmuIJ6D4gs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLd6F85ZPcIHs/zowRAmbAAKChBdwNqO+PjrPA9vX+cxPoDcN4TACfexQx gWznLpbNBT3y4aQeyVDXaY0= =K8gk -----END PGP SIGNATURE----- --nextPart1402951.YmuIJ6D4gs-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 14:07:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99C91106566B for ; Sun, 14 Feb 2010 14:07:49 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7011A8FC15 for ; Sun, 14 Feb 2010 14:07:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id C118150843; Sun, 14 Feb 2010 14:07:48 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDpfCdC+D7Ex; Sun, 14 Feb 2010 14:07:47 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 8B11D50842 ; Sun, 14 Feb 2010 14:07:47 +0000 (GMT) Message-ID: <4B7803B9.1040102@langille.org> Date: Sun, 14 Feb 2010 09:07:53 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Daniel O'Connor References: <4B6F9A8D.4050907@langille.org> <4B779561.7000205@langille.org> <201002141735.18275.doconnor@gsoft.com.au> In-Reply-To: <201002141735.18275.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 14:07:49 -0000 Daniel O'Connor wrote: > On Sun, 14 Feb 2010, Dan Langille wrote: >> After creating three different system configurations (Athena, >> Supermicro, and HP), my configuration of choice is this Supermicro >> setup: >> >> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >> 2. SuperMicro 5046A $750 (+$43 shipping) >> 3. LSI SAS 3081E-R $235 >> 4. SATA cables $60 >> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >> 6. Xeon W3520 $310 >> >> Total price with shipping $1560 >> >> Details and links at http://dan.langille.org/2010/02/14/supermicro/ >> >> I'll probably start with 5 HDD in the ZFS array, 2x gmirror'd drives >> for the boot, and 1 optical drive (so 8 SATA ports). > > That is f**king expensive for a home setup :) > > I priced a decent ZFS PC for a small business and it was AUD$2500 > including the disks (5x750Gb), case, PSU etc.. Yes, and this one doesn't yet have HDD. Can you supply details of your system? From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 14:53:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24F65106566B for ; Sun, 14 Feb 2010 14:53:55 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f191.google.com (mail-yx0-f191.google.com [209.85.210.191]) by mx1.freebsd.org (Postfix) with ESMTP id D885B8FC0C for ; Sun, 14 Feb 2010 14:53:54 +0000 (UTC) Received: by yxe29 with SMTP id 29so3342089yxe.14 for ; Sun, 14 Feb 2010 06:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Uuu1rEdiuh01Wfx5hF2hqGXA5yePxVH9PyqI7B989Fg=; b=iLuEVbADaXoyhLhY/IqtDNTeQCEh+z6gi4wLGRNPW+aikLN/mY2zgAYpIL+CaEuOq4 qkDkyuBRyPQiolmiE179RMPWyJf16av4m43WQgHq7OSy3wevwshKKIQAC35gnsa6gtSQ rkCVAJ8R+lKqOk/bgrVG1+SLWo0TkCkunPlTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=KyS+ALDZKh3wTsM+d3pr7vGBVvbtS5bE/TKV9PXViTXD2RUGQDrPLJyrU3IRkV8A6Z 2D63Qu9oM0/C7au4xDzLQDRPrct3evzngwvFGuQHj9Xj3o+x5RNKjbEt3k4v+vnO5lKg B3uSn44IDJvIB8wDljmBjJfEz6BrFjf2kPZkg= MIME-Version: 1.0 Received: by 10.150.118.24 with SMTP id q24mr3307368ybc.119.1266159234129; Sun, 14 Feb 2010 06:53:54 -0800 (PST) Date: Sun, 14 Feb 2010 16:53:54 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: RE: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 14:53:55 -0000 > On Sun, 14 Feb 2010, Dan Langille wrote: >> After creating three different system configurations (Athena, >> Supermicro, and HP), my configuration of choice is this Supermicro >> setup: >> >> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >> 2. SuperMicro 5046A $750 (+$43 shipping) >> 3. LSI SAS 3081E-R $235 >> 4. SATA cables $60 >> 5. Crucial 3=D72G ECC DDR3-1333 $191 (+ $6 shipping) >> 6. Xeon W3520 $310 You do realise how much of a massive overkill this is and how much you are overspending? - Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 16:43:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F413106566C for ; Sun, 14 Feb 2010 16:43:33 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id D02A58FC08 for ; Sun, 14 Feb 2010 16:43:32 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-243-166.shv.bellsouth.net [98.67.243.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 5E58D803D802; Sun, 14 Feb 2010 10:43:31 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id o1EGhRYF060896; Sun, 14 Feb 2010 10:43:27 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Sun, 14 Feb 2010 10:43:27 -0600 (CST) From: Wes Morgan X-X-Sender: morganw@volatile To: Dan Langille In-Reply-To: <4B779561.7000205@langille.org> Message-ID: References: <4B6F9A8D.4050907@langille.org> <4B779561.7000205@langille.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3224958491-2097000650-1266159572=:26040" Content-ID: X-Virus-Scanned: clamav-milter 0.95.3 at warped X-Virus-Status: Clean Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 16:43:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3224958491-2097000650-1266159572=:26040 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Sun, 14 Feb 2010, Dan Langille wrote: > Dan Langille wrote: > > Hi, > > > > I'm looking at creating a large home use storage machine. Budget is a > > concern, but size and reliability are also a priority. Noise is also a > > concern, since this will be at home, in the basement. That, and cost, > > pretty much rules out a commercial case, such as a 3U case. It would be > > nice, but it greatly inflates the budget. This pretty much restricts me to > > a tower case. > > > > The primary use of this machine will be a backup server[1]. It will do > > other secondary use will include minor tasks such as samba, CIFS, cvsup, > > etc. > > > > I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] with > > hot-swap bays[3], that seems interesting. I haven't looked at power > > supplies, but given that number of drives, I expect something beefy with a > > decent reputation is called for. > > > > Whether I use hardware or software RAID is undecided. I > > > > I think I am leaning towards software RAID, probably ZFS under FreeBSD 8.x > > but I'm open to hardware RAID but I think the cost won't justify it given > > ZFS. > > > > Given that, what motherboard and RAM configuration would you recommend to > > work with FreeBSD [and probably ZFS]. The lists seems to indicate that more > > RAM is better with ZFS. > > > > Thanks. > > > > > > [1] - FYI running Bacula, but that's out of scope for this question > > > > [2] - http://www.newegg.com/Product/Product.aspx?Item=N82E16811192058 > > > > [3] - nice to have, especially for a failure. > > After creating three different system configurations (Athena, Supermicro, and > HP), my configuration of choice is this Supermicro setup: > > 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) > 2. SuperMicro 5046A $750 (+$43 shipping) > 3. LSI SAS 3081E-R $235 > 4. SATA cables $60 > 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) > 6. Xeon W3520 $310 > > Total price with shipping $1560 > > Details and links at http://dan.langille.org/2010/02/14/supermicro/ Wow um... That's quite a setup. Do you really need the Xeon W3520? You could get a regular core 2 system for much less and still use the ECC ram (highly recommended). The case you're looking at only has 6 hot-swap bays according to the manuals, although the pictures show 8 (???). You could shave some off the case and cpu, upgrade your 3081E-R to an ARC-1222 for $200 more and have the hardware raid option. If I was building a tower system, I'd put together something like this: Case with 8 hot-swap SATA bays ($250): http://www.newegg.com/Product/Product.aspx?Item=N82E16811192058 Or if you prefer screwless, you can find the case without the 2 hotswap bays and use an icy dock screwless version. Intel server board (for ECC support) ($200): http://www.newegg.com/Product/Product.aspx?Item=N82E16813121328 SAS controller ($120): http://www.buy.com/prod/supermicro-lsi-megaraid-lsisas1068e-8-port-sas-raid-controller-16mb/q/loc/101/207929556.html Note: You'll need to change or remove the mounting bracket since it is "backwards". I was able to find a bracket with matching screw holes on an old nic and secure it to my case. It uses the same chipset as the more expensive 3081E-R, if I remember correctly. Quad-core CPU ($190): http://www.newegg.com/Product/Product.aspx?Item=N82E16819115131 4x2gb ram sticks (97*2): http://www.newegg.com/Product/Product.aspx?Item=N82E16820139045 same SATA cables for sata to mini-sas, same CD burner. Total cost probably $400 less, which you can use to buy some of the drives. For my personal (overkill) setup I have a chenbro 4U chassis with 16 hotswap bays and mini-SAS backplanes, a zippy 2+1 640 watt redundant power supply (sounds like a freight train). I cannot express the joy I felt in ripping out all the little SATA cables and snaking a couple fat 8087s under the fans. 8 of the bays are dedicated to my media array, and the other 8 are there for swapping in and out of backup drives mostly, but the time they REALLY come in handy is when you need to upgrade your array. Buy the replacement drives, pop them in, migrate the pool, and remove the old drives. I've been running with this for almost 3 years. If I had to do it over again, I probably wouldn't get the power supply, it was more expensive than the chassis and I don't think it has ever "saved" me from anything (although I can't complain, it runs 24/7 and never had a glitch). If I could find a good tower case I might consider it, but I've never seen one I liked with mini-sas backplanes. Really the only thing I'm missing is a nice 21U rack on casters, then the whole thing disappears into a corner humming away. --3224958491-2097000650-1266159572=:26040-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 17:42:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0102F106568F for ; Sun, 14 Feb 2010 17:42:38 +0000 (UTC) (envelope-from jon@witchspace.com) Received: from queueout03-winn.ispmail.ntl.com (queueout03-winn.ispmail.ntl.com [81.103.221.33]) by mx1.freebsd.org (Postfix) with ESMTP id 776598FC18 for ; Sun, 14 Feb 2010 17:42:37 +0000 (UTC) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100214172831.VAWB4204.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Sun, 14 Feb 2010 17:28:31 +0000 Received: from witchspace.com ([86.28.98.4]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with SMTP id <20100214172831.GVYI13254.aamtaout01-winn.ispmail.ntl.com@witchspace.com> for ; Sun, 14 Feb 2010 17:28:31 +0000 Received: (qmail 8773 invoked from network); 14 Feb 2010 16:28:14 -0000 Received: from unknown (HELO core.home) (192.168.0.3) by 192.168.0.100 with SMTP; 14 Feb 2010 16:28:14 -0000 From: Jonathan Belson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Feb 2010 17:28:28 +0000 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=VnTOQO56TaHgvNHnZ8wA:9 a=vrz9d7kaIy6HQphQfU4A:7 a=WUp0O3NPq-XWB2UcegexfICub5gA:4 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 17:42:38 -0000 Hiya After reading some earlier threads about zfs performance, I decided to = test my own server. I found the results rather surprising... The machine is a Dell SC440, dual core 2GHz E2180, 2GB of RAM and ICH7 = SATA300 controller. There are three Hitachi 500GB drives = (HDP725050GLA360) in a raidz1 configuration (version 13). I'm running = amd64 7.2-STABLE from 14th Jan. First of all, I tried creating a 200MB file on / (the only non-zfs = partition): # dd if=3D/dev/zero of=3D/root/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 6.158355 secs (34053769 bytes/sec) # dd if=3D/dev/zero of=3D/root/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 5.423107 secs (38670674 bytes/sec) # dd if=3D/dev/zero of=3D/root/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 6.113258 secs (34304982 bytes/sec) Next, I tried creating a 200MB file on a zfs partition: # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 58.540571 secs (3582391 bytes/sec) # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 46.867240 secs (4474665 bytes/sec) # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 21.145221 secs (9917853 bytes/sec) # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 19.387938 secs (10816787 bytes/sec) # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 21.378161 secs (9809787 bytes/sec) # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 200+0 records in 200+0 records out 209715200 bytes transferred in 23.774958 secs (8820844 bytes/sec) Ouch! Ignoring the first result, that's still over three times slower = than the non-zfs test. With a 2GB test file: # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 547.901945 secs (3827605 bytes/sec) # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 595.052017 secs (3524317 bytes/sec) # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 517.326470 secs (4053827 bytes/sec) Even worse :-( Reading 2GB from a raw device: dd if=3D/dev/ad4s1a of=3D/dev/null bs=3D1M count=3D2000 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 13.914145 secs (77169084 bytes/sec) =20 Reading 2GB from a zfs partition (unmounting each time): dd if=3D/tank/test/zerofile.000 of=3D/dev/null bs=3D1M count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 29.905155 secs (70126772 bytes/sec) dd if=3D/tank/test/zerofile.000 of=3D/dev/null bs=3D1M count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 32.557361 secs (64414066 bytes/sec) dd if=3D/tank/test/zerofile.000 of=3D/dev/null bs=3D1M count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 34.137874 secs (61431828 bytes/sec) For reading, there seems to be much less of a disparity in performance. I notice that one drive is on atapci0 and the other two are on atapci1, = but surely it wouldn't make this much of a difference to write speeds? Cheers, --Jon From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 17:51:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B02FB106566B for ; Sun, 14 Feb 2010 17:51:48 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 356CF8FC1C for ; Sun, 14 Feb 2010 17:51:47 +0000 (UTC) Received: by fxm28 with SMTP id 28so134458fxm.31 for ; Sun, 14 Feb 2010 09:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=WIFXQX0XhLKMs2JGkr21qjuAzsB/0splJ//hsqNR2Ds=; b=q8AIaDP6iWo+F/gbwAd3kFqoCL8p9xio1W/W/3SWBKLK2APoop0cBWu1NUz5GXuv+m UiiJkFZC9n7Yl4gqWh57+NF6oaNuPkWlfe2Q51V0NjhLAI9ZwTPIVcRYosLxdWYH1K0u Z1v5REI6Z/86TzO1Oz5vbb+v942bFmZ9WxS/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SHKF4ics9BlmftoRA589QRuahA1yypReWOaVQRRwD9FmvDlVD+VSQev1oZLfdtnINx wCXM0D7Q/iENlqj/fvkt3vlgYO5R1cAP8Wrw4fmAvaJC1VFC+Cf+BezsR5LUgXGsYRfm YpzzkdIcjczuCo9dqdhyUr9rfcgOOm91cRqFI= Received: by 10.223.65.12 with SMTP id g12mr1786696fai.69.1266169906915; Sun, 14 Feb 2010 09:51:46 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2648646fxm.8.2010.02.14.09.51.44 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Feb 2010 09:51:45 -0800 (PST) Sender: Alexander Motin Message-ID: <4B78382E.8080905@FreeBSD.org> Date: Sun, 14 Feb 2010 19:51:42 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Steve Polyack References: <1265617382.00216602.1265605802@10.7.7.3> <1265707385.00217197.1265696404@10.7.7.3> <1265728980.00217271.1265715603@10.7.7.3> <1265750583.00217397.1265739002@10.7.7.3> <1265754184.00217418.1265743204@10.7.7.3> <1265756530.00217435.1265745602@10.7.7.3> <1265790181.00217606.1265778601@10.7.7.3> <1265842691.00217889.1265831404@10.7.7.3> In-Reply-To: <1265842691.00217889.1265831404@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 17:51:48 -0000 Steve Polyack wrote: > On 2/10/2010 12:02 AM, Dan Langille wrote: >> Don't use a port multiplier and this goes away. I was hoping to avoid >> a PM and using something like the Syba PCI Express SATA II 4 x Ports >> RAID Controller seems to be the best solution so far. >> >> http://www.amazon.com/Syba-Express-Ports-Controller-SY-PEX40008/dp/B002R0DZWQ/ref=sr_1_22?ie=UTF8&s=electronics&qid=1258452902&sr=1-22 > > Dan, I can personally vouch for these cards under FreeBSD. We have 3 of > them in one system, with almost every port connected to a port > multiplier (SiI5xxx PMs). Using the siis(4) driver on 8.0-RELEASE > provides very good performance, and supports both NCQ and FIS-based > switching (an essential for decent port-multiplier performance). > > One thing to consider, however, is that the card is only single-lane > PCI-Express. The bandwidth available is only 2.5Gb/s (~312MB/sec, > slightly less than that of the SATA-2 link spec), so if you have 4 > high-performance drives connected, you may hit a bottleneck at the > bus. I'd be particularly interested if anyone can find any similar > Silicon Image SATA controllers with a PCI-E 4x or 8x interface ;) Here is SiI3124 based card with built-in PCIe x8 bridge: http://www.addonics.com/products/host_controller/adsa3gpx8-4em.asp It is not so cheap, but with 12 disks connected via 4 Port Multipliers it can give up to 1GB/s (4x250MB/s) of bandwidth. Cheaper PCIe x1 version mentioned above gave me up to 200MB/s, that is maximum of what I've seen from PCIe 1.0 x1 controllers. Looking on NCQ and FBS support it can be enough for many real-world applications, that don't need so high linear speeds, but have many concurrent I/Os. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 18:04:59 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83C12106566B for ; Sun, 14 Feb 2010 18:04:59 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5678FC1C for ; Sun, 14 Feb 2010 18:04:58 +0000 (UTC) Received: by pzk14 with SMTP id 14so4920075pzk.3 for ; Sun, 14 Feb 2010 10:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Ht9xSVOIafFlkiDojA1+qI2oZvXbhpwiPRL0oqugRbQ=; b=ZHW2zG5K9t/gA2oZGd9nFAt8Id7Ai4lKehagWDqeF7VqbNJOEPUB5xR+EgFe6O1IQu /CoF6FLd3PIBpG5bnslIRqF6zajfOeMyt9HiHgmkXDTrlPPIyBKk2VQBjm7ZZ0d7xeq3 Ph0YiZ5rYQltL1dl5ITISwdsdNO3JXB3myt8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=O7W6C0tzBXFgopGMWT6rXvQJ0SccRWlTCuwBKLfNWbjLnfP4W6MPXa5Sf8rQk4wrnV i9VGfwp9QSPlZSAAmsgUDJDAZnI4r/jJN4AdZntx4HsyRIIyvJOQ1C1PmP7lGCNRraol hK8b5eyaZ4zaMm9Sovfb3zSirdV0DbVGCxDOQ= MIME-Version: 1.0 Received: by 10.142.210.15 with SMTP id i15mr960456wfg.40.1266170698466; Sun, 14 Feb 2010 10:04:58 -0800 (PST) Date: Sun, 14 Feb 2010 10:04:58 -0800 Message-ID: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> From: Nick Rogers To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 18:04:59 -0000 I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone shed light on the below error? I unfortunately cannot provide a proper crash dump. The pointer addresses are always the same. The only other thing I've noticed that may be related is a watchdog timeout on bge0 error before the panic. Thanks. Jan 27 15:25:01 wifi kernel: Jan 27 15:25:01 wifi kernel: Jan 27 15:25:01 wifi kernel: Fatal trap 12: page fault while in kernel mode Jan 27 15:25:01 wifi kernel: cpuid = 4; apic id = 04 Jan 27 15:25:02 wifi kernel: Jan 27 15:25:02 wifi kernel: fault virtual address = 0x28 Jan 27 15:25:02 wifi kernel: fault code = supervisor write data, page not present Jan 27 15:25:02 wifi kernel: instruction pointer = 0x20:0xffffffff803263b7 Jan 27 15:25:02 wifi kernel: stack pointer = 0x28:0xffffff8073acdb40 Jan 27 15:25:02 wifi kernel: frame pointer = 0x28:0xffffff8073acdba0 Jan 27 15:25:02 wifi kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Jan 27 15:25:02 wifi kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Jan 27 15:25:02 wifi kernel: processor eflags = Jan 27 15:25:02 wifi kernel: interrupt enabled, Jan 27 15:25:02 wifi kernel: resume, Jan 27 15:25:02 wifi kernel: IOPL = 0 Jan 27 15:25:02 wifi kernel: Jan 27 15:25:02 wifi kernel: current process From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 18:53:14 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 439BF1065670 for ; Sun, 14 Feb 2010 18:53:14 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id D07558FC0A for ; Sun, 14 Feb 2010 18:53:13 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id o1EIrB1t025443; Sun, 14 Feb 2010 18:53:11 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ngjah-0002x6-QI; Sun, 14 Feb 2010 18:53:11 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id o1EIrBUa057150; Sun, 14 Feb 2010 18:53:11 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id o1EIrBpZ057144; Sun, 14 Feb 2010 18:53:11 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Sun, 14 Feb 2010 18:53:11 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Steven Friedrich In-Reply-To: <201001300708.37683.freebsd@insightbb.com> Message-ID: References: <201001300708.37683.freebsd@insightbb.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-stable@FreeBSD.org Subject: Re: loading module sdhci causes panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 18:53:14 -0000 On Sat, 30 Jan 2010, Steven Friedrich wrote: > I stopped the boot before the timer expired, after it had loaded modules > specified in /boot/loader.conf > > I loaded mmc, mmcsd, and sdhci. > > I continued the boot, and it panic'ed right after apic. > > I rebooted everal times, to load each individually, to narrow it down to > sdhci. > > Can anyone verify that sdhci is compatible with FreeBSD 8? What happens if you just load sdhci? WHat happens if you load sdhci and mmcsd, but not mmc? WHat happens if you load sdhci and mmc, but not mmcsd? Given how early in the boot process you see problems, I'm wondering if this is somehow related to PR kern/141756... Thanks, Gavin From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 19:13:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8242B106566B for ; Sun, 14 Feb 2010 19:13:56 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 47A8D8FC14 for ; Sun, 14 Feb 2010 19:13:56 +0000 (UTC) Received: by iwn36 with SMTP id 36so2403574iwn.3 for ; Sun, 14 Feb 2010 11:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=hqxtx0/knjhPQAZAdYDElrXdstXiUTDadWElrOizKdw=; b=TvAV3eJbFkDeEq6Q2Dzoc3b+KnF8Ri1fz9NzX4H4AVhTZPzxQh1d3VwJKAPn44ciBU FbSkp5kjNYyn4HgBCxRxdJpoQG1LptGvRH5RGArPTnZ9KjTxpSl5foKcVM81OWS3upBD TYkrNByKrra8k+No6bgZ5wFeQMUlpIZs+coW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=PktzaKjp52EKLApdTPYsoBg52NC3+qgNiVfv2ckfD/DRVJdLEQi7wHtexttXN+HzAJ sBfXAQIK7Zep+JLZerzgReflbjTxWZTKAoKLCozhr7An8UH1QYxGqgyVQqeLVo2Ew8Xf uJHD8hy8wmwQWqlXyq8JzH0cUXNlhknHYjegM= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.59.5 with SMTP id j5mr2693222ibh.6.1266174835493; Sun, 14 Feb 2010 11:13:55 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2010 11:13:55 -0800 X-Google-Sender-Auth: 7aae7f8e9c4863bd Message-ID: From: Artem Belevich To: Jonathan Belson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 19:13:56 -0000 Can you check if kstat.zfs.misc.arcstats.memory_throttle_count sysctl increments during your tests? ZFS self-throttles writes if it thinks system is running low on memory. Unfortunately on FreeBSD the 'free' list is a *very* conservative indication of available memory so ZFS often starts throttling before it's really needed. With only 2GB in the system, that's probably what slows you down. The code is in arc_memory_throttle() in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, if anyone's curious. --Artem On Sun, Feb 14, 2010 at 9:28 AM, Jonathan Belson wrote= : > Hiya > > After reading some earlier threads about zfs performance, I decided to te= st my own server. =A0I found the results rather surprising... > > The machine is a Dell SC440, dual core 2GHz E2180, 2GB of RAM and ICH7 SA= TA300 controller. =A0There are three Hitachi 500GB drives (HDP725050GLA360)= in a raidz1 configuration (version 13). =A0I'm running amd64 7.2-STABLE fr= om 14th Jan. > > > First of all, I tried creating a 200MB file on / (the only non-zfs partit= ion): > > # dd if=3D/dev/zero of=3D/root/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 6.158355 secs (34053769 bytes/sec) > > # dd if=3D/dev/zero of=3D/root/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 5.423107 secs (38670674 bytes/sec) > > # dd if=3D/dev/zero of=3D/root/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 6.113258 secs (34304982 bytes/sec) > > > Next, I tried creating a 200MB file on a zfs partition: > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 58.540571 secs (3582391 bytes/sec) > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 46.867240 secs (4474665 bytes/sec) > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 21.145221 secs (9917853 bytes/sec) > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 19.387938 secs (10816787 bytes/sec) > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 21.378161 secs (9809787 bytes/sec) > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D200 > 200+0 records in > 200+0 records out > 209715200 bytes transferred in 23.774958 secs (8820844 bytes/sec) > > Ouch! =A0Ignoring the first result, that's still over three times slower = than the non-zfs test. > > > With a 2GB test file: > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 547.901945 secs (3827605 bytes/sec) > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 595.052017 secs (3524317 bytes/sec) > > # dd if=3D/dev/zero of=3D/tank/test/zerofile.000 bs=3D1M count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 517.326470 secs (4053827 bytes/sec) > > Even worse :-( > > > Reading 2GB from a raw device: > > dd if=3D/dev/ad4s1a of=3D/dev/null bs=3D1M count=3D2000 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 13.914145 secs (77169084 bytes/sec) > > > Reading 2GB from a zfs partition (unmounting each time): > > dd if=3D/tank/test/zerofile.000 of=3D/dev/null bs=3D1M count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 29.905155 secs (70126772 bytes/sec) > > dd if=3D/tank/test/zerofile.000 of=3D/dev/null bs=3D1M count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 32.557361 secs (64414066 bytes/sec) > > dd if=3D/tank/test/zerofile.000 of=3D/dev/null bs=3D1M count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 34.137874 secs (61431828 bytes/sec) > > For reading, there seems to be much less of a disparity in performance. > > I notice that one drive is on atapci0 and the other two are on atapci1, b= ut surely it wouldn't make this much of a difference to write speeds? > > Cheers, > > --Jon > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 20:26:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69CB2106568B for ; Sun, 14 Feb 2010 20:26:21 +0000 (UTC) (envelope-from jon@witchspace.com) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.freebsd.org (Postfix) with ESMTP id B5D9B8FC1C for ; Sun, 14 Feb 2010 20:26:20 +0000 (UTC) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100214202618.BYBY10950.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Sun, 14 Feb 2010 20:26:18 +0000 Received: from witchspace.com ([86.28.98.4]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with SMTP id <20100214202618.JBZG13254.aamtaout01-winn.ispmail.ntl.com@witchspace.com> for ; Sun, 14 Feb 2010 20:26:18 +0000 Received: (qmail 17799 invoked from network); 14 Feb 2010 19:26:02 -0000 Received: from unknown (HELO core.home) (192.168.0.3) by 192.168.0.100 with SMTP; 14 Feb 2010 19:26:02 -0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jonathan Belson In-Reply-To: Date: Sun, 14 Feb 2010 20:26:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <50780815-0D98-4910-B81A-1F41455AC856@witchspace.com> References: To: Artem Belevich X-Mailer: Apple Mail (2.1077) X-Cloudmark-Analysis: v=1.1 cv=W3tOLUehizD4qj6VhtReFuw5MKb8d+XqjIxlDsIazEA= c=1 sm=0 a=uaAj8Ayxam7Zkd_fM5QA:9 a=fKIaMkIs0kY3gXFDgKPSimqX4ZEA:4 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: freebsd-stable@freebsd.org Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 20:26:21 -0000 On 14 Feb 2010, at 19:13, Artem Belevich wrote: > Can you check if kstat.zfs.misc.arcstats.memory_throttle_count sysctl > increments during your tests? >=20 > ZFS self-throttles writes if it thinks system is running low on > memory. Unfortunately on FreeBSD the 'free' list is a *very* > conservative indication of available memory so ZFS often starts > throttling before it's really needed. With only 2GB in the system, > that's probably what slows you down. I tested a number of times during a 2GB write to a zfs partition and the = count stayed at 0. Cheers, --Jon From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 20:33:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1984C106568D for ; Sun, 14 Feb 2010 20:33:43 +0000 (UTC) (envelope-from jon@witchspace.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id 633838FC12 for ; Sun, 14 Feb 2010 20:33:42 +0000 (UTC) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100214203340.KSN4204.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Sun, 14 Feb 2010 20:33:40 +0000 Received: from witchspace.com ([86.28.98.4]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with SMTP id <20100214203340.JEET13254.aamtaout01-winn.ispmail.ntl.com@witchspace.com> for ; Sun, 14 Feb 2010 20:33:40 +0000 Received: (qmail 18072 invoked from network); 14 Feb 2010 19:33:24 -0000 Received: from unknown (HELO core.home) (192.168.0.3) by 192.168.0.100 with SMTP; 14 Feb 2010 19:33:24 -0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jonathan Belson In-Reply-To: <50780815-0D98-4910-B81A-1F41455AC856@witchspace.com> Date: Sun, 14 Feb 2010 20:33:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7C406D93-F94F-4A0C-AE49-6A6D8C1C2868@witchspace.com> References: <50780815-0D98-4910-B81A-1F41455AC856@witchspace.com> To: Artem Belevich X-Mailer: Apple Mail (2.1077) X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=LuWcx9DwnpR-6DHuvo0A:9 a=UhZjU0lUQFXm0ClcdAvFVcF5uQgA:4 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: freebsd-stable@freebsd.org Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 20:33:43 -0000 On 14 Feb 2010, at 20:26, Jonathan Belson wrote: > On 14 Feb 2010, at 19:13, Artem Belevich wrote: >> Can you check if kstat.zfs.misc.arcstats.memory_throttle_count sysctl >> increments during your tests? >>=20 >> ZFS self-throttles writes if it thinks system is running low on >> memory. Unfortunately on FreeBSD the 'free' list is a *very* >> conservative indication of available memory so ZFS often starts >> throttling before it's really needed. With only 2GB in the system, >> that's probably what slows you down. >=20 > I tested a number of times during a 2GB write to a zfs partition and = the count stayed at 0. Oh, I should add that I use the following settings from the zfs tuning = guide: vm.kmem_size=3D"1024M" vm.kmem_size_max=3D"1024M" vfs.zfs.arc_max=3D"100M" Cheers, --Jon From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 20:34:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCA141065741 for ; Sun, 14 Feb 2010 20:34:04 +0000 (UTC) (envelope-from mloftis@wgops.com) Received: from juggler.wgops.com (juggler.wgops.com [204.11.247.41]) by mx1.freebsd.org (Postfix) with ESMTP id A94278FC17 for ; Sun, 14 Feb 2010 20:34:04 +0000 (UTC) Received: by juggler.wgops.com (Postfix, from userid 65534) id 91A27A811D; Sun, 14 Feb 2010 13:34:03 -0700 (MST) X-Spam-ASN: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on juggler.wgops.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED, SARE_SUB_OBFU_OTHER autolearn=no version=3.2.5 Received: from [192.168.1.44] (host-72-174-39-176.msl-mt.client.bresnan.net [72.174.39.176]) by juggler.wgops.com (Postfix) with ESMTPSA id 3CA4AA8005 for ; Sun, 14 Feb 2010 13:34:01 -0700 (MST) Date: Sun, 14 Feb 2010 13:34:00 -0700 From: Michael Loftis To: freebsd-stable@freebsd.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: clamav-milter 0.95.3 at juggler X-Virus-Status: Clean Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 20:34:04 -0000 --On Sunday, February 14, 2010 5:28 PM +0000 Jonathan Belson wrote: > Hiya > > After reading some earlier threads about zfs performance, I decided to > test my own server. I found the results rather surprising... > You really need to test with at least 4GB of data, else you're just testing caching speeds on writing. Use a test suite like bonnie++ and you'll see just how poor the ZFS performance is, especially with multiple readers on the same file, atleast in 8.0. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 21:15:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9103E106566C for ; Sun, 14 Feb 2010 21:15:55 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 179B58FC14 for ; Sun, 14 Feb 2010 21:15:54 +0000 (UTC) Received: by fxm28 with SMTP id 28so298843fxm.31 for ; Sun, 14 Feb 2010 13:15:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.187.209 with SMTP id m17mr437654hbh.148.1266182151246; Sun, 14 Feb 2010 13:15:51 -0800 (PST) In-Reply-To: References: From: Joshua Boyd Date: Sun, 14 Feb 2010 16:15:31 -0500 Message-ID: <33c6b0bc1002141315y6671e91dife7e80b926cb9d0b@mail.gmail.com> To: Michael Loftis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 21:15:55 -0000 Repeated the same tests on my AMD64 dual core 4GB system with 5 HD103SI 1T drives in raidz1 on a Supermicro PCI-E controller, running 8-STABLE. foghornleghorn# dd if=/dev/zero of=/usr/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 4.246402 secs (49386563 bytes/sec) foghornleghorn# dd if=/dev/zero of=/usr/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 3.913826 secs (53583169 bytes/sec) foghornleghorn# dd if=/dev/zero of=/usr/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 4.436917 secs (47265975 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 0.377800 secs (555095486 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 0.140478 secs (1492869742 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 0.140452 secs (1493143431 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 8.117563 secs (258347487 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 8.251862 secs (254142882 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 8.307188 secs (252450287 bytes/sec) foghornleghorn# dd if=/dev/da0 of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 18.958791 secs (110616336 bytes/sec) foghornleghorn# dd if=/dev/da0 of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 18.924833 secs (110814822 bytes/sec) foghornleghorn# dd if=/dev/da0 of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 18.893001 secs (111001529 bytes/sec) foghornleghorn# dd if=/tank/zerofile.000 of=/dev/null bs=1M 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 5.156406 secs (406708089 bytes/sec) foghornleghorn# dd if=/tank/zerofile.000 of=/dev/null bs=1M 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 5.126920 secs (409047148 bytes/sec) foghornleghorn# dd if=/tank/zerofile.000 of=/dev/null bs=1M 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 5.145461 secs (407573211 bytes/sec) Here are my relevant settings: vfs.zfs.prefetch_disable=0 vfs.zfs.zil_disable="1" Other than that, I'm trusting FreeBSD's default settings, and they seem to be working pretty well. On Sun, Feb 14, 2010 at 3:34 PM, Michael Loftis wrote: > > > --On Sunday, February 14, 2010 5:28 PM +0000 Jonathan Belson < > jon@witchspace.com> wrote: > > Hiya >> >> After reading some earlier threads about zfs performance, I decided to >> test my own server. I found the results rather surprising... >> >> > You really need to test with at least 4GB of data, else you're just testing > caching speeds on writing. Use a test suite like bonnie++ and you'll see > just how poor the ZFS performance is, especially with multiple readers on > the same file, atleast in 8.0. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 21:37:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03AB1065672 for ; Sun, 14 Feb 2010 21:37:57 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9747C8FC13 for ; Sun, 14 Feb 2010 21:37:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id C725D50843; Sun, 14 Feb 2010 21:37:56 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c90i+bey5lPw; Sun, 14 Feb 2010 21:37:56 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id DF72450842 ; Sun, 14 Feb 2010 21:37:55 +0000 (GMT) Message-ID: <4B786D3A.3000408@langille.org> Date: Sun, 14 Feb 2010 16:38:02 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 21:37:57 -0000 Dan Naumov wrote: >> On Sun, 14 Feb 2010, Dan Langille wrote: >>> After creating three different system configurations (Athena, >>> Supermicro, and HP), my configuration of choice is this Supermicro >>> setup: >>> >>> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>> 2. SuperMicro 5046A $750 (+$43 shipping) >>> 3. LSI SAS 3081E-R $235 >>> 4. SATA cables $60 >>> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>> 6. Xeon W3520 $310 > > You do realise how much of a massive overkill this is and how much you > are overspending? I appreciate the comments and feedback. I'd also appreciate alternative suggestions in addition to what you have contributed so far. Spec out the box you would build. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 22:02:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D0211065670 for ; Sun, 14 Feb 2010 22:02:35 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0337C8FC08 for ; Sun, 14 Feb 2010 22:02:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 89001508A8; Sun, 14 Feb 2010 22:02:34 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjLKaMf6Rlc3; Sun, 14 Feb 2010 22:02:33 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id A314350843 ; Sun, 14 Feb 2010 22:02:33 +0000 (GMT) Message-ID: <4B787300.2080602@langille.org> Date: Sun, 14 Feb 2010 17:02:40 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dmitry Morozovsky References: <4B6F9A8D.4050907@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 22:02:35 -0000 Dmitry Morozovsky wrote: > On Wed, 10 Feb 2010, Dmitry Morozovsky wrote: > > DM> other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, > DM> FreeBSD/amd64 > > well, not exactly "regular" - it's ASUS M2N-LR-SATA with 10 SATA channels, but > I suppose there are comparable in "workstation" mobo market now... I couldn't find this one for sale, FWIW. But looks interesting. Thanks. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 22:16:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C2E31065670; Sun, 14 Feb 2010 22:16:27 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA188FC13; Sun, 14 Feb 2010 22:16:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id B111B50843; Sun, 14 Feb 2010 22:16:25 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ+MI5SZwSy3; Sun, 14 Feb 2010 22:16:24 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 29FE550823 ; Sun, 14 Feb 2010 22:16:24 +0000 (GMT) Message-ID: <4B78763E.5080105@langille.org> Date: Sun, 14 Feb 2010 17:16:30 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Motin References: <1265617382.00216602.1265605802@10.7.7.3> <1265707385.00217197.1265696404@10.7.7.3> <1265728980.00217271.1265715603@10.7.7.3> <1265750583.00217397.1265739002@10.7.7.3> <1265754184.00217418.1265743204@10.7.7.3> <1265756530.00217435.1265745602@10.7.7.3> <1265790181.00217606.1265778601@10.7.7.3> <1265842691.00217889.1265831404@10.7.7.3> <4B78382E.8080905@FreeBSD.org> In-Reply-To: <4B78382E.8080905@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Steve Polyack Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 22:16:27 -0000 Alexander Motin wrote: > Steve Polyack wrote: >> On 2/10/2010 12:02 AM, Dan Langille wrote: >>> Don't use a port multiplier and this goes away. I was hoping to avoid >>> a PM and using something like the Syba PCI Express SATA II 4 x Ports >>> RAID Controller seems to be the best solution so far. >>> >>> http://www.amazon.com/Syba-Express-Ports-Controller-SY-PEX40008/dp/B002R0DZWQ/ref=sr_1_22?ie=UTF8&s=electronics&qid=1258452902&sr=1-22 >> Dan, I can personally vouch for these cards under FreeBSD. We have 3 of >> them in one system, with almost every port connected to a port >> multiplier (SiI5xxx PMs). Using the siis(4) driver on 8.0-RELEASE >> provides very good performance, and supports both NCQ and FIS-based >> switching (an essential for decent port-multiplier performance). >> >> One thing to consider, however, is that the card is only single-lane >> PCI-Express. The bandwidth available is only 2.5Gb/s (~312MB/sec, >> slightly less than that of the SATA-2 link spec), so if you have 4 >> high-performance drives connected, you may hit a bottleneck at the >> bus. I'd be particularly interested if anyone can find any similar >> Silicon Image SATA controllers with a PCI-E 4x or 8x interface ;) > > Here is SiI3124 based card with built-in PCIe x8 bridge: > http://www.addonics.com/products/host_controller/adsa3gpx8-4em.asp > > It is not so cheap, but with 12 disks connected via 4 Port Multipliers > it can give up to 1GB/s (4x250MB/s) of bandwidth. > > Cheaper PCIe x1 version mentioned above gave me up to 200MB/s, that is > maximum of what I've seen from PCIe 1.0 x1 controllers. Looking on NCQ > and FBS support it can be enough for many real-world applications, that > don't need so high linear speeds, but have many concurrent I/Os. Is that the URL you meant to post? "4 Port eSATA PCI-E 8x Controller for Mac Pro". I'd rather use internal connections. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 22:24:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6357A106566B for ; Sun, 14 Feb 2010 22:24:43 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id E6F128FC1B for ; Sun, 14 Feb 2010 22:24:42 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1EMOcxK023479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Feb 2010 09:24:40 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1EMOTug068454; Mon, 15 Feb 2010 09:24:29 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1EMORk6068453; Mon, 15 Feb 2010 09:24:27 +1100 (EST) (envelope-from peter) Date: Mon, 15 Feb 2010 09:24:27 +1100 From: Peter Jeremy To: Andriy Gapon Message-ID: <20100214222426.GB67580@server.vk2pj.dyndns.org> References: <20100201085131.GA34006@server.vk2pj.dyndns.org> <4B66A0DD.2070109@icyb.net.ua> <20100202063635.GA64643@server.vk2pj.dyndns.org> <4B67C8A6.5050102@icyb.net.ua> <20100202230511.GA19744@pjdesk.au.alcatel-lucent.com> <4B6B4CD8.8060208@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <4B6B4CD8.8060208@icyb.net.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Kernel probe order issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 22:24:43 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-05 00:40:24 +0200, Andriy Gapon wrote: >I came up with some things with which you can try to experiment: > >1. Boot with hw.pci.usb_early_takeover=3D"0" in loader.conf. > >2. Comment out the following line in sys/dev/usb/controller/uhci_pci.c: >pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); Sorry for the delay in responding. Neither of these made any difference. I have also tried asking in FreeBSD-usb and hps@ suggested trying ukbd.c Rev 43 from p4 - which also didn't help. --=20 Peter Jeremy --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt4eBoACgkQ/opHv/APuIdggQCgvek4RA2pLAdOTX2h3qpeL2Bt MtoAn3NTHKN45liO/YXaRUK+wHS2nTPP =BfeB -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 22:32:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7564E106566C for ; Sun, 14 Feb 2010 22:32:54 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3ECCD8FC13 for ; Sun, 14 Feb 2010 22:32:54 +0000 (UTC) Received: (qmail 45823 invoked by uid 0); 14 Feb 2010 22:32:53 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Feb 2010 22:32:53 -0000 Date: Sun, 14 Feb 2010 17:32:52 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Dan Langille In-Reply-To: <4B786D3A.3000408@langille.org> Message-ID: References: <4B786D3A.3000408@langille.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1293156801-1266186773=:935" Cc: FreeBSD-STABLE Mailing List , Dan Naumov Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 22:32:54 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1293156801-1266186773=:935 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 14 Feb 2010, Dan Langille wrote: > Dan Naumov wrote: >>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>> After creating three different system configurations (Athena, >>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>> setup: >>>> >>>> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>> 2. SuperMicro 5046A $750 (+$43 shipping) >>>> 3. LSI SAS 3081E-R $235 >>>> 4. SATA cables $60 >>>> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>>> 6. Xeon W3520 $310 >> >> You do realise how much of a massive overkill this is and how much you >> are overspending? > > > I appreciate the comments and feedback. I'd also appreciate alternative > suggestions in addition to what you have contributed so far. Spec out the > box you would build. $1200, and I'll run any benchmarks you'd like to see: http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=8441629 This box is really only for backups, so no fancy CPU. The sub-$100 celeron seems to not impact ZFS performance a bit. It does have ECC memory, and a fancy "server" mainboard. C > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --0-1293156801-1266186773=:935-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 22:42:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32F88106566C for ; Sun, 14 Feb 2010 22:42:03 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id DADE48FC08 for ; Sun, 14 Feb 2010 22:42:02 +0000 (UTC) Received: by ywh11 with SMTP id 11so7293464ywh.9 for ; Sun, 14 Feb 2010 14:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=RvYmbwOPr07N82E/QP2F5A4wScXHqAp/jhqwNLhXQDU=; b=e3FBh0UaeA1hBUykvORtXcEygHYOybAiG0Hc7ugFLk3khGjpRApvZQ4SdgoIGZ+ZG4 9TtFZ5sH8jMSj35aQekJ5g/0sBE4/jR6SZ8G9vnEwE43ibE+HI8acc9AjtT9LaKu9hqb N8cEwW5DXJBBi56YRl1O1hu9qOnhXDvC23ubE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=tkhLksg0Wjpaa6THWosP6KeCwqGx6nfu8h4kFhP1nZohHgGBhBsBMqitpYFhFqp5HP v4HJ/F0yblhf5QqUM+TUGq3wyfi5wlMKadNJINucDKCFSWEDS5FC3MaepVAhmOuqG59e 3n4ao4inSzL9p1HNngvXL0YLfbI5aPgw5xpbI= MIME-Version: 1.0 Received: by 10.150.118.31 with SMTP id q31mr3538886ybc.58.1266187320145; Sun, 14 Feb 2010 14:42:00 -0800 (PST) In-Reply-To: <4B786D3A.3000408@langille.org> References: <4B786D3A.3000408@langille.org> Date: Mon, 15 Feb 2010 00:42:00 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 22:42:03 -0000 On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille wrote: > Dan Naumov wrote: >>> >>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>> >>>> After creating three different system configurations (Athena, >>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>> setup: >>>> >>>> =A0 =A01. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>> =A0 =A02. SuperMicro 5046A $750 (+$43 shipping) >>>> =A0 =A03. LSI SAS 3081E-R $235 >>>> =A0 =A04. SATA cables $60 >>>> =A0 =A05. Crucial 3=D72G ECC DDR3-1333 $191 (+ $6 shipping) >>>> =A0 =A06. Xeon W3520 $310 >> >> You do realise how much of a massive overkill this is and how much you >> are overspending? > > > I appreciate the comments and feedback. =A0I'd also appreciate alternativ= e > suggestions in addition to what you have contributed so far. =A0Spec out = the > box you would build. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Case: Fractal Design Define R2 - 89 euro: http://www.fractal-design.com/?view=3Dproduct&prod=3D32 Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=3DH PSU: Corsair 400CX 80+ - 59 euro: http://www.corsair.com/products/cx/default.aspx RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Total: ~435 euro The motherboard has 6 native AHCI-capable ports on ICH9R controller and you have a PCI-E slot free if you want to add an additional controller card. Feel free to blow the money you've saved on crazy fast SATA disks and if your system workload is going to have a lot of random reads, then spend 200 euro on a 80gb Intel X25-M for use as a dedicated L2ARC device for your pool. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 22:59:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E09191065672 for ; Sun, 14 Feb 2010 22:59:07 +0000 (UTC) (envelope-from jon@witchspace.com) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by mx1.freebsd.org (Postfix) with ESMTP id 3684A8FC0A for ; Sun, 14 Feb 2010 22:59:06 +0000 (UTC) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100214225901.FTEM4474.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Sun, 14 Feb 2010 22:59:01 +0000 Received: from witchspace.com ([86.28.98.4]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with SMTP id <20100214225900.OTIU2093.aamtaout03-winn.ispmail.ntl.com@witchspace.com> for ; Sun, 14 Feb 2010 22:59:01 +0000 Received: (qmail 4636 invoked from network); 14 Feb 2010 21:58:20 -0000 Received: from unknown (HELO core.home) (192.168.0.3) by 192.168.0.100 with SMTP; 14 Feb 2010 21:58:20 -0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jonathan Belson In-Reply-To: <33c6b0bc1002141315y6671e91dife7e80b926cb9d0b@mail.gmail.com> Date: Sun, 14 Feb 2010 22:58:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <33c6b0bc1002141315y6671e91dife7e80b926cb9d0b@mail.gmail.com> To: Joshua Boyd X-Mailer: Apple Mail (2.1077) X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=e4Pwy1OWAAAA:8 a=Hohl_Ves4lfI9dadVNUA:9 a=iFOdUcapOEneXYinPzCgnvct0xkA:4 a=l7LHO80XtP4A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: freebsd-stable@freebsd.org, Michael Loftis Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 22:59:08 -0000 On 14 Feb 2010, at 21:15, Joshua Boyd wrote: > Repeated the same tests on my AMD64 dual core 4GB system with 5 = HD103SI 1T > drives in raidz1 on a Supermicro PCI-E controller, running 8-STABLE. [ snip results ] I was hoping I'd get something closer to these figures... > Here are my relevant settings: >=20 > vfs.zfs.prefetch_disable=3D0 > vfs.zfs.zil_disable=3D"1" I already had prefetch disabled, but retrying with zil disabled made no = difference. What is your arc_min and arc_max set to? >=20 > On Sun, Feb 14, 2010 at 3:34 PM, Michael Loftis = wrote: >>>=20 >> You really need to test with at least 4GB of data, else you're just = testing >> caching speeds on writing. Use a test suite like bonnie++ and you'll = see I'd expect to get more than 4MB/s if I was just measuring cache speed = :-) Cheers, --Jon From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 23:07:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFCA2106566C for ; Sun, 14 Feb 2010 23:07:28 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id C4A268FC15 for ; Sun, 14 Feb 2010 23:07:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 54B7D50843; Sun, 14 Feb 2010 23:07:28 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uswhqrGNzCjH; Sun, 14 Feb 2010 23:07:27 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id DDF7B50842 ; Sun, 14 Feb 2010 23:07:26 +0000 (GMT) Message-ID: <4B788235.6080804@langille.org> Date: Sun, 14 Feb 2010 18:07:33 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Wes Morgan References: <4B6F9A8D.4050907@langille.org> <4B779561.7000205@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 23:07:29 -0000 Wes Morgan wrote: > On Sun, 14 Feb 2010, Dan Langille wrote: > >> Dan Langille wrote: >>> Hi, >>> >>> I'm looking at creating a large home use storage machine. Budget is a >>> concern, but size and reliability are also a priority. Noise is also a >>> concern, since this will be at home, in the basement. That, and cost, >>> pretty much rules out a commercial case, such as a 3U case. It would be >>> nice, but it greatly inflates the budget. This pretty much restricts me to >>> a tower case. >>> >>> The primary use of this machine will be a backup server[1]. It will do >>> other secondary use will include minor tasks such as samba, CIFS, cvsup, >>> etc. >>> >>> I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] with >>> hot-swap bays[3], that seems interesting. I haven't looked at power >>> supplies, but given that number of drives, I expect something beefy with a >>> decent reputation is called for. >>> >>> Whether I use hardware or software RAID is undecided. I >>> >>> I think I am leaning towards software RAID, probably ZFS under FreeBSD 8.x >>> but I'm open to hardware RAID but I think the cost won't justify it given >>> ZFS. >>> >>> Given that, what motherboard and RAM configuration would you recommend to >>> work with FreeBSD [and probably ZFS]. The lists seems to indicate that more >>> RAM is better with ZFS. >>> >>> Thanks. >>> >>> >>> [1] - FYI running Bacula, but that's out of scope for this question >>> >>> [2] - http://www.newegg.com/Product/Product.aspx?Item=N82E16811192058 >>> >>> [3] - nice to have, especially for a failure. >> After creating three different system configurations (Athena, Supermicro, and >> HP), my configuration of choice is this Supermicro setup: >> >> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >> 2. SuperMicro 5046A $750 (+$43 shipping) >> 3. LSI SAS 3081E-R $235 >> 4. SATA cables $60 >> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >> 6. Xeon W3520 $310 >> >> Total price with shipping $1560 >> >> Details and links at http://dan.langille.org/2010/02/14/supermicro/ > > Wow um... That's quite a setup. Do you really need the Xeon W3520? You > could get a regular core 2 system for much less and still use the ECC ram > (highly recommended). The case you're looking at only has 6 hot-swap bays > according to the manuals, although the pictures show 8 (???). Going to http://www.supermicro.com/products/system/tower/5046/SYS-5046A-X.cfm it does say 6 hot-swap and two spare. I'm guessing they say that because the M/B supports only 6 SATA connections: http://www.supermicro.com/products/motherboard/Core2Duo/X58/C7X58.cfm > You could > shave some off the case and cpu, upgrade your 3081E-R to an ARC-1222 for > $200 more and have the hardware raid option. That is a nice card. However, I don't want hardware RAID. I want ZFS. > If I was building a tower system, I'd put together something like this: Thank you for the suggestions. > Case with 8 hot-swap SATA bays ($250): > http://www.newegg.com/Product/Product.aspx?Item=N82E16811192058 > Or if you prefer screwless, you can find the case without the 2 hotswap > bays and use an icy dock screwless version. I do like this case, it's one I have priced: http://dan.langille.org/2010/02/14/pricing-the-athena/ > Intel server board (for ECC support) ($200): > http://www.newegg.com/Product/Product.aspx?Item=N82E16813121328 ECC, nice, which is something I've found appealing. > SAS controller ($120): > http://www.buy.com/prod/supermicro-lsi-megaraid-lsisas1068e-8-port-sas-raid-controller-16mb/q/loc/101/207929556.html > Note: You'll need to change or remove the mounting bracket since it is > "backwards". I was able to find a bracket with matching screw holes on an > old nic and secure it to my case. It uses the same chipset as the more > expensive 3081E-R, if I remember correctly. I follow what you say, but cannot comprehend why the bracket is backwards. > Quad-core CPU ($190): > http://www.newegg.com/Product/Product.aspx?Item=N82E16819115131 > > 4x2gb ram sticks (97*2): > http://www.newegg.com/Product/Product.aspx?Item=N82E16820139045 > > same SATA cables for sata to mini-sas, same CD burner. Total cost probably > $400 less, which you can use to buy some of the drives. I put this all together, and named it after you (hope you don't mind): http://dan.langille.org/2010/02/14/273/ You're right, $400 less. I also wrote up the above suggestions with a Supermicro case instead: SUPERMICRO CSE-743T-645B Black 4U Pedestal Chassis w/ 645W Power Supply $320 http://www.newegg.com/Product/Product.aspx?Item=N82E16811152047 I like your suggestions with the above case. It is now my preferred solution. > For my personal (overkill) setup I have a chenbro 4U chassis with 16 > hotswap bays and mini-SAS backplanes, a zippy 2+1 640 watt redundant power > supply (sounds like a freight train). I cannot express the joy I felt in > ripping out all the little SATA cables and snaking a couple fat 8087s > under the fans. 8 of the bays are dedicated to my media array, and the > other 8 are there for swapping in and out of backup drives mostly, but the > time they REALLY come in handy is when you need to upgrade your array. Buy > the replacement drives, pop them in, migrate the pool, and remove the old > drives. This is really nice. :) Thank you for your suggestions. They have been very helpful. :) From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 23:10:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AA9F106566B for ; Sun, 14 Feb 2010 23:10:52 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f191.google.com (mail-yx0-f191.google.com [209.85.210.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1D8A98FC0C for ; Sun, 14 Feb 2010 23:10:51 +0000 (UTC) Received: by yxe29 with SMTP id 29so3512166yxe.14 for ; Sun, 14 Feb 2010 15:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iQPo6kRs4KnRa+qTiVj7DW8vSiFmnCjMBzQANZoX6C4=; b=MlasVk3J2Z3j5R93Gx2L3l5TxHbZmk13W8F0TfL9UFrmr7/7mOpX8vG2o9pq5q0h5Y wTMbPdBlotD+wRFdlak/3gvdKzbP+ULENQXpoBFUX+egAZi3EeE6bJKGoFqbvTDFZ/Wr rp/a6ux3etM6O8E+C96VB+jkEGEFfX6MN3+xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=TEKnC/F76G5tsujWTjdAsoqwo9djXhWLtuv1JQ3ihMQ6uG/5WAqygJom4lZNZAfEA4 G8zu5n6Vgwy9WRwybu5nZd9IpfKJRvgtUZSZPrFRdQsWteJC5BOntUoay7asaIAzASp+ vZkn7QMhJtHu4Za8xC65majbi0Y0scn87pRB4= MIME-Version: 1.0 Received: by 10.150.8.10 with SMTP id 10mr8281020ybh.125.1266189049949; Sun, 14 Feb 2010 15:10:49 -0800 (PST) In-Reply-To: References: <4B786D3A.3000408@langille.org> Date: Mon, 15 Feb 2010 01:10:49 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , dan@langille.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 23:10:52 -0000 On Mon, Feb 15, 2010 at 12:42 AM, Dan Naumov wrote: > On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille wrote: >> Dan Naumov wrote: >>>> >>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>> >>>>> After creating three different system configurations (Athena, >>>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>>> setup: >>>>> >>>>> =A0 =A01. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>> =A0 =A02. SuperMicro 5046A $750 (+$43 shipping) >>>>> =A0 =A03. LSI SAS 3081E-R $235 >>>>> =A0 =A04. SATA cables $60 >>>>> =A0 =A05. Crucial 3=D72G ECC DDR3-1333 $191 (+ $6 shipping) >>>>> =A0 =A06. Xeon W3520 $310 >>> >>> You do realise how much of a massive overkill this is and how much you >>> are overspending? >> >> >> I appreciate the comments and feedback. =A0I'd also appreciate alternati= ve >> suggestions in addition to what you have contributed so far. =A0Spec out= the >> box you would build. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Case: Fractal Design Define R2 - 89 euro: > http://www.fractal-design.com/?view=3Dproduct&prod=3D32 > > Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=3D= H > > PSU: Corsair 400CX 80+ - 59 euro: > http://www.corsair.com/products/cx/default.aspx > > RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Total: ~435 euro > > The motherboard has 6 native AHCI-capable ports on ICH9R controller > and you have a PCI-E slot free if you want to add an additional > controller card. Feel free to blow the money you've saved on crazy > fast SATA disks and if your system workload is going to have a lot of > random reads, then spend 200 euro on a 80gb Intel X25-M for use as a > dedicated L2ARC device for your pool. And to expand a bit, if you want that crazy performance without blowing silly amounts of money: Get a dock for holding 2 x 2,5" disks in a single 5,25" slot and put it at the top, in the only 5,25" bay of the case. Now add an additional PCI-E SATA controller card, like the often mentioned PCIE SIL3124. Now you have 2 x 2,5" disk slots and 8 x 3,5" disk slots, with 6 native SATA ports on the motherboard and more ports on the controller card. Now get 2 x 80gb Intel SSDs and put them into the dock. Now partition each of them in the following fashion: 1: swap: 4-5gb 2: freebsd-zfs: ~10-15gb for root filesystem 3: freebsd-zfs: rest of the disk: dedicated L2ARC vdev GMirror your SSD swap partitions. Make a ZFS mirror pool out of your SSD root filesystem partitions Build your big ZFS pool however you like out of the mechanical disks you ha= ve. Add the 2 x ~60gb partitions as dedicated independant L2ARC devices for your SATA disk ZFS pool. Now you have redundant swap, redundant and FAST root filesystem and your ZFS pool of SATA disks has 120gb worth of L2ARC space on the SSDs. The L2ARC vdevs dont need to be redundant, because should an IO error occur while reading off L2ARC, the IO is deferred to the "real" data location on the pool of your SATA disks. You can also remove your L2ARC vdevs from your pool at will, on a live pool. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 23:23:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 048A4106568B for ; Sun, 14 Feb 2010 23:23:38 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 264018FC1B for ; Sun, 14 Feb 2010 23:23:36 +0000 (UTC) Received: by fxm28 with SMTP id 28so45327fxm.31 for ; Sun, 14 Feb 2010 15:23:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.184.6 with SMTP id w6mr441400hbg.4.1266189815119; Sun, 14 Feb 2010 15:23:35 -0800 (PST) In-Reply-To: <33c6b0bc1002141512t29c2650cp2f2dba866b9d7415@mail.gmail.com> References: <33c6b0bc1002141315y6671e91dife7e80b926cb9d0b@mail.gmail.com> <33c6b0bc1002141512t29c2650cp2f2dba866b9d7415@mail.gmail.com> From: Joshua Boyd Date: Sun, 14 Feb 2010 18:23:15 -0500 Message-ID: <33c6b0bc1002141523q72eed878qf900230026ff34b3@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 23:23:38 -0000 On Sun, Feb 14, 2010 at 6:12 PM, Joshua Boyd wrote: > > > On Sun, Feb 14, 2010 at 5:58 PM, Jonathan Belson wrote: > >> On 14 Feb 2010, at 21:15, Joshua Boyd wrote: >> >> > Repeated the same tests on my AMD64 dual core 4GB system with 5 HD103SI >> 1T >> > drives in raidz1 on a Supermicro PCI-E controller, running 8-STABLE. >> >> [ snip results ] >> >> I was hoping I'd get something closer to these figures... >> >> > Here are my relevant settings: >> > >> > vfs.zfs.prefetch_disable=0 >> > vfs.zfs.zil_disable="1" >> >> I already had prefetch disabled, but retrying with zil disabled made no >> difference. >> > > That setting actually enables prefetch ... I have 4GB of RAM, so I felt > safe turning it on. > > >> >> What is your arc_min and arc_max set to? >> > > System Memory: > Physical RAM: 4015 MB > Free Memory : 2130 MB > > ARC Size: > Current Size: 783 MB (arcsize) > Target Size (Adaptive): 783 MB (c) > Min Size (Hard Limit): 101 MB (zfs_arc_min) > Max Size (Hard Limit): 808 MB (zfs_arc_max) > > ARC Size Breakdown: > Most Recently Used Cache Size: 97% 764 MB (p) > Most Frequently Used Cache Size: 2% 18 MB (c-p) > > ARC Efficency: > Cache Access Total: 148383 > Cache Hit Ratio: 66% 98434 [Defined State for buffer] > Cache Miss Ratio: 33% 49949 [Undefined State for Buffer] > REAL Hit Ratio: 65% 96744 [MRU/MFU Hits Only] > > Data Demand Efficiency: 99% > Data Prefetch Efficiency: 0% > > CACHE HITS BY CACHE LIST: > Anon: 1% 1515 [ New > Customer, First Cache Hit ] > Most Recently Used: 28% 27931 (mru) [ Return > Customer ] > Most Frequently Used: 69% 68813 (mfu) [ Frequent > Customer ] > Most Recently Used Ghost: 0% 175 (mru_ghost) [ Return > Customer Evicted, Now Back ] > Most Frequently Used Ghost: 0% 0 (mfu_ghost) [ Frequent > Customer Evicted, Now Back ] > CACHE HITS BY DATA TYPE: > Demand Data: 12% 12369 > Prefetch Data: 0% 0 > Demand Metadata: 85% 84375 > Prefetch Metadata: 1% 1690 > CACHE MISSES BY DATA TYPE: > Demand Data: 0% 6 > Prefetch Data: 96% 47994 > Demand Metadata: 3% 1580 > Prefetch Metadata: 0% 369 > --------------------------------------------- > > > >> >> > >> > On Sun, Feb 14, 2010 at 3:34 PM, Michael Loftis >> wrote: >> >>> >> >> You really need to test with at least 4GB of data, else you're just >> testing >> >> caching speeds on writing. Use a test suite like bonnie++ and you'll >> see >> >> I'd expect to get more than 4MB/s if I was just measuring cache speed :-) >> >> Cheers, >> >> --Jon >> >> > > > -- > Joshua Boyd > JBipNet > > E-mail: boydjd@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 23:25:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0878A10656CE for ; Sun, 14 Feb 2010 23:25:12 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECBD8FC1B for ; Sun, 14 Feb 2010 23:25:11 +0000 (UTC) Received: by fxm28 with SMTP id 28so46325fxm.31 for ; Sun, 14 Feb 2010 15:25:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.161.130 with SMTP id h2mr452311hbd.114.1266189909253; Sun, 14 Feb 2010 15:25:09 -0800 (PST) In-Reply-To: <33c6b0bc1002141523q72eed878qf900230026ff34b3@mail.gmail.com> References: <33c6b0bc1002141315y6671e91dife7e80b926cb9d0b@mail.gmail.com> <33c6b0bc1002141512t29c2650cp2f2dba866b9d7415@mail.gmail.com> <33c6b0bc1002141523q72eed878qf900230026ff34b3@mail.gmail.com> From: Joshua Boyd Date: Sun, 14 Feb 2010 18:24:49 -0500 Message-ID: <33c6b0bc1002141524r68aac008o4a2c34a644e8a46f@mail.gmail.com> To: freebsd-stable@freebsd.org, Jonathan Belson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 23:25:12 -0000 Here's my bonnie++ results: foghornleghorn# bonnie++ -s 8192 -d. -n64 -uroot Using uid:0, gid:0. Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP foghornleghorn.r 8G 184 99 191627 43 150484 35 416 98 388853 49 103.3 3 Latency 47480us 1645ms 1545ms 53943us 186ms 2449ms Version 1.96 ------Sequential Create------ --------Random Create-------- foghornleghorn.res. -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 64 22256 80 37111 99 17478 88 22686 81 37208 99 15053 90 Latency 28364us 336us 274us 27001us 321us 80123us 1.96,1.96,foghornleghorn.res.openband.net ,1,1266194600,8G,,184,99,191627,43,150484,35,416,98,388853,49,103.3,3,64,,,,,22256,80,37111,99,17478,88,22686,81,37208,99,15053,90,47480us,1645ms,1545ms,53943us,186ms,2449ms,28364us,336us,274us,27001us,321us,80123us On Sun, Feb 14, 2010 at 6:23 PM, Joshua Boyd wrote: > > > On Sun, Feb 14, 2010 at 6:12 PM, Joshua Boyd wrote: > >> >> >> On Sun, Feb 14, 2010 at 5:58 PM, Jonathan Belson wrote: >> >>> On 14 Feb 2010, at 21:15, Joshua Boyd wrote: >>> >>> > Repeated the same tests on my AMD64 dual core 4GB system with 5 HD103SI >>> 1T >>> > drives in raidz1 on a Supermicro PCI-E controller, running 8-STABLE. >>> >>> [ snip results ] >>> >>> I was hoping I'd get something closer to these figures... >>> >>> > Here are my relevant settings: >>> > >>> > vfs.zfs.prefetch_disable=0 >>> > vfs.zfs.zil_disable="1" >>> >>> I already had prefetch disabled, but retrying with zil disabled made no >>> difference. >>> >> >> That setting actually enables prefetch ... I have 4GB of RAM, so I felt >> safe turning it on. >> >> >>> >>> What is your arc_min and arc_max set to? >>> >> >> System Memory: >> Physical RAM: 4015 MB >> Free Memory : 2130 MB >> >> ARC Size: >> Current Size: 783 MB (arcsize) >> Target Size (Adaptive): 783 MB (c) >> Min Size (Hard Limit): 101 MB (zfs_arc_min) >> Max Size (Hard Limit): 808 MB (zfs_arc_max) >> >> ARC Size Breakdown: >> Most Recently Used Cache Size: 97% 764 MB (p) >> Most Frequently Used Cache Size: 2% 18 MB (c-p) >> >> ARC Efficency: >> Cache Access Total: 148383 >> Cache Hit Ratio: 66% 98434 [Defined State for buffer] >> Cache Miss Ratio: 33% 49949 [Undefined State for >> Buffer] >> REAL Hit Ratio: 65% 96744 [MRU/MFU Hits Only] >> >> Data Demand Efficiency: 99% >> Data Prefetch Efficiency: 0% >> >> CACHE HITS BY CACHE LIST: >> Anon: 1% 1515 [ New >> Customer, First Cache Hit ] >> Most Recently Used: 28% 27931 (mru) [ Return >> Customer ] >> Most Frequently Used: 69% 68813 (mfu) [ Frequent >> Customer ] >> Most Recently Used Ghost: 0% 175 (mru_ghost) [ Return >> Customer Evicted, Now Back ] >> Most Frequently Used Ghost: 0% 0 (mfu_ghost) [ Frequent >> Customer Evicted, Now Back ] >> CACHE HITS BY DATA TYPE: >> Demand Data: 12% 12369 >> Prefetch Data: 0% 0 >> Demand Metadata: 85% 84375 >> Prefetch Metadata: 1% 1690 >> CACHE MISSES BY DATA TYPE: >> Demand Data: 0% 6 >> Prefetch Data: 96% 47994 >> Demand Metadata: 3% 1580 >> Prefetch Metadata: 0% 369 >> --------------------------------------------- >> >> >> >>> >>> > >>> > On Sun, Feb 14, 2010 at 3:34 PM, Michael Loftis >>> wrote: >>> >>> >>> >> You really need to test with at least 4GB of data, else you're just >>> testing >>> >> caching speeds on writing. Use a test suite like bonnie++ and you'll >>> see >>> >>> I'd expect to get more than 4MB/s if I was just measuring cache speed :-) >>> >>> Cheers, >>> >>> --Jon >>> >>> >> >> >> -- >> Joshua Boyd >> JBipNet >> >> E-mail: boydjd@jbip.net >> >> http://www.jbip.net >> > > > > -- > Joshua Boyd > JBipNet > > E-mail: boydjd@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net Cell: (513) 375-0157 http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 23:31:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 806A7106566C for ; Sun, 14 Feb 2010 23:31:37 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 567A28FC19 for ; Sun, 14 Feb 2010 23:31:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id C0F6950843; Sun, 14 Feb 2010 23:31:36 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFph9JAoBW87; Sun, 14 Feb 2010 23:31:35 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 90C3850842 ; Sun, 14 Feb 2010 23:31:35 +0000 (GMT) Message-ID: <4B7887D6.8000107@langille.org> Date: Sun, 14 Feb 2010 18:31:34 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dmitry Morozovsky References: <4B6F9A8D.4050907@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 23:31:37 -0000 Dmitry Morozovsky wrote: > On Mon, 8 Feb 2010, Dan Langille wrote: > > DL> I'm looking at creating a large home use storage machine. Budget is a > DL> concern, but size and reliability are also a priority. Noise is also a > DL> concern, since this will be at home, in the basement. That, and cost, > DL> pretty much rules out a commercial case, such as a 3U case. It would be > DL> nice, but it greatly inflates the budget. This pretty much restricts me to > DL> a tower case. > > [snip] > > We use the following at work, but it's still pretty cheap and pretty silent: > > Chieftec WH-02B-B (9x5.25 bays) $130 http://www.ncixus.com/products/33591/WH-02B-B-OP/Chieftec/ but not available $87.96 at http://www.xpcgear.com/chieftec-wh-02b-b-mid-tower-case.html http://www.chieftec.com/wh02b-b.html > filled with > > 2 x Supermicro CSE-MT35T > http://www.supermicro.nl/products/accessories/mobilerack/CSE-M35T-1.cfm > for regular storage, 2 x raidz1 I could not find a price on that, but guessing at $100 each > 1 x Promise SuperSwap 1600 > http://www.promise.com/product/product_detail_eng.asp?product_id=169 > for changeable external backups $100 from http://www.overstock.com/Electronics/Promise-SuperSwap-1600-Drive-Enclosure/2639699/product.html So that's $390. Not bad. Still need RAM, M/B, PSU, and possibly video. > and still have 2 5.25 bays for anything interesting ;-) I'd be filling those three with DVD-RW and two SATA drives in a gmirror configuration. > other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, > FreeBSD/amd64 Let's say $150 for the M/B, $150 for the CPU, and $200 for the RAM. Total is $890. Nice. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 14 23:52:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE883106566B for ; Sun, 14 Feb 2010 23:52:02 +0000 (UTC) (envelope-from tortise@paradise.net.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 97FF98FC08 for ; Sun, 14 Feb 2010 23:52:02 +0000 (UTC) Received: from dp2000xp (203-97-234-182.cable.telstraclear.net [203.97.234.182]) by smtp4.clear.net.nz (CLEAR Net Mail) with SMTP id <0KXU00I9FUXOZ940@smtp4.clear.net.nz> for freebsd-stable@freebsd.org; Mon, 15 Feb 2010 12:37:01 +1300 (NZDT) Date: Mon, 15 Feb 2010 12:36:57 +1300 From: Tortise To: FreeBSD Stable Message-id: <275D70206D694FAEADE12EFC9CAD8915@dp2000xp> Organization: mxrelay1.xtreme.net.nz smtp.paradise.net.nz MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Content-type: text/plain; format=flowed; charset=iso-8859-15; reply-type=response Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <4B6F9A8D.4050907@langille.org> <4B779561.7000205@langille.org> <4B788235.6080804@langille.org> Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 23:52:02 -0000 ----- Original Message ----- From: "Dan Langille" To: "Wes Morgan" Cc: "FreeBSD Stable" Sent: Monday, February 15, 2010 12:07 PM Subject: Re: hardware for home use large storage >>>> Whether I use hardware or software RAID is undecided. I >>>> >>>> I think I am leaning towards software RAID, probably ZFS under FreeBSD 8.x >>>> but I'm open to hardware RAID but I think the cost won't justify it given >>>> ZFS. >>>> >>>> Given that, what motherboard and RAM configuration would you recommend to >>>> work with FreeBSD [and probably ZFS]. The lists seems to indicate that more >>>> RAM is better with ZFS. >>>> ..... > That is a nice card. However, I don't want hardware RAID. I want ZFS. I hope its not too rude to ask, and with no rudeness intended. Is ZFS better under FreeBSD or Open Solaris? (I gather an server version of open solaris is less than a couple of months away.) From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 00:09:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A7A81065670 for ; Mon, 15 Feb 2010 00:09:15 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3A58FC0C for ; Mon, 15 Feb 2010 00:09:14 +0000 (UTC) Received: by iwn10 with SMTP id 10so123478iwn.13 for ; Sun, 14 Feb 2010 16:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=8leaOxulXsELlTG29mky+CKeSTkyNeYzIOR0WXF9sts=; b=jxfONasswdiHhV8T6dACYaK7cDI4AA2qX6CcKB+O99IL3jwHX8MjLYZtd3iN1zwTV2 JdXPOX/+pJH9niVMKfbIufwC7nKJy+qX8Q6ZpesaGuKKQh/rwQCo+A/RJQaJasDhb3jR 3mpzDEmFogZ7ZGD8gf6eRKglHF5xUOpyuOTX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=PY8J5cb4pyGadDK7ou8qyds0t+lb9berbXxTV2S8JmFGlsggxj+k9KXckFZ+pfi55V R77OhXAHc2xUH3bhltnSST9D1V/ADkYql2RsyIab17MSb5ORx7I8pE3COmYC72YcE1Pa OaXAAb8Ph6pxTw+jl2OaZEkA6fbS+mbzyJYCE= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.182.68 with SMTP id 46mr1818542ibz.45.1266192554501; Sun, 14 Feb 2010 16:09:14 -0800 (PST) In-Reply-To: References: <4B786D3A.3000408@langille.org> Date: Sun, 14 Feb 2010 16:09:14 -0800 X-Google-Sender-Auth: ca3e029cca3f2e00 Message-ID: From: Artem Belevich To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-STABLE Mailing List , dan@langille.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 00:09:15 -0000 > your ZFS pool of SATA disks has 120gb worth of L2ARC space Keep in mind that housekeeping of 120G L2ARC may potentially require fair amount of RAM, especially if you're dealing with tons of small files. See this thread: http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg34674.html --Artem From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 00:22:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7CC8106566C for ; Mon, 15 Feb 2010 00:22:48 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8C42F8FC0A for ; Mon, 15 Feb 2010 00:22:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id BB2C850843; Mon, 15 Feb 2010 00:22:47 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kior83BrGL-e; Mon, 15 Feb 2010 00:22:46 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 5B3E250823 ; Mon, 15 Feb 2010 00:22:46 +0000 (GMT) Message-ID: <4B7893D4.4010908@langille.org> Date: Sun, 14 Feb 2010 19:22:44 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Naumov , FreeBSD Stable References: <4B786D3A.3000408@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 00:22:48 -0000 Dan Naumov wrote: > On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille wrote: >> Dan Naumov wrote: >>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>> After creating three different system configurations (Athena, >>>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>>> setup: >>>>> >>>>> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>> 2. SuperMicro 5046A $750 (+$43 shipping) >>>>> 3. LSI SAS 3081E-R $235 >>>>> 4. SATA cables $60 >>>>> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>>>> 6. Xeon W3520 $310 >>> You do realise how much of a massive overkill this is and how much you >>> are overspending? >> >> I appreciate the comments and feedback. I'd also appreciate alternative >> suggestions in addition to what you have contributed so far. Spec out the >> box you would build. > > ====================== > Case: Fractal Design Define R2 - 89 euro - > http://www.fractal-design.com/?view=product&prod=32 That is a nice case. It's one slot short for what I need. The trays are great. I want three more slots for 2xSATA for a gmirror base-OS and an optical drive. As someone mentioned on IRC, there are many similar non hot-swap cases. From the website, I couldn't see this for sale in USA. But converting your price, to US$, it is about $121. Looking around, this case was suggested to me. I like it a lot: LIAN LI PC-A71F Black Aluminum ATX Full Tower Computer Case $240 http://www.newegg.com/Product/Product.aspx?Item=N82E16811112244 > Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro - > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H Non-ECC RAM, which is something I'd like to have. $175 > PSU: Corsair 400CX 80+ - 59 euro - > http://www.corsair.com/products/cx/default.aspx http://www.newegg.com/Product/Product.aspx?Item=N82E16817139008 for $50 Is that sufficient power up to 10 SATA HDD and an optical drive? > RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro http://www.newegg.com/Product/Product.aspx?Item=N82E16820145238 $82 > ====================== > Total: ~435 euro With my options, it's about $640 with shipping etc. > The motherboard has 6 native AHCI-capable ports on ICH9R controller > and you have a PCI-E slot free if you want to add an additional > controller card. Feel free to blow the money you've saved on crazy > fast SATA disks and if your system workload is going to have a lot of > random reads, then spend 200 euro on a 80gb Intel X25-M for use as a > dedicated L2ARC device for your pool. I have been playing with the idea of an L2ARC device. They sound crazy cool. Thank you Dan. -- dan From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 00:33:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0D6D106566C for ; Mon, 15 Feb 2010 00:33:11 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 712188FC0A for ; Mon, 15 Feb 2010 00:33:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id BD62550843; Mon, 15 Feb 2010 00:33:10 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS7F7EL4hYdG; Mon, 15 Feb 2010 00:33:09 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 8405850823 ; Mon, 15 Feb 2010 00:33:09 +0000 (GMT) Message-ID: <4B789643.7020606@langille.org> Date: Sun, 14 Feb 2010 19:33:07 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Naumov References: <4B786D3A.3000408@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 00:33:11 -0000 Dan Naumov wrote: > On Mon, Feb 15, 2010 at 12:42 AM, Dan Naumov wrote: >> On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille wrote: >>> Dan Naumov wrote: >>>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>>> After creating three different system configurations (Athena, >>>>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>>>> setup: >>>>>> >>>>>> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>>> 2. SuperMicro 5046A $750 (+$43 shipping) >>>>>> 3. LSI SAS 3081E-R $235 >>>>>> 4. SATA cables $60 >>>>>> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>>>>> 6. Xeon W3520 $310 >>>> You do realise how much of a massive overkill this is and how much you >>>> are overspending? >>> >>> I appreciate the comments and feedback. I'd also appreciate alternative >>> suggestions in addition to what you have contributed so far. Spec out the >>> box you would build. >> ====================== >> Case: Fractal Design Define R2 - 89 euro: >> http://www.fractal-design.com/?view=product&prod=32 >> >> Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >> >> PSU: Corsair 400CX 80+ - 59 euro: >> http://www.corsair.com/products/cx/default.aspx >> >> RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro >> ====================== >> Total: ~435 euro >> >> The motherboard has 6 native AHCI-capable ports on ICH9R controller >> and you have a PCI-E slot free if you want to add an additional >> controller card. Feel free to blow the money you've saved on crazy >> fast SATA disks and if your system workload is going to have a lot of >> random reads, then spend 200 euro on a 80gb Intel X25-M for use as a >> dedicated L2ARC device for your pool. > > And to expand a bit, if you want that crazy performance without > blowing silly amounts of money: > > Get a dock for holding 2 x 2,5" disks in a single 5,25" slot and put > it at the top, in the only 5,25" bay of the case. That sounds very interesting. I just looking around for such a thing, and could not find it. Is there a more specific name? URL? > Now add an > additional PCI-E SATA controller card, like the often mentioned PCIE > SIL3124. http://www.newegg.com/Product/Product.aspx?Item=N82E16816124026 for $35 > Now you have 2 x 2,5" disk slots and 8 x 3,5" disk slots, > with 6 native SATA ports on the motherboard and more ports on the > controller card. Now get 2 x 80gb Intel SSDs and put them into the > dock. Now partition each of them in the following fashion: > > 1: swap: 4-5gb > 2: freebsd-zfs: ~10-15gb for root filesystem > 3: freebsd-zfs: rest of the disk: dedicated L2ARC vdev > > GMirror your SSD swap partitions. > Make a ZFS mirror pool out of your SSD root filesystem partitions > Build your big ZFS pool however you like out of the mechanical disks you have. > Add the 2 x ~60gb partitions as dedicated independant L2ARC devices > for your SATA disk ZFS pool. > > Now you have redundant swap, redundant and FAST root filesystem and > your ZFS pool of SATA disks has 120gb worth of L2ARC space on the > SSDs. The L2ARC vdevs dont need to be redundant, because should an IO > error occur while reading off L2ARC, the IO is deferred to the "real" > data location on the pool of your SATA disks. You can also remove your > L2ARC vdevs from your pool at will, on a live pool. That is nice. Thank you. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 00:37:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 201C61065672 for ; Mon, 15 Feb 2010 00:37:47 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f191.google.com (mail-yx0-f191.google.com [209.85.210.191]) by mx1.freebsd.org (Postfix) with ESMTP id C87C58FC12 for ; Mon, 15 Feb 2010 00:37:46 +0000 (UTC) Received: by yxe29 with SMTP id 29so3545736yxe.14 for ; Sun, 14 Feb 2010 16:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=LvzECBYq/1PVSqvR1pihankVMR0/84wtxRQhxJqkjdo=; b=YLbrmLG0kEoXiawcjnmS+ISb1ihUgsNXCGAVhLCfNfFvRUd+9kjZsc96KHH3SVn4VO PWt1s4mZqkZCou9UyhIc+NmssF/EcimWrHPPqvubywrOLNoTAwv7nSEiM1SXn+DL9/HM 928VI9KUoNkzol1YVxQiAaJvFlwNRdeeqTPO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eHgfyi+7aBBG6ag4jKc7fng2YXVrhDE60qzktETiQXQGtDIGzpjwji3IFIsu5nQBPK lbuRUEhQRC7GEPh4QLb3kvfNdhevDqMFD0KvoC+8lj62Lkt3FAFZIEyKIn4IegNu1gb7 UqKi0Ustxz9J10GR7+kqCzSHoaICVtFSoR/e8= MIME-Version: 1.0 Received: by 10.150.118.31 with SMTP id q31mr3705344ybc.58.1266194265519; Sun, 14 Feb 2010 16:37:45 -0800 (PST) In-Reply-To: <4B7893D4.4010908@langille.org> References: <4B786D3A.3000408@langille.org> <4B7893D4.4010908@langille.org> Date: Mon, 15 Feb 2010 02:37:45 +0200 Message-ID: From: Dan Naumov To: Dan Langille , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 00:37:47 -0000 >> PSU: Corsair 400CX 80+ - 59 euro - > >> http://www.corsair.com/products/cx/default.aspx > > http://www.newegg.com/Product/Product.aspx?Item=N82E16817139008 for $50 > > Is that sufficient power up to 10 SATA HDD and an optical drive? Disk power use varies from about 8 watt/disk for "green" disks to 20 watt/disk for really powerhungry ones. So yes. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 00:55:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C36E1065740 for ; Mon, 15 Feb 2010 00:55:02 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 64B158FC14 for ; Mon, 15 Feb 2010 00:55:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 0949B50908; Mon, 15 Feb 2010 00:55:01 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJIDzQy134AC; Mon, 15 Feb 2010 00:54:59 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 990D7508E7 ; Mon, 15 Feb 2010 00:54:59 +0000 (GMT) Message-ID: <4B789B61.2070600@langille.org> Date: Sun, 14 Feb 2010 19:54:57 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Charles Sprickman References: <4B786D3A.3000408@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List , Dan Naumov Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 00:55:02 -0000 Charles Sprickman wrote: > On Sun, 14 Feb 2010, Dan Langille wrote: > >> Dan Naumov wrote: >>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>> After creating three different system configurations (Athena, >>>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>>> setup: >>>>> >>>>> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>> 2. SuperMicro 5046A $750 (+$43 shipping) >>>>> 3. LSI SAS 3081E-R $235 >>>>> 4. SATA cables $60 >>>>> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>>>> 6. Xeon W3520 $310 >>> >>> You do realise how much of a massive overkill this is and how much you >>> are overspending? >> >> >> I appreciate the comments and feedback. I'd also appreciate >> alternative suggestions in addition to what you have contributed so >> far. Spec out the box you would build. > > $1200, and I'll run any benchmarks you'd like to see: > > http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=8441629 > > > This box is really only for backups, so no fancy CPU. The sub-$100 > celeron seems to not impact ZFS performance a bit. It does have ECC > memory, and a fancy "server" mainboard. That's pretty neat. Especially given it has 4x1TB of disks. For my needs, I'd like a bigger case and PSU: $720 without HDD. https://secure.newegg.com/WishList/MySavedWishDetail.aspx?ID=8918889 My system will have a minimum of 8 SATA devices (5 for ZFS, 2 for the gmirror'd OS, and 1 for the optical drive). Thus, I'd still need to buy another SATA controller on top of the above. Thank you. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 01:25:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 445DA106566B for ; Mon, 15 Feb 2010 01:25:04 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 940188FC21 for ; Mon, 15 Feb 2010 01:25:03 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o1F1Oxmd005744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Feb 2010 11:55:00 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Dan Langille Date: Mon, 15 Feb 2010 11:54:55 +1030 User-Agent: KMail/1.9.10 References: <4B6F9A8D.4050907@langille.org> <201002141735.18275.doconnor@gsoft.com.au> <4B7803B9.1040102@langille.org> In-Reply-To: <4B7803B9.1040102@langille.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12295894.KgLGvQPujE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002151154.57022.doconnor@gsoft.com.au> X-Spam-Score: -3.639 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 01:25:04 -0000 --nextPart12295894.KgLGvQPujE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 15 Feb 2010, Dan Langille wrote: > > I priced a decent ZFS PC for a small business and it was AUD$2500 > > including the disks (5x750Gb), case, PSU etc.. > > Yes, and this one doesn't yet have HDD. > > Can you supply details of your system? 1 AP400791A 4U Rackmount chassis (no PSU) 1 MB455SPF 5 drive hot swap bay (in 3x5.25") 5 HAWD7502ABYS WD 750Gb 24x7 RAID 1 GA-MA770T-UD3P Gigabyte AMD770T AM3 motherboard 1 CPAP-965 AMD PhenomII X4 AM2+/3 2 MEK-4G1333D3D4R Kingston 4Gb DDR3/1333 ECC RAM 1 PSS-PSR700 Seasonic 700W PSU 1 VCMS4350-D512H Radeon 4350 PCIe video card 1 FMCFP4G 4Gb CF card 1 n/a CF to IDE adapter Note that I haven't actually built it yet, I don't expect any problems=20 though. I built a much cheaper version (non hot swap) at home using a Gigabyte=20 GA-MA785GM-US2H, Athlon II X2 240 2.8GHz, 4Gb DDR2 RAM and 5 1Tb WD=20 drives in an Antec NineHundred case. It boots of a CF card too, but has=20 onboard video and only a 400W PSU (which is probably overkill, steady=20 state draw was ~110W) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart12295894.KgLGvQPujE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLeKJo5ZPcIHs/zowRArRGAJ4wNkugVpvLxpHSZ+Ew4b26R107igCeOMST eG/0SUcNznC5aFw6E1jqS6w= =oSfo -----END PGP SIGNATURE----- --nextPart12295894.KgLGvQPujE-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 05:46:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB37106566C; Mon, 15 Feb 2010 05:46:39 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBAF8FC13; Mon, 15 Feb 2010 05:46:39 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 86D1578C4D; Mon, 15 Feb 2010 14:46:38 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 54A9978C3B; Mon, 15 Feb 2010 14:46:38 +0900 (JST) Message-ID: <252B63EC396745F7A6AE9E622C215437@artemis> From: "Daisuke Aoyama" To: References: Date: Mon, 15 Feb 2010 14:46:35 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01CAAE4D.ABED7060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: [PATCH] VirtualBox headless VNC support by LibVNCServer (20100211) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 05:46:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0028_01CAAE4D.ABED7060 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit Hi, all First, thank you for using my patch. This archive contains individual patch files and modified Makefile. Please select options you want before building. then make with normal way. What's new?: Send ScrollLock when press Ctrl+Scroll or Ctrl+Pause. Fixed 16bpp mode have incorrect settings. (it may cause the viewer confuse, now is send 32bpp instead of 16bpp) Show port 0 when VNC Server disabled. Code cleanup. # cd /usr/ports/emulators/virtualbox-ose # tar xvf /path/to/vboxvnc-20100211.tar.gz # make config # make It provides VNC server for guest OS console access in VBoxHeadless frontend. Supported Options: -v, -vnc, --vnc on|off Enable (default) or disable the VNC Server -a, -vncaddress, --vncaddress IP address the VNC server will bind to -p, -vncport, --vncport Port number the VNC server will bind to -k, -vnckeymap, --vnckeymap Keyboard mapfile (default: builtin US) -S, -vncsecret, --vncsecret VNC Authentication secret three options at one line is an equivalent option, for example: "-v on", "-vnc on", "--vnc on" are same feature. -v option specify whether VNC server starts in the machine. default is on (enable). -a and -p options specify IP address and port number of VNC server. default IP is wildcard, port is 5900. If you have multiple IPs(NICs) in your system, you can select the listen address of the server. -k option specify the keyboard layout convert from VNC keys to Scancodes. default is US standard 101keys. (I tested only US 101 keyboard) If you want another keyboard, you can spcify the path of kbdmap(5). In standard installation of FreeBSD, it's located in /usr/share/syscons/keymaps/. for example, "-k /usr/share/syscons/keymaps/jp.106.kbd" uses JP 106 keyboard. -S option specify the password of the VNC server. However, it have security risk in common server. It assumed used with FreeNAS (limited user environment). Please consider the risk by using command line. When starting the VM, the proctitle is changed like below (you can see by "ps axww"): VBoxHeadless: VM: TestVM4 Port: 5900 Auth: off (VBoxHeadless) Regards, Daisuke Aoyama ------=_NextPart_000_0028_01CAAE4D.ABED7060 Content-Type: application/octet-stream; name="vboxvnc-20100211.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vboxvnc-20100211.tar.gz" H4sIAODbc0sCA+19+2PauNLo/hr+CpU+Agkv8wpJmp4lQFJu8zpAut1vdz+uARN8Aoa1TZNsm/O3 3xlJtiXLhiTtnrPn3Hi3AWZGo9FoNBo9fapfG2NzavzwJz6FQqFaLhP8hCf8WSyUSxrRtFKpWKyU qsUdUtCK1aL2Ayn88C94lo6r2yCKPZ+7q+huJoYxXV1IqXD/Ic9LcmbckMXcdh0ynE+nxtA15xaZ cbMg47m9t/HZtN2lPh3Mb7Nzx0i8JE3dNcjQNuBjtLexUSwUdrOFSrZQBNxPk/kMYBuHhm1NdHtE juy5MZmawwl5OzKG18aPg+nSmJpjI6e77xIvIcmrI9swDrvNPSZI3pgtp7o7t528nHP+lIuV+Uy0 nFYlxYJWyBe0fLFMiqU9rbZXqpEBSEVatwvyCngnLs47vbP6aesgXIhmu9v72Op02+dnBxulnJYr UtpO62ObwbREo95rHZ932q3uwYYvUuK03u21Ov1uu4fwiesu9vJ5d7bIDSf20nAN2zUM+J4nvyY2 PPQYyjdwRrmlZd7C96U1MnIjI+/Ml/bQcCTSkenoDnDRQburWM5M257bufLAdHM3IRbTYc5ZWrnh fCYoMP/qy8fD80/948tWt9eHot/n966WBpj/aGRipTtUJ0ftEyzXR5buELT16ougq/vsebf16kvr U69Tb/T63cujT/fk1Zfjup/2PuEhz89Ofn4cp0TiJRgcAR0Ml46DhriYGrpjkCX8Y1UAwB+5ueTm 9hVUR/usB/9aHahiKKaEbJyfnrbOegcbdXJlWKDUaXaxtBdQ/2S8nE4J1475h2GjpZPbWpWgzd6A 9hOJw8v2SbPfbF20zpqgkjvdme29+oJW0m22QX0j47MxzSOYal93atUIPPwFrkhw60zdhT0fSkSu cUuB+ak5QAJKeT27juB0fbg0p6PESfswEGphXeUqEu2VrS8m5tDJA8rPNldcn+lwaU9DvMbuIo/g ROfyLMgzPwBfmZ/NR8spGC8qfWR/zl3PpaRxbTh7DQkTiZ86H7qdxsHGxqsv8JWmkAwFGXmG0gdD SaAx9Y/OO/16p/EehDBLoFV9NqqWE5fdVv/47BwbOZTHHE0p5PB/2hdFqDXDoT8vfu69x2Yd/EZb vOy1T7B1685d37SgLUynCQHTv/hwzL0HiK8vzDDS9yBariDhzs5bx8fts6NzlmPifb3bb5yfHbWP LzstBvN/QpGOu9sH2eyN6U6yV8PhQfLVl0bjPkk80PY2BX36dJ+kwp80WeIDUN9Fp3XU/nSPVSmo OkHZn7QbPSjeYDjM/lLI7v62RUKV4bf9bGkrkUD/cNw5v7z4GyswtDpweBTabgJst1igv/pHnfOz HjOGj1Bf7w19BKbASAMHQ6UT6jGR6F4e9rmDWVxfZT2NU/gJ6O5gg5XmwC8WtUxfrgPmw+h3AdVu eoh2E3I5v+hBdpDH33tlkqSNhqAeCf6G3shyDWuUJOBdkEOzdXh5LJGNjMHy6sqE5uPczQbzqQO0 4zElpmWrN5ttmoOU6hh9Kal7Cg3SNA8vZcpm9nDpEN0akff1E+IsF9jr+fJcXJ50W/XLZvtcSnSx nDpGfTky5wHnT5om0eDvMLuzE8j8DPzmZ4NMdetqqV8ZChG4lI9nDYnXiTkAUNewP4NvFOgTiZxp DafLkUHeYpeG8Nx8Qcucm12/gy4XaxL8+eE2VCdtddQYoEr9H6zugt+XEnavm8/l+/n7QOOcQaj/ SiQ+nH7oUy/d+/kCWpVt0N6Cgr0GQtNA+S7qvfd9UBCwOTlv1E8O693WPeHW3GpBj9FHh/TqC/zt U2TeuXMoq6OT+nH3AAs+BtsYm5YxSv3UBmkve30wqTR584a8CCNA7+nEYef8Qwu8A60FrkRiG78v TdtwqDmOuTnmSGdpkU2MuyAOs8bm1SbRr3TTepHIAdocR2cPBYrOHuUKshdzCvIXzOUJ2feZ0aTF /ghq/LM1dKjRSL2BZbjooHykxPVFVKmon+s2Tw42HO7QP513oD5voT9ysKueLUO+aPsAfdHhUYvg JySlnz1olefHJ5JVohkkkyADNKkINzzAVpCdeE5NSfkjBFYzw3JJcnUxaB2g5H/n7rCcgG9n4Dh6 9bNmvdNk/QDAIE65OD+DSAWc1tXSJKCum7l9TWbzYZ9KQ5am980eet+m4KKWpuMm2sjxBHqddoP6 PeSq6MbvXaUCgYyrVIHR6GBqZH93y2qyGD1IRiI7zHRC/s26D+o5fcfZV9p5znTmCSHCxH5F5nMf jmQ7gO1A59cCHWNgt4CObG7pUxpIzq3pnUDRj2OaOGr1Gu+pLg42souOLakgVBJfiatoHqIx2h+l A8cDbFggSn0c7ZvCfo8BV9oidkLhpjoaLJ2slitFBa2AWmsUnCgm137QkaVXMFlgv8azksWjmFxB kk7HDjBPMfTr6kJTHyzWBwCiK4oiYmrn1ZfzrhfCkLdkhw7wfd/anIMnteYuuM3ZAkfM0KXyIQip 5j6FOGHwek8ODgiGr7QaEQI2ygeIMACR5GoDWSCxSs85RqSJLIzScS9sg3Xa8CULNW/fuRPwKnt7 YXmTNNROMj0bt+B1nFR+6djo1UvFdGLjRxjKNd6f35PNjte/lIpZGJ2CmxrAaNYEAI/3DHBnMAK2 ScAgtylyaM73yHDE0I493KfTEYQ6vVLR41Iq7pPpiHVWJPuZZGck2xFYMo5HdTDCe08FniZgBOhm F7o7nOyJ+VK/QwOF+sVF/6LT/ljvtajGyQGJi7Q3yTtCBzEQONznT+ZDfdqgQuVgFBfNvfu+3gG/ A+beXc34MZxpm4NxGubw/biGtUE5N+vg1KA5PpVX87zBCo5fnsCIFpV3eq0OcNKewgC/NTsfIflT Up+1ekcnvafmDanrzYsnZt2DTqUBEWr3YE3q2JAtki0fBKwvkdeYYuLRaO6A6Qc94cNyQEadVvvs 4qTeaPUbp817kjXIpvOVtXJM9FUM579C1IpjhoBxwFPIjfmMpW2EiNn8Sn5pma6T/90thZKF0GWK juTgjK6dPLbu5kkEEXg0bJNO/nYBPlqr6eX8Atzu3MpfGVaffe2PjIWTW9zFq+DXV68+0BAA2k// sH2Wh4z6jjH6GjT8gWn5UNBMhAKY36eOdW+FtpHRQHcm7Bt8htVsWJ9zziSRGM19ZuC/fTyOUGBg BT0JI2S/g1EaziAGtejJzUloEHRPeXPPD9xffTmlk0aCM0pspMQ88/Olm2ccaCfGv/tRE8sGago/ R9Dn8fpgsjXOYTgKw0Lmqu9J0hxNiaPPFjAiSAqZphOSLJ7meUcrzsd8H+k8zjFSbiVXChEjbWjm 6AmSxomTc+ZkK3c1hD92gUZIcwtiEicZm3t6VSgXVe15a+o8WuT54B/CdCM0ZmASW4bfZ8lQfmk/ kIhSJ+gjkcNBxxhCFToGPdUtnHXBr2cGjHQWDXfq/Wq+b1ywAevHBv38dAGjwfZFo0n4QMgfxN1j drzbg/74/LhTP71/rE29+jKOr/s85nACYW7WGccThVggV6oQKHMiVPLo4kYWrPH+9BxcTrmiaauz jstL0LKiSyGDws4jMlg3nF3fnPLBoFSoPbQmasUQtlOrUgafD2D4sNoKyJ+UhzpAp8NxvwE8zat5 IwEbWx30JdQefNOGOBHnu6Nlo76DzRXSPorPzDuGu1xAj0n8SWXsz4LKYSlw1Q465u/YX/C+e6VD VvKmhiMWIjvjw0eQPDIFz4wPXYKOEMrYbUEj+njPe1hI/OGYa5L/whWMe3Jx3u1lOSKx0kE91iVB qPcTWCGuoO9JE/QPbGV0nNY+a4punWTdu4VBRiS7sE3LLZCvgPyEkweAKhC/Ne9UKlL6+M7vWznK RXgMtxWzg1H+w5notpE3h9j6JvAxndv5cu22XMvriwVr9GE3IoaWWGF5b5XDEbs5cwaV7OTPuy0B 2i/XFrc5XCt8sASYA6ZYIT3QTc2hHriptRK3PY+Qd+ZT3TbFdcPcyHCu3flidTYqvTiOaNR7vDmc trrd+nHrPnpCBJoXnRH54f+PB3dTOPk/N49CoQDNIG7/D/uB+3/KQLVTKuP+n+JO6QdSed7/8y+q fzoVloW2mMW2mPW9R1Zc3c16u29wTPv99n9BbZcrcv0XS5Xy8/6vf8mTzWZJVK8h1HterPfc3Dav 2IYvrZjVdnDfVXFnr1LNBW15u7BbKCS2t7cfxXkDN3NlC1q2qJFiYU/b3SvvKEx//JFkK8VMlWzD X61IfvwxQUSO/V7r9OIE5ynJ3gF5lcJJ7FQwCQVRWbN11j47TmcQiHuHGift1lmveXISgrQ+tdIh 3s3WUZew54CvHB+dXrSOQ2Td88tOo9X1yAJMbrhYJLbNMUQCJDztltiOyWv7YC2tnyHSnjWObH1m DJbjsWGzHOOpr427mb7IDcM0dGaa5+6v2ZI/yD8WxlVim3WqJFyQj53mRYI8pBhRlKJY4RL88Pz8 Ffx/2Ja/j//XSpWdasj/l0vVyrP//6v4/3C9f98+IMyd9wPAuECKxb1yMa4fKO9gPwB/QQLsB176 0TzNzrDt3OSdAsY/H82RMafIxPbLOH8sIrif336J65ZhGHOH234+yZAPniR9Zv0+Xxru94UEb507 J4/DSQdlEuBLy3TcEQPSXEh+S+RBtvIiRlnKQTQqQCmIoJQh5ABDW0lRQ9CdNX9HtVyqVFHNpSro uUT1/CVBPXqnd4Ej33EqeenAuHLvVyuZINKThH9ZJwP/oIm5n2fwzftK3lqgoK/LpTl6B1RdhJIr 87NhkY+nJMW3KI2Ibl8tcRU7jdzj60rN9jNkBj0XZgkfZG59xU1zoadl4RYEkgKm+nLqpgnbe0yB 7sTAzpSwHXA0ezUXneWij0Y2WC/PjP8ib80Flo20L4gH8pjyDvXGnE4JTicRdx6Tw4LlgGNTzp7u IXuLf995lBcIspazAfB8fBbXLAsWC/BM2A/yln1CRh+Mu8Ecd/PDT3owwFPaHl2Xd02LXHbTMTl0 WQ6OMbQNrxjsB9g+/YQcUOj6EsS3XD6kJwzHqn6llZOXMcFItF3YI1ZO+OSW8ZXvI3igXQDzaHN/ 2MPrBrnOrU2XDCe6dcVYO4YLurxC7tTHFZmTK1e81keLa9y6hm2RZCNJmq3GSesT7pAhKWiOadKz oUszRqc6VAlCsA1BO4A8bLK1BT8++z8M6/MijQ16dctaWo55ZUFrRG5QddTcDkgFHPE+o8CZIpdz BYI6N/cDcnZ5chJNw3Q8WknzgVnhKpIuMyOf5Ol2IjEGy+ClZHwjKcLFpBVWY6OTArjLGqsweL4E pvKFJD0nmMyQTWczA570uNU7v+j1O62/93FX2tkxuc/ISR6YZr2LRGbciyCvRZjXZfusVypSXlL+ T0gT+EJMpa+QOpzTE5JBKiT//IhcHkPv+0RMdP2ITB6fyneOmKj7iKwelurbPCkVEGw/1hbi7PeB iegAv1SibWinkCmW/DYkPiB/6oU5Sici3SuGFjj01qdL49KCjiS3cP7YV2kHtqFf7z8wrBjiMSSQ fC/UwcETuEQhy2WpuK+SelmqnPUYzoGTCZfnEcw/xzAPnPA3ML+OYe5772/g3Y3h7bv9B/P+9gAi sADFkoT+IiwQGnRVK6BBV6vljFaNNGgozBI69KwmmOl9gn+sHaNIwwqvfQjV+4L1UOTNm8T2RuqF 49rD2UIgyJAkxEDJNPn6lURiefCTTKfTGC1sQJSCx8dc050aqeTH0z3y2qFRKHwZ0SgOIdDUU7Qt 8vzT5G+sbe6RpDW3DMAXvKx5zd0T3Oj6ffPgzTNDVcINR6BOzq0kUktiPH3ARaIHXF6tLKd0aPiT OXIn5C2paEVUugR9R4qFck0BvybFNLWmGhuR7RYLmXIt0pq4zYuWtMKINg7Pz0/IGL4H7sC1lwbo gm7Px+HsIdlayMNaOSqTwsRlF3RsWG1khBEi8Ik2yDRgvshNFrQqDthQ34rj/xb7VR2EXPCxDvYX ciPUJDHnyIytJD2BE4UzrMhcv6hCBINpWnr/iI5u+UNgkmI6wUFW+oFO9D74eY/1IKpRKLcgX0i2 k/kVSUHrE+Zo9tjwCI/HBePMXC6HYqX3xVzwUa3GMm5IYFapcFFoDYdSPUZ/LTwWvQf1aGKFunOi T3GjqGuQccDwaSqMEy/7bjrXR6y7S/kdH3OVjxAUmfAZ+TXybUQIpsgE/hOdZNsazwPH9xBtZ9+Z lulSryo4zyAUSX9TdSBvkx65/j4VElXuBgzU5tBrDNlnmLOSBArWMcaKKYLXWEz1u+y7ruEK9Cnf v2XCrEQO998ac0AyPgFBTAdVx9wJnSYAQm8WITXQh9c3ODWDW4h01xyYU9O9S9MsvIe7eEjG5zY8 F48dym6FhidaAToWrUx7lMRqD2B8Roc0nc8XZKKDbIY9My28DCLwA+QBcTVaX3xT/7Km1jrstKfq QkBkkJijR2EzW2MNar/2uIoUO3y/jFIBhYbzH7b+o6wtfo/1n1KxUimF13+qxef1n7/O+o9S72wF SNvdoQv2BY0UdvcKBfj/aStACv9gDUgjGrCu7VUKkWtAhQz80jLl3V10W9v5LWi2W6FFcPU8OyUC /27wgBX3QmKMf1bvkkJuJ6dRgga734YM7khTN53ltUHq8zt9ppO3Ov38cWHow0nOMnL/WLzDJLjc sh1ab8Jdm/AvtLLjoyBshEgqDnu8NEdxONqzYu8eS4BO+u9LY2nEUQS7ACmFSGMubBeFM/Sw6BSD 5zjCSYa4hBUijixe3HIXwp358NpwQwjLcE08QW5aIYRuL/Q8orgwSwfDUoxcnIU+xKPsMxqRvmSb L8nJ+XGf7k0NvvWPL9uKcvjaYRg8nV+FSy11jHypb+U6oIfkWy8QSHtKf5+5cGQKt91Ch3jW7bdP L0767e7lBT0Kq/Ub7ZQfQ2dIW+5AgR5XBfqNk3q3i3eQBLTpYL0ysQ2ezzVhsDEeHM7nUzKaL26G E2N4nQJIY2qC9Vy4NhlOM8LM9xaMTZwF/ITYEJcDpoaFHSpn9XlujpCPa9OVh8HSdefWqe5cM+Jb 9nGXIaEcVBbXg1EqEOzGokkgsO7ezTBGho9IJoltv6h7e/7XFBSbRxOYvz3kvTsECkfT+Q0Pb45C qcRgwR5CXNDpNWzThUDabWOA/GbWv1yMwEWcgM16hHUHwjL31LlKYZID8hH03+9eNhqtbjdDeDyM dzHMQuxeiNnN+izElIORWd8JrXYwqL82F4KfzvG0ewgIdXMLMPrlDr7glNP2fUhz/4xSnawthVKU H4Mevwz+XAvO6kCddSdLF6uU+WKfLkN6ncsWcqCnm1MptISttIfOvuObes/A1FdQ0Wjv0I/GaYYU 1YBw0Fou/PwoNlrRfIgRVFATYknXUGuc6m2ANiqohI6exLUiNpKSVtHYeq5IxJc8ZEu9oTM/B6Ra LmTIxDCvJlj55Rr8GixwTriWIc4C51hLCIEv5X3Bzmc6VjXEVxlyJXwf+N9FYmdijpG7VgVq7wfw H3jfCwL1CMvUh8bvrcrRMlCoPwUg6BYq4dhw2c8UKjpD2F9aQK9otFC0QLQwnjH5eVFFkG15wo/8 DadeAEuhabJHCmmg0cTEkDBFnVd6RmcDUj5L0WA5aTA1xSdlxSkhpJOnG+lUpbVgw90Rq2qffYb1 DyT12kknM7RjiprpXJNcnJYUFSs1CSijp36ZZsHmpfFDKIS3I4EXF6T4+tWbw/K3MyS3kmmkKMSg ISbD/zgR00WQ8dR0INhrQ8Rnj7EzPiAT6A2mqfZZvdns9OtnP0foYlVy7Oj7mLsnQqxeBCeg1D1r U1tec9oSTU30WyEuK81iZswcw41OSie5o3NNq5Xl2vXRiEZuWKHYkyo00DVKNPBboXHoZ1N3dSw/ 85HuxHQUQn3pTi50x7kZycReX6NKiMRze9TASIHJyKIGr6ccD7A7Czl3taRs9uJoDk7Kzdm4XwF9 Erqs1aRXCGPEV2uJ8aZJRjtYSwsydLmnY77wAXJ4Ca4ekABl8egHIj1orLO0aH2ezOcLoUPMakGn yGmZ7fHp+cjuR5iLFPsXFm8K3QuYOpL2GaLv4rRQilOhe+PtOcLa72NlocGbIIs4BykKw2wrEEaI bHyzi2PoTe415jOI+962+e935A3/FrDlgOw7iKOPW71eq5PyYqV0KoibcrpzvnQvdGizqbQayL0I KIMI7ppDxKgnIjsagmFe9Mv6jChZkMsMf3pZ3H/PmN3XkbDCMx5g+/cBW+nh1PMkokeRuny/3riT HQ+y766EWmemi+ObAkvGu7okS3jw2oHiZXitp/eD4Ylno14GvLfHbohCfin8hsDNXwubglOm170E 7aplDe27hXt45xpOCkuD7q4xwXNm1pUhZut7f2OGfVwEbaBD1J/YQiAf204ldXnzGp/ypqE+LyVy ncwdlwWmqsRyw8KWH6r2J4+vvr26veZGLfQd8cYWvL7pT38ils426wNoDEvX6LIb5oyRGD6iS4Zu cXTHP/9gn6xAjr9uGGE3UPY9cnvwGtriHf07g+LDF6pgUMBdRlBLlEEFWPKGFG4LGpqPl/HXA1ay Q/q7C1o3+ifG2GW/9+O5FNdxOTVHo6mxlk95HZ8Oxg9r2dSQDdVqVosn0wo+meZ3MTTH7DuI1+vh Gky9USpVbDsqkrYPzvBiyayEdnQe6xSrsdEfGaH6I8JCOmaCkWsG/97R0Z9geGCYqQBLWxeddseh 7gtUAS7Q0vEu/cXEoqMDtMNU6pZkKfc0xGVaFZp1nmh0byMjuqNEd4zoLpooqpCp0S2aeFTxNu55 ERyhCKgLIaSNaPhPmRX5fk3f6wXfEWHGgdeDB/F9ANaYM9St4XxkxLVlLAJtwyD4wetb2oQRBmM6 DQdyGV6oqGbMMOQtNeMCVrDp6NPFROcYvlOFkx0Qdz6d30BEGnAUPK5zY7rDicfUX7ilO34+fejX p26/s4cjNV4gQo9OOXezogdJcbITWrueNqhBdD2Swq1RWIF+wYvuZ/IVylYrgCI8CE0srol6AkLk 4drz6UOE9Ej/PYLSZeGQkIXbov5nyyJlV9r5dxT9EGHr6wdi//kUqofPMP1LxMSmqcnSfrjoF/bE 9rNZ2NwnV3N3Tiwcz0z7QuMOJdTkhNqDExblhMUHJyzJCUsPTliWE5YfnLAiJ6w8OGFVTlh9cMId OeHOgxPW5IS1ByfclRPuPjhh0xiaQCEnz8UnF327d6wE0nLGIfo1TSjw7zQG8CnfeuE63VqR97qg pXVtYVuhNK+hB+aRpNebYkNiHXYQjMgcMAcvOTl4F8XEE0JgR3sdT7Y36JV2xh78m9r0vRw/dHvN 01bv/XmzfXohDqSDISrdXZhOXZ6cnx2TLTpPtWbOH0JDmig84//CSxza1drqt88+1k/azXrnmJNv eTPbLF9h/p4i9qWBULd//mH/weV5T2fY/AKxCbf1JWLJlCL5yR9QJn+CXikUwzy+VNgLrFuBQRpR 7GDVooVzp9HLVI+Q4dKaPkAKRhUtx4mhfza+WY6ghr19aKnDn3stPNMUXjqJq2OeUKnkgMEDatmf OSc0/5i1p28p36HpOheGfWHeGlPfjgcicG1JRRZKcUOsHlBmMUWUfYv4byo5TtQAoxPTMoKSi8D1 JReo1ZLLrB5SciFFUPJUyF/BkDAVrQ0YJdbS32TtlA2bQ/ZVshBg0ozuCxmjFPDivH0GTL3SCdRE unZByLR/hDczNPqd48NvKcalYzj0HrmPnfopNF2cItpaSkC5JGHcurJI9FgacSrw6R1Jxxgt6Tux Qj1KAJfFVrHrBA+lEFZanyT2+WfDnup36ZS4K4QD0Vl6eFlsAbxOXo/0WwX9ybTao3RqCWFUtdx3 MSZAgCyXB1snFKV7mkRnc9cc37G+idcxhHDsy5335cb7IgRHnLaYIXdFf/oMpb5h66EQjd3wqTUP M/ExEwFzW4Qft2Sb3HDAHQLuADCR+N6Sd3ERE7K8XRdPUR7FNUyKD+FyF8nED5Y27tZGQZRLcR2b 4ko+EVNKrBrJJzqt9DP9+xP9+x7+QnjuTxJDhU48v+wlFlN9KrIfRXlumdV2eELKHg9Odfu6A8FO 3TmdA9w0RsJCXjjtIy0Ub9QHx9YxHPMPz0T1YBM6Awi+PENYZPQZHEBG3VUf8TAWYsflsRU7wMfw ChpMhq0HbI1Ny3QmRriFC+ANv3Uf1dsncgWzZbIOJUhJ/dYDOq6M1LfLK2+cpRziHJBSUU0UbJ0T rUaqnT1yQ+1mQv8OFgv+OaWf45nL5znZUA+NMBNSu6RwsVaDVWBxa9CNsDFo8u/cFsTWA+fT0XiQ IVuWcTMe+AJ786tS5CnNspaKe7i9/lOtVqP7aDd4Qfa9guyzgpAyXTsLRBWKsC8XYUOQfV+QfV+W XZ2sK5apLH8FUbQqFaVSrbCjh6w9cIkqikRFQaKS5gtULfnylDRZHE0QpxIS5yV96cj2BgiAi32o D7x41tBHZD72ZfrXqcdrfqqaalRLpVJRlKikSKQJEu348uwEypFkqQiiFNfWVIHZ76dP/plFYSbr 32NB95E9JMhCfZHj+yb2adO/VwzGOz3mpaRdeRnqP5jnYD5D9YzUCdBNpvEjY+ogHrU5i2+yogkf sKkK+uQz40Y8txX0x5zHQ3YfPu9YUncs0Z23tJLT8urBujioQP8PhZUigId+ikX5wUNwNvmRMRS9 8wtEElazeaDCZODBCjcFHvugLbDgxfHXtOXoRYSvG6P4tEEhhPZJ1+fBK7zA2AODIYne238lRZ0P L/2x4X40HXMwNTrGFQwy+dSZjjWlW1dTw/HKrDfmS8vXwBb72ZgvTKXoQuL1hX+ErN1HyvovEuvC ng8Nx/n4/qd6Yz6b6daIC7bgPwM5OFfI7ey8h0c3KO///PsfQ+dZvtP9v5VKqRA+/1d8vv/xL3v+ b/Knnv6bqGf/Srurzv7VyvzoX/ju24l/IG9ssVtS3veRpFM/bR1eHh21OsHBsCicePwLOrY8/Asd CkMoW3+MPj83tGG8A96IY4dT3XE8l9JczmZ3bJf0fhSqyQ6f7ysJjw7JHjtq3G102he9+uFJi54P S4WOgYEzWiwHU3O4F9r/4+/R4Tfmk3/KKP/kdqfXP+/2f2qfNc9/6rIkvnfss+4zQ9jh+XSKO9sv is/d26Ob+HF9yBi1Lejp2XUWb2xjPLTc0FYcNQN+kDsqh+ncuiJDug9eyqVpxOXidRM0EZuKk478 04M+RNgqLxQE0oTvh/E0K9dGs929qOOrQ6OqhSXxzuj5Z/o8hF/+VHiJNrRGux9Pz5dAw2ugSgq6 EpdS4WwxLwqjLsIpq3Ar0kgLW9ErW6tSi4s30atDK1KLyyiR6ygr0sprF9GLF2urI1gSiF1JWMHD m55fO62/v8qMcC5dnXHfV21PnBNPP2RSXMlWmhVLf+dJy+8zXbl2olIplDqISD9xFBGh83CMnn5a kK4I3X0s3yjh1Og3HQ5//VT0RMq3nYLcFzitPtDidWW4QXbNcZOIG0Slowrki+fp/dNPXq/ksff3 6orb7TGhf7D2dj84W3snp78KpX/DGbyhHPxTucDhzj+hq0iw/vhL7K5daZuuWFgP6mcW2uwfbPAX U1HQPrtYamGbn8FV7PnTALyhg15xG7I3wA+2hnTavW6r0SPippCI+gkdQ1PLJAgfKbonZjCjzXSc 8fS7OtyhAQaLIITB9z1LxS+FyUdFj/+N9/97b4t4wvt/Vt3/slPeKYbGf8Wd5/HfX2f859X79x33 eVyD976U8L7/EvxfWzXeq/p3vaCngKjH5XtA8Yosf3MkDv3yj73DRbnBJfpKk5E5V2FTcxB/98mK QWP8jSAxV37yEeuH1s+n9Ytmu0OSwduQ+WvRgjehZeeOwTXtJP0VnTgeLLVz59A3v4nJVr5igE9i euPsZuuofnnS6zPuQW4ynCT5vfH9pZxFiCy4cVNQC74BO1yMo/ZJK1Si3GKYHbr2NHc9GCXZ7UBr 0vxjkdMKVU4vX/aJeXIDQatAMaCGIXL3p/14XDIYOf6pbexwWGXjFCBhuCKD9N39FcxC52cimHlY mZ1XwNP6p37v9AK6I1Iu7FYDxKdPn7xpydRUH+BCbEE4aRQSUf79y2/kwJfwC96wijdbw1PwL6QG 6MBhQHrqQR9ed+ldPALBxA0IevpARHEERWEMPzag9cbg8UYPW0QO7YAvW9aPS3qh44qmgHRwxIsU 8hGMuPTdOwdy+F1EG86QUQC6BXWzkPiPjKmPZbeJUKyPH4OCy7tAAvj385mUFnGVEsPhYUQFV2C4 y4WCqTAMPTSoIGsM2cR95XF6ss25rSTUWMIL/coIZSqmPTNu1Tx3haThjCnBDiNoWbHVfgijGEvW nlQ1oN2hu6JAViyydWsMl66i+yrXb9vC/SJxiS+t0TwOB0P8WNypYS3jcEdmvBoa0PqNaRz2vTGN rRh6EilWHPAofb5fI4bEGdrmwo0gsoRGdLacBS3Ip5jSZUSmTrq02D8RGdgKuiOip+jMOX//HJuU PoKgE6/AhbO6kTMBlULItefqsgwKVi6CPmXOzzsvKIkfQsaK3l0uDDs+W4aOTf3+bmVqhu6o/qnA 2/2RFm4hhSLHFBUM91tHJQVT5piyguFe66iiYKocU1Uw3G8c7SgY7uaOagqGO6Oj3TBGK3glLSgo XwlabL+l6Efz9KMVYxMpqtM81Wml2ESKVjVPq1o5NpGicM1TuFaJTaTUhebVhVaNTaRUk+ZVk7YT m0ipQc2rQa0Wm0ipXM2rXG03NpFS70Wv3ouF+MpVTKLomUQx1iQ6ikkU/SYTaxIdxSSKnkkUY02i o5hE0TOJYqxJdGIxR8VYk+hU4hPFmkSnGp8o1iQ6O/GJYk2iU4tPFGsSnVjMUakQX7mF+FQrTEKL TxVvE/Ee5KgUbxTxLuSoFG8V8T7kqBRvFtyJSJtbgObs8rRf8Ho3PF4sMkCkJiC1MLIoIIthZElA lsLIsoAsh5EVAVkJI6sCshpG7gjInTCyJiBrYeSugNyVe1lEbwvo+mgUTp0V0N3lwLV1OdhFmi2B 5nQJg+zF9C5MkxdomuZnc2SEKXIiBTvRGyZhoxqPxB/VCBRsSMYo6HlEtcDi0AeowqMfj8QbAQFJ eBDkkxR8EnlY4hNUfAJlSOTT1IIixY2MiK8YZYDks9F8NqvGSQGn8HDJZ7QrMwoL5dPt+HRxg6cg s2AMFeJSDVQoDHfkzXhf+OWNWdZK2Wx4fotcGZZhszctzGckfkYpNDNDJ1X47IMyp0GWTj8EJKFZ CEK3FQqFiQBomchh+QpEMYM3FyigFzKolMFrChTQjzKonME7CRTQSxlUyeAFBArolQyqZvC2AQX0 WgbtZPBqAQX0vzKolsF7BBTQGxm0m8FLAxTQlgTSQOWbuyooJYNA3ZsFFZSWQajorArqyyBU9IEK 2pZB5UzcNNRqXCWjzk4xqDB/NnD1QVoiwLr4fVMB/V0GYV3cqKCfZBDWhaGCWjII68JWQR0JVMS6 cFVQTwZhXdypoJ9lENbFUgVdyiCsC1MFtWUQtoO5CjqXQRX60jgFdCGDUNG/qKAvMggV/ZsKupdB tUzkJOIKxG4mblpiJa5UoC85VEB1GaTR9z4qoK4MwmoYqaCmDMJqGKugIxmE1XClgo5lEFbDRAW9 l0FYDf9QQf9HBu3QlyQqoA8yCJvAVAWdyCBsAvsqaE8C4a3Km79uqrCkDEJN/18V9E8ZVIyZ1VqF Qb3/+uumAvsqg1Dxf6ig/5FBqPhbFfRJBqHihyqoIYN26LsxFdBHGYSKH6igQxmEirdU0JkEqqDe ZyroVAah3jMq6K0MQqPPqaB3MggVnVdBf5NB5ZjZyFWYSiY++l6HrWai5gbj4VgtZHMdqBbvgVbi dtUZvwAojrVItaBOAfpAaSRJqpo6J+gDpTkoUi2qk4Q+UJp5ItWSOmvoA6X5JlItq9OIPlCaZSLV ijqv6AOluSVSraoTjT5QmlEi1R115tEHStNIpFqLmIr0oUVZ3axmpLn39agdVknRy17rsFrUkpUH Do2NyU5RXajygKGhMtkpxSwyeRh/+OyBy3JwRgdFxbRCEjd0JjuVqCU2DxyaPiA71YjsymmFRJlb IDs7kYtyHjw020B2ahEZVdMKScSMAdnZjVhN86CheRZSK0StB3rg0MQLqWmxK3keLjQdQ2rF6HU0 DxGaFSI1VtHKzIKHiJyYILVyaPSnAiprAdW1gJ2IZQAfWpTLXYuY/feh0rQsqe3GBJixiN1CJm69 azXOryRl/mc1rijbo+UM7fQqgoVCUMpELXHFw8uRTiYOXIlwMtHAapyLWYHZiXQSceBadFOPhUe2 10ioVohsrrHg+Oa6GhfTZhlCrGXdcY20RFFSHVdVezRJeUX/w7ACA0f/bNhy+kpEFsVHk0R4+2rp 0SQ7ESTlR5PUZF8kADwQvjkgPD03XNq2wbYQ4Xu5V866bYXn3A7IG3Um7pfCb/vC1iHTchPbC912 DO+lAlPTMlJsW9RgOWa7nbeC2xAZZjg5zBA8JQD54schHjvfID62K2G7wTFLcaMwnqaHLCK2EP8u 7J7C/QkorOHfMM5etOkdFDCtxdLF18HNdFd48XjyJbvgkQzwpD8h7MQ9ngeyp96vXC4XsE8KaQkp FDR8i7AzJJEfmPI8nKIIX3D+ET9ebLJrMBfeh5iC7Ujj7wsFAaasfN4lBL/jKxVcezixU4sMuy2f 6+NmYk6N1O/kHVmw25PpK9NSW9ns7/iG1w35dLKouUCl9B0SPoLfbCSSbp5vBhdJhPl4SHFuGQoR XKjpFYKKSlK+iAsq4GJ7W5DDwWRjLGTy9SgZ3LlJb+rXpHdZ+Fei30vsX0Ty98Widf8YidAmD9j8 Auh3K7XY1qgwWAkepJj2aJiEWIeGi8sk9CILrL0F2aYXU4RuREdF0Q2mAiVeAKEUhtUmtQVfPO/a a+/FQ34TPET1DV/ntnALn19XGTCjLAHV+sctsLn9LmqHNYL/WvVwH9R9knq42RVCL3Og7jLYWymf WHHteD8HSOENV5KvY1jxRh5wir8Ee0F/i9pK6gFM6bKx71A/ft+Bx13SjIV3MS/KeoCTQMGtvL6+ aV+B+p6PCf1Ol6deD9mVug6/3heT0AuFHUMHB9f3y+PfgRtrDr5ghW8QB21g4UsSdEBe9pJYeAsM vmY0ZdJcQ9tqzd9yXCT6goJ9Ym5vB4LQ6+4VegoQ3t+Fb+iKoQq9K2UDTMY1LXoBhZ8BdhLg4fDl JzFcsLTCi74CJcaUBblvhF9ZLtxPLDWOYF+z0EIi4pLE9pBu6fdDEf7iIrEV4JmWoPVEBjfFa0d+ 5R/dCb41XsjQFS3IQ4HrXIntxrQ+DI2seei1etZyFoJIr1Cgd6+giOP5wrBSWE4wRjsp3nE6Xvjv KqPVNOZG7Lgjw4Y6TGJSYrDXsvP30lCFYSXR5kRxkT3k+MpwHbU5jNkLo4I8WdmoO91grx0Zeyb4 chNf4eMDNn+1ZIBvpNy1+XZKX+ihxJY0/zdBRMkqRBQPf6IhbvA3ytM6kQm64tt8mI5DOqMZM8UQ ndUdeT3KUeWxwsoeyVPhRnAF04Z4XzgKSy9aAukOXjv42fVfhaQUhgsp3oAF/oxemERX20EoGpzo MD5k/bB0DGYDrCqoC2pifkTEGghrDfwKJq4Z3ki2WIotUkynJXfBEom1rpoa48i0Qd8LT12CrCHf L8j3q3tCQWNnUuFvv9q+h3Cc8wOlw+aHWocKYUqlefxC88+iNkEI6JQLv+WEu+mFxhtP77tRIRRg NU8Fonl2V+WpPTJPbUWe3dBtDJA79a8E+vSZaele1+6/C5NZUyHG14CD46eaPP2qHkZ4D+YD69yv dCxMOh2UlMMlfdBgP4z3yx8eCoyH07ljgBMN3dJJ01MfzDyn5G9fBO+GVNIH5ihS4f1ZFBrKhnc9 1NpoeKi+oe9bOzqacrycThe6O/kFu72z+mmrD53Ub1L4h7zVt4PyCIH3PPyGO/H9n/yAVvgM2AZj F4ILdwx6ksbOMmyoMxJepWwIAfbKc2RS4BEKeniRhENpYrCzVrzw+6q4BrFTw5g5HxVXerXgm3gA SL528hhgspkQfCeEd0hN6K1FPxkdFXkMo95gsSall8m91D5ivKvS8BlT7jvYm/B8FxAzCo+v36gx FG0d4Xd/BKMa+TXKJmfC27gQhofrMj4QF18molIfSPEDWB9O00A+1tw1Z4spc9/hkOb+IWx5eXze vkNS0oie/z7qhYLBq76lY5TCK8YS26PlbBHlcOKci6roOEPxaz506TKfjqSZ7XEbUasJ3Xd85Xi8 Xo+Ct6HQ+IrRS3fuUukyAcsg3grlEn4VGzW5mW5a1M50+2rozWBuwY/P6dA5UO7xgoOmq6J6+vo8 4EjeeZEZT46cf9F+k5uKV1zsHZQgftXrXSmNEOwq7RaTeBPE0c1Wi7xcVDWbkMGEb8xe/RIstuKn XM/tLwUeEP62OPHVN2vYbv64GWaI+zRjWckeRz0H/MN/xfOE+x8m3/f+B0TuqPc/lJ/vf/iL3f8w +VPuf5iI9z9otb1KZa9Yy+2Uq5VyNfL+B82/78/jELrnj3nc/vvwYX+EMKfFwKNUvz9cTJcO/gPv bdzC6MYiyUaSBrLcWbFlo7VR+D6jXBGR7K/KW7hQjn1C8Typ/3uczfPz/Dw/z8/z8/w8P8/P8/P8 PD/Pz/Pz/Dw/z8/z8/w8P8/P8/P8PD/Pz/Pz/Dw/z8/z86c9/w8PfDlrAPAAAA== ------=_NextPart_000_0028_01CAAE4D.ABED7060-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 06:33:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90160106568B for ; Mon, 15 Feb 2010 06:33:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 17B418FC0C for ; Mon, 15 Feb 2010 06:33:08 +0000 (UTC) Received: by fxm28 with SMTP id 28so256820fxm.31 for ; Sun, 14 Feb 2010 22:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=PVYGsshPuTL1zPOBsjCFjFZpuwltHRdK49UvgQOKY/g=; b=PqYt8F4Id1ObC1yQ4OSd4AfzkWJQGf+gIT5f5t9pg7/saLEFyx4QatmAssOun2k1vp 4dDrDNNexG3Aok0dciw4hto+6cWPOSm0gtAnc+cgkSk0xm0hqiDk4tThnjgYUzMOfJbb W8NSWT9r06nJx68crpwhO4Ld+nhi2l25eQcGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Yhe0j13FwB8cJEiQDiKO+r9r4YOAs4jDfK3+9zu4BByFZktxs2TpDUH3uCSbx8VNQ0 l8krNRTuDto+wn2hNK0mfpg6MGKAh4TDvV5wNhd0IR9D0UEpk+Jw/4QYEXanDzUbioXH G6q2XdPJzzzNetRFNYEcjk7OEqEnYDfmuB2dg= Received: by 10.223.62.78 with SMTP id w14mr3270378fah.82.1266215587933; Sun, 14 Feb 2010 22:33:07 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm2813440fxm.9.2010.02.14.22.33.06 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Feb 2010 22:33:07 -0800 (PST) Sender: Alexander Motin Message-ID: <4B78EAA0.40403@FreeBSD.org> Date: Mon, 15 Feb 2010 08:33:04 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Langille References: <1265617382.00216602.1265605802@10.7.7.3> <1265707385.00217197.1265696404@10.7.7.3> <1265728980.00217271.1265715603@10.7.7.3> <1265750583.00217397.1265739002@10.7.7.3> <1265754184.00217418.1265743204@10.7.7.3> <1265756530.00217435.1265745602@10.7.7.3> <1265790181.00217606.1265778601@10.7.7.3> <1265842691.00217889.1265831404@10.7.7.3> <4B78382E.8080905@FreeBSD.org> <4B78763E.5080105@langille.org> In-Reply-To: <4B78763E.5080105@langille.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Steve Polyack Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 06:33:09 -0000 Dan Langille wrote: > Alexander Motin wrote: >> Steve Polyack wrote: >>> On 2/10/2010 12:02 AM, Dan Langille wrote: >>>> Don't use a port multiplier and this goes away. I was hoping to avoid >>>> a PM and using something like the Syba PCI Express SATA II 4 x Ports >>>> RAID Controller seems to be the best solution so far. >>>> >>>> http://www.amazon.com/Syba-Express-Ports-Controller-SY-PEX40008/dp/B002R0DZWQ/ref=sr_1_22?ie=UTF8&s=electronics&qid=1258452902&sr=1-22 >>>> >>> Dan, I can personally vouch for these cards under FreeBSD. We have 3 of >>> them in one system, with almost every port connected to a port >>> multiplier (SiI5xxx PMs). Using the siis(4) driver on 8.0-RELEASE >>> provides very good performance, and supports both NCQ and FIS-based >>> switching (an essential for decent port-multiplier performance). >>> >>> One thing to consider, however, is that the card is only single-lane >>> PCI-Express. The bandwidth available is only 2.5Gb/s (~312MB/sec, >>> slightly less than that of the SATA-2 link spec), so if you have 4 >>> high-performance drives connected, you may hit a bottleneck at the >>> bus. I'd be particularly interested if anyone can find any similar >>> Silicon Image SATA controllers with a PCI-E 4x or 8x interface ;) >> >> Here is SiI3124 based card with built-in PCIe x8 bridge: >> http://www.addonics.com/products/host_controller/adsa3gpx8-4em.asp >> >> It is not so cheap, but with 12 disks connected via 4 Port Multipliers >> it can give up to 1GB/s (4x250MB/s) of bandwidth. >> >> Cheaper PCIe x1 version mentioned above gave me up to 200MB/s, that is >> maximum of what I've seen from PCIe 1.0 x1 controllers. Looking on NCQ >> and FBS support it can be enough for many real-world applications, that >> don't need so high linear speeds, but have many concurrent I/Os. > > Is that the URL you meant to post? "4 Port eSATA PCI-E 8x Controller > for Mac Pro". I'd rather use internal connections. Not exactly what I meant, as it is a Mac version, but yes. At least such controllers exist. May be they also could be found with internal SATA. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 06:57:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B0F106566B for ; Mon, 15 Feb 2010 06:57:06 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4FD8FC0A for ; Mon, 15 Feb 2010 06:57:05 +0000 (UTC) Received: by fxm28 with SMTP id 28so270304fxm.31 for ; Sun, 14 Feb 2010 22:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=H2uIOH0/B178u02xpcwtqG3kzT0SzZ6s/0pALr6XdcI=; b=nZhKIspNlUs52N5xUAFeETItON1+Y9+cWEA44iOvyZMRT5tZonM8DY/FuI6CjRBUOO sYOyj62to4T8wv3PzylvslK1oQZLRvPIDbWw0SoJ+vg1ppy08ntv9JGFTyL8jXurfEgY 89w1H1tFnrBNlD+lZMZ0e/5fRgvQCMrE6J3gU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=P8JzCkPpj+qhEwwy7CT7pQAsgk0LQDQ2amsFqwt2rUMvVNyjXLrypNDMsVbAIodSGC AUyClyNyasYu15tPwDiV9YXFwYCY3kJABEQvzPhGF8bKedcaHTWgqcHW11GbXTEsqRco GfVwAxS6n2bTXziEO8yOhoiiWue6Xv1xHGW4Y= Received: by 10.223.5.17 with SMTP id 17mr5527756fat.0.1266217025044; Sun, 14 Feb 2010 22:57:05 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2861134fxm.0.2010.02.14.22.57.04 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Feb 2010 22:57:04 -0800 (PST) Sender: Alexander Motin Message-ID: <4B78F03D.8050001@FreeBSD.org> Date: Mon, 15 Feb 2010 08:57:01 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Langille References: <1266171781.00219459.1266159602@10.7.7.3> <1266196981.00219531.1266183601@10.7.7.3> <1266200581.00219547.1266188486@10.7.7.3> <1266200583.00219554.1266189602@10.7.7.3> <1266207781.00219573.1266194402@10.7.7.3> In-Reply-To: <1266207781.00219573.1266194402@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , Dan Naumov Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 06:57:06 -0000 Dan Langille wrote: > Dan Naumov wrote: >> Now add an >> additional PCI-E SATA controller card, like the often mentioned PCIE >> SIL3124. > > http://www.newegg.com/Product/Product.aspx?Item=N82E16816124026 for $35 This is PCI-X version. Unless you have PCI-X slot, PCIe x1 version seems preferable: http://www.newegg.com/Product/Product.aspx?Item=N82E16816124027 -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 07:55:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7425106566C for ; Mon, 15 Feb 2010 07:55:24 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 31FA18FC0A for ; Mon, 15 Feb 2010 07:55:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o1F7tHNn014082; Mon, 15 Feb 2010 10:55:17 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 15 Feb 2010 10:55:17 +0300 (MSK) From: Dmitry Morozovsky To: Dan Langille In-Reply-To: <4B788235.6080804@langille.org> Message-ID: References: <4B6F9A8D.4050907@langille.org> <4B779561.7000205@langille.org> <4B788235.6080804@langille.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Mon, 15 Feb 2010 10:55:17 +0300 (MSK) Cc: FreeBSD Stable , Wes Morgan Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 07:55:24 -0000 On Sun, 14 Feb 2010, Dan Langille wrote: [snip] DL> > SAS controller ($120): DL> > http://www.buy.com/prod/supermicro-lsi-megaraid-lsisas1068e-8-port-sas-raid-controller-16mb/q/loc/101/207929556.html DL> > Note: You'll need to change or remove the mounting bracket since it is DL> > "backwards". I was able to find a bracket with matching screw holes on an DL> > old nic and secure it to my case. It uses the same chipset as the more DL> > expensive 3081E-R, if I remember correctly. DL> DL> I follow what you say, but cannot comprehend why the bracket is backwards. It's because IO slot is ot the other side of the bracked, like good old ISA -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 07:57:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DD210656A6 for ; Mon, 15 Feb 2010 07:57:21 +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 652F48FC2E for ; Mon, 15 Feb 2010 07:57:21 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2C3B6.dip.t-dialin.net [217.226.195.182]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 29EC8844F3D; Mon, 15 Feb 2010 08:57:16 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id EF43D8EEC3; Mon, 15 Feb 2010 08:57:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1266220632; bh=FS1hl1h0dVHyAhTWU/iAw5ZNJBGZuoDHuyCWE7IaPBs=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=i5VPQJ/psK3Gh1/59leE9rWRGFBB73uboBb7Ngh/tv3DpZRAgokNveyhp9THInFxY xL7M6xn4ViM5nfH3hdJg+pc0Nyyg1hHhBRK2KEeQKnAvbi4KmiMRF9I9AInVmr95Am wQSR3+BjQKaybAfeBMU/jfOrgMAQBeOSm4MwdVSIA9LVIyMVmGflYVp12rsV5NahAH 5WwhLueb4jV9zW942Cc7rcUPHZ5S7/41WTiRx2x3dXY1oPThvcc0xQdkzasUH058DO 8IUJ0ARrpb7Uzv6QAzbKfaWsnixlYq6Y7eFg8TpIdh5QYn40RTXiRnKT0QTm5Fb0YO S33pfkqV8Xh1g== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o1F7vBBE061041; Mon, 15 Feb 2010 08:57:11 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 15 Feb 2010 08:57:10 +0100 Message-ID: <20100215085710.21077b9vaoqxbpgk@webmail.leidinger.net> Date: Mon, 15 Feb 2010 08:57:10 +0100 From: Alexander Leidinger To: Dan Naumov References: <4B786D3A.3000408@langille.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 29EC8844F3D.8CAD1 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.363, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1266825436.65119@X1aR36DmcEhP8x+5AiQifA X-EBL-Spam-Status: No Cc: FreeBSD-STABLE Mailing List , dan@langille.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 07:57:22 -0000 Quoting Dan Naumov (from Mon, 15 Feb 2010 01:10:49 +0200): > Get a dock for holding 2 x 2,5" disks in a single 5,25" slot and put > it at the top, in the only 5,25" bay of the case. Now add an > additional PCI-E SATA controller card, like the often mentioned PCIE > SIL3124. Now you have 2 x 2,5" disk slots and 8 x 3,5" disk slots, > with 6 native SATA ports on the motherboard and more ports on the > controller card. Now get 2 x 80gb Intel SSDs and put them into the > dock. Now partition each of them in the following fashion: > > 1: swap: 4-5gb > 2: freebsd-zfs: ~10-15gb for root filesystem > 3: freebsd-zfs: rest of the disk: dedicated L2ARC vdev If you already have 2 SSDs I suggest to make 4 partitions. The additional one for the ZIL (decide yourself what you want to speed up "more" and size the L2ARC and ZIL partitions accordingly...). This should speed up write operations. The ZIL one should be zfs mirrored, because the ZIL is more sensitive to disk failures than the L2ARC: zpool add log mirror > GMirror your SSD swap partitions. > Make a ZFS mirror pool out of your SSD root filesystem partitions > Build your big ZFS pool however you like out of the mechanical disks > you have. > Add the 2 x ~60gb partitions as dedicated independant L2ARC devices > for your SATA disk ZFS pool. BTW, the cheap way of doing something like this is to add a USB memory stick as L2ARC: http://www.leidinger.net/blog/2010/02/10/making-zfs-faster/ This will not give you the speed boost of a real SSD attached via SATA, but for the price (maybe you even got the memory stick for free somewhere) you can not get something better. Bye, Alexander. -- Crito, I owe a cock to Asclepius; will you remember to pay the debt? -- Socrates' last words http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 08:01:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 127691065670 for ; Mon, 15 Feb 2010 08:01:35 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9958FC17 for ; Mon, 15 Feb 2010 08:01:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o1F81XUL041983; Mon, 15 Feb 2010 11:01:33 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 15 Feb 2010 11:01:33 +0300 (MSK) From: Dmitry Morozovsky To: Dan Naumov In-Reply-To: Message-ID: References: <4B786D3A.3000408@langille.org> <4B7893D4.4010908@langille.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Mon, 15 Feb 2010 11:01:33 +0300 (MSK) Cc: FreeBSD-STABLE Mailing List , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 08:01:35 -0000 On Mon, 15 Feb 2010, Dan Naumov wrote: DN> >> PSU: Corsair 400CX 80+ - 59 euro - DN> > DN> >> http://www.corsair.com/products/cx/default.aspx DN> > DN> > http://www.newegg.com/Product/Product.aspx?Item=N82E16817139008 for $50 DN> > DN> > Is that sufficient power up to 10 SATA HDD and an optical drive? DN> DN> Disk power use varies from about 8 watt/disk for "green" disks to 20 DN> watt/disk for really powerhungry ones. So yes. The only thing one should be aware that startup current on contemporary 3.5 SATA disks would exceed 2.5A on 12V buse, so delaying plate startup is rather vital. Or get 500-520 VA PSU to be sure. Or do both just to be on the safe side ;-) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 08:04:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84600106566B for ; Mon, 15 Feb 2010 08:04:58 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB548FC08 for ; Mon, 15 Feb 2010 08:04:58 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-243-166.shv.bellsouth.net [98.67.243.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 3484B800833C; Mon, 15 Feb 2010 02:04:57 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id o1F84qZv014061; Mon, 15 Feb 2010 02:04:52 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Mon, 15 Feb 2010 02:04:51 -0600 (CST) From: Wes Morgan X-X-Sender: morganw@volatile To: Dmitry Morozovsky In-Reply-To: Message-ID: References: <4B6F9A8D.4050907@langille.org> <4B779561.7000205@langille.org> <4B788235.6080804@langille.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.3 at warped X-Virus-Status: Clean Cc: FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 08:04:58 -0000 On Mon, 15 Feb 2010, Dmitry Morozovsky wrote: > On Sun, 14 Feb 2010, Dan Langille wrote: > > [snip] > > DL> > SAS controller ($120): > DL> > http://www.buy.com/prod/supermicro-lsi-megaraid-lsisas1068e-8-port-sas-raid-controller-16mb/q/loc/101/207929556.html > DL> > Note: You'll need to change or remove the mounting bracket since it is > DL> > "backwards". I was able to find a bracket with matching screw holes on an > DL> > old nic and secure it to my case. It uses the same chipset as the more > DL> > expensive 3081E-R, if I remember correctly. > DL> > DL> I follow what you say, but cannot comprehend why the bracket is backwards. > > It's because IO slot is ot the other side of the bracked, like good old ISA Yeah. Mirror image would be a more accurate description. I'm surprised I had an ISA card that matched up with the mounting holes. Supermicro calls it "UIO". From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 08:30:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3710B106566C for ; Mon, 15 Feb 2010 08:30:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE9C8FC0A for ; Mon, 15 Feb 2010 08:30:28 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta04.emeryville.ca.mail.comcast.net with comcast id i8Te1d0011bwxycA48WVFw; Mon, 15 Feb 2010 08:30:29 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.emeryville.ca.mail.comcast.net with comcast id i8YP1d0033S48mS8e8YQBk; Mon, 15 Feb 2010 08:32:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9CCEB1E301A; Mon, 15 Feb 2010 00:30:27 -0800 (PST) Date: Mon, 15 Feb 2010 00:30:27 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215083027.GA51038@icarus.home.lan> References: <4B786D3A.3000408@langille.org> <20100215085710.21077b9vaoqxbpgk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100215085710.21077b9vaoqxbpgk@webmail.leidinger.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 08:30:29 -0000 On Mon, Feb 15, 2010 at 08:57:10AM +0100, Alexander Leidinger wrote: > Quoting Dan Naumov (from Mon, 15 Feb 2010 > 01:10:49 +0200): > > >Get a dock for holding 2 x 2,5" disks in a single 5,25" slot and put > >it at the top, in the only 5,25" bay of the case. Now add an > >additional PCI-E SATA controller card, like the often mentioned PCIE > >SIL3124. Now you have 2 x 2,5" disk slots and 8 x 3,5" disk slots, > >with 6 native SATA ports on the motherboard and more ports on the > >controller card. Now get 2 x 80gb Intel SSDs and put them into the > >dock. Now partition each of them in the following fashion: > > > >1: swap: 4-5gb > >2: freebsd-zfs: ~10-15gb for root filesystem > >3: freebsd-zfs: rest of the disk: dedicated L2ARC vdev > > If you already have 2 SSDs I suggest to make 4 partitions. The > additional one for the ZIL (decide yourself what you want to speed > up "more" and size the L2ARC and ZIL partitions accordingly...). > This should speed up write operations. The ZIL one should be zfs > mirrored, because the ZIL is more sensitive to disk failures than > the L2ARC: zpool add log mirror > > >GMirror your SSD swap partitions. > >Make a ZFS mirror pool out of your SSD root filesystem partitions > >Build your big ZFS pool however you like out of the mechanical > >disks you have. > >Add the 2 x ~60gb partitions as dedicated independant L2ARC devices > >for your SATA disk ZFS pool. > > BTW, the cheap way of doing something like this is to add a USB > memory stick as L2ARC: > http://www.leidinger.net/blog/2010/02/10/making-zfs-faster/ > This will not give you the speed boost of a real SSD attached via > SATA, but for the price (maybe you even got the memory stick for > free somewhere) you can not get something better. I had a feeling someone would bring up L2ARC/cache devices. This gives me the opportunity to ask something that's been on my mind for quite some time now: Aside from the capacity different (e.g. 40GB vs. 1GB), is there a benefit to using a dedicated RAM disk (e.g. md(4)) to a pool for L2ARC/cache? The ZFS documentation explicitly states that cache device content is considered volatile. Example: # zpool status storage pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 mirror ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad14 ONLINE 0 0 0 errors: No known data errors # mdconfig -a -t malloc -o reserve -s 256m -u 16 # zpool add storage cache md16 # zpool status storage pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 mirror ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad14 ONLINE 0 0 0 cache md16 ONLINE 0 0 0 And removal: # zpool remove storage md16 # mdconfig -d -u 16 # -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 08:49:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84D29106566C for ; Mon, 15 Feb 2010 08:49:51 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id BDE5B8FC18 for ; Mon, 15 Feb 2010 08:49:50 +0000 (UTC) Received: by gxk10 with SMTP id 10so3966911gxk.3 for ; Mon, 15 Feb 2010 00:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=wWOzEyal0cgIGx//gOsWCN7//oTMksTfV1hQptXVCsA=; b=HPkYO/i69fhjz2MsO50aj0NLDmZ8LksKEIOGoevSH4o4NONkMHOQJJDck0OFs+CuNN vL8XFn3Tpch03jlTHdOt8llcUDZINbDeShEyNzIbMgQgbQEQascDyM+GnOtzm/GSsw3K +PTdIip6BjgzMwbCtmx7eTr5W+dDqKggK7z0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=L8WknWlOZQqqsC6VKG+7O0IJs9eXDaJnvorSfw0EIe97LaLrsBlyOIPy1IoPlAwFV5 JrE/uq9kWwdQqPomwBuzNn/VzolwpWB/XCg8YTLVP8tfRLjinaFfUqo3vpY/XPbAcaAl q8JSUYg+K5MQTJuxIY7unYzApiGGTAg4xECHI= MIME-Version: 1.0 Received: by 10.150.251.16 with SMTP id y16mr9320414ybh.188.1266223787111; Mon, 15 Feb 2010 00:49:47 -0800 (PST) Date: Mon, 15 Feb 2010 10:49:47 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: RE: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 08:49:53 -0000 > I had a feeling someone would bring up L2ARC/cache devices. This gives > me the opportunity to ask something that's been on my mind for quite > some time now: > > Aside from the capacity different (e.g. 40GB vs. 1GB), is there a > benefit to using a dedicated RAM disk (e.g. md(4)) to a pool for > L2ARC/cache? The ZFS documentation explicitly states that cache > device content is considered volatile. Using a ramdisk as an L2ARC vdev doesn't make any sense at all. If you have RAM to spare, it should be used by regular ARC. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 09:07:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18E791065672 for ; Mon, 15 Feb 2010 09:07:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 024588FC13 for ; Mon, 15 Feb 2010 09:07:57 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta06.emeryville.ca.mail.comcast.net with comcast id i94G1d0011afHeLA697ytl; Mon, 15 Feb 2010 09:07:58 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id i97x1d0033S48mS8d97xkB; Mon, 15 Feb 2010 09:07:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 59DE01E301A; Mon, 15 Feb 2010 01:07:56 -0800 (PST) Date: Mon, 15 Feb 2010 01:07:56 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215090756.GA54764@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 09:07:58 -0000 On Mon, Feb 15, 2010 at 10:49:47AM +0200, Dan Naumov wrote: > > I had a feeling someone would bring up L2ARC/cache devices. This gives > > me the opportunity to ask something that's been on my mind for quite > > some time now: > > > > Aside from the capacity different (e.g. 40GB vs. 1GB), is there a > > benefit to using a dedicated RAM disk (e.g. md(4)) to a pool for > > L2ARC/cache? The ZFS documentation explicitly states that cache > > device content is considered volatile. > > Using a ramdisk as an L2ARC vdev doesn't make any sense at all. If you > have RAM to spare, it should be used by regular ARC. ...except that it's already been proven on FreeBSD that the ARC getting out of control can cause kernel panics[1], horrible performance until ZFS has had its active/inactive lists flushed[2], and brings into question how proper tuning is to be established and what the effects are on the rest of the system[3]. There are still reports of people disabling ZIL "for stability reasons" as well. My thought process basically involves "getting rid" of the ARC and using L2ARC entirely, given that it provides more control/containment which cannot be achieved on FreeBSD (see above). In English: I'd trust a whole series of md(4) disks (with sizes that I choose) over something "variable/dynamic" which cannot be controlled or managed effectively. The "Internals" section of Brendan Gregg's blog[4] outlines where the L2ARC sits in the scheme of things, or if the ARC could essentially be disabled by setting the minimum size to something very small (a few megabytes) and instead using L2ARC which is manageable. [1]: http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211009.html [2]: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053949.html [3]: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055073.html [4]: http://blogs.sun.com/brendan/entry/test -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 09:24:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E372F1065694 for ; Mon, 15 Feb 2010 09:24:30 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id CA9A88FC16 for ; Mon, 15 Feb 2010 09:24:30 +0000 (UTC) Received: by mail.alameda.net (Postfix, from userid 1000) id E2EF31CC84; Mon, 15 Feb 2010 00:56:55 -0800 (PST) Date: Mon, 15 Feb 2010 00:56:55 -0800 From: Ulf Zimmermann To: Dan Langille Message-ID: <20100215085655.GL30353@evil.alameda.net> References: <4B786D3A.3000408@langille.org> <4B789643.7020606@langille.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B789643.7020606@langille.org> User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.5-PRERELEASE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner-ID: E2EF31CC84.A605B X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: FreeBSD-STABLE Mailing List , Dan Naumov Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 09:24:31 -0000 On Sun, Feb 14, 2010 at 07:33:07PM -0500, Dan Langille wrote: > >Get a dock for holding 2 x 2,5" disks in a single 5,25" slot and put > >it at the top, in the only 5,25" bay of the case. > > That sounds very interesting. I just looking around for such a thing, > and could not find it. Is there a more specific name? URL? I had an Addonics 5.25" frame for 4x 2.5" SAS/SATA but the small fans in it are unfortunatly of the cheap kind. I ended up using the 2x2.5" to 3.5" frame from Silverstone (for the small Silverstone case I got). -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 09:43:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC2B81065670 for ; Mon, 15 Feb 2010 09:43:54 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 83DA08FC1E for ; Mon, 15 Feb 2010 09:43:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:Sender:From:Date; bh=iXbybdnP9H6NNeBR2kdBMg59C78qKjQMmRYEFAZsMNM=; b=ZoKDP/ceRHZgIS2RbFk5tRzfymA7I3mVQVu/JyCmk0WxwPUxb5FY+CrHyBX72xHrrNyqsdNU0Q+nXcm2wTA74TDg93WOh8aPE6g8hTl4ZIUyKWxhdho7UlAq6qxQimTihdFZdiHIR7uAxS+uEMjQpT3Y1xkU0zKZo5cCe5dmkd4=; Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:56899 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NgxUd-0005vg-Hx for freebsd-stable@freebsd.org; Mon, 15 Feb 2010 03:43:53 -0600 Date: Mon, 15 Feb 2010 03:43:36 -0600 (CST) From: Larry Rosenman Sender: ler@borg To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Score: -1.7 (-) X-LERCTR-Spam-Score: -1.7 (-) X-Spam-Report: SpamScore (-1.7/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.695, TW_BD=0.077, TW_BP=0.077, TW_CB=0.077, TW_KB=0.077, TW_TK=0.077, TW_UH=0.077, TW_VP=0.077 X-LERCTR-Spam-Report: SpamScore (-1.7/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.695, TW_BD=0.077, TW_BP=0.077, TW_CB=0.077, TW_KB=0.077, TW_TK=0.077, TW_UH=0.077, TW_VP=0.077 Subject: kernel compile failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 09:43:54 -0000 I'm getting: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/cam/ata/ata_xpt.c /usr/src/sys/cam/ata/ata_xpt.c: In function 'probestart': /usr/src/sys/cam/ata/ata_xpt.c:331: error: 'ATA_SF_PUIS_SPINUP' undeclared (first use in this function) /usr/src/sys/cam/ata/ata_xpt.c:331: error: (Each undeclared identifier is reported only once /usr/src/sys/cam/ata/ata_xpt.c:331: error: for each function it appears in.) /usr/src/sys/cam/ata/ata_xpt.c: In function 'probedone': /usr/src/sys/cam/ata/ata_xpt.c:789: error: 'ATA_RESP_INCOMPLETE' undeclared (first use in this function) *** Error code 1 Stop in /usr/obj/usr/src/sys/BORG. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. with a RELENG_8 csup'ed yesterday. Any ideas? kernel Config: # # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.475 2007/04/10 21:40:12 pjd Exp $ cpu HAMMER ident BORG # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_4BSD # 4BSD scheduler options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options NFSLOCKD # Network Lock Manager options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 #8+ options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev ###8+ default now #options ADAPTIVE_GIANT # Giant mutex is adaptive. #options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT options INCLUDE_CONFIG_FILE # Debugging for use in -current options KDB # Enable kernel debugger support. options KDB_TRACE # Enable kernel debugger support. options KDB_UNATTENDED # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options STACK #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives device atapicam # ATA CAM Layer options ATA_STATIC_ID # Static device numbering device ahci # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) device sg # Linux SG Stuff #---- device pt #SCSI processor device targ #SCSI Target Mode Code device targbh #SCSI Target Mode Blackhole Device #---- # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device wlan_amrr # 802.11 AMRR support # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners ############# # The cpufreq(4) driver provides support for non-ACPI CPU frequency control #device cpufreq # Direct Rendering modules for 3D acceleration. device drm # DRM core module required by DRM drivers device radeondrm # ATI Radeon options HWPMC_HOOKS device smbus # Bus support, required for smb below. device intpm device ichsmb device smb device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge device crypto # core crypto support device cryptodev # /dev/crypto for access to h/w device rndtest # FIPS 140-2 entropy tester device ipmi device smbios options SCTP #options BREAK_TO_DEBUGGER #options ALT_BREAK_TO_DEBUGGER device coretemp # Core temp (CORE procs and newer) #ungarble messages options PRINTF_BUFR_SIZE=128 #####KTR Stuff options KTR options KTR_COMPILE=(KTR_SCHED) options KTR_MASK=(KTR_SCHED) options KTR_ENTRIES=262144 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 09:50:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2EBC1065670 for ; Mon, 15 Feb 2010 09:50:10 +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 8AAA78FC14 for ; Mon, 15 Feb 2010 09:50:10 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2C3B6.dip.t-dialin.net [217.226.195.182]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 6AFE8844F3D; Mon, 15 Feb 2010 10:50:04 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 09EB1CD82F; Mon, 15 Feb 2010 10:50:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1266227401; bh=dnUpk/RhCDiCIN+5cdZSuhrOey5sgjYHb3Iezemfzr4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=O7d7zMQbHUODXgQG6Drtt4OriznttzYovbIm8XyyQsI43YVxSWU7dRqmmXrV7kPFo WwtmsZ/B9jaHy50Pc3S+am/sNi15RLGEhwyjSOti2i2iX5CEGoYjJh7tNlEMP4ewDa Y7QEMgVlYjCfA5dnq8m2W6hKC06U4r00KI/5AaEMnd8zun9ZUGD+7v0aEMwXMvEmQ5 pnHmeRzjyxVdRVXFGuQuL4/eGhnUBvsPGPIKWcnLWvcR2KGGQl+iZlBaBTCdizyUjK 47EMzPU3GTrV+bMClMYsRv+nopG1MUJmh8W3Dm8Gkkhur4ipizyKr8RFvonYSaHO0s +NQnDZQfod/eA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o1F9o0mJ086320; Mon, 15 Feb 2010 10:50:00 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 15 Feb 2010 10:50:00 +0100 Message-ID: <20100215105000.101326yj01j0f64g@webmail.leidinger.net> Date: Mon, 15 Feb 2010 10:50:00 +0100 From: Alexander Leidinger To: Jeremy Chadwick References: <20100215090756.GA54764@icarus.home.lan> In-Reply-To: <20100215090756.GA54764@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 6AFE8844F3D.7B35B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1266832205.52346@38gYt3GKTDHcOWUhybIiXw X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 09:50:11 -0000 Quoting Jeremy Chadwick (from Mon, 15 Feb 2010 01:07:56 -0800): > On Mon, Feb 15, 2010 at 10:49:47AM +0200, Dan Naumov wrote: >> > I had a feeling someone would bring up L2ARC/cache devices. This gives >> > me the opportunity to ask something that's been on my mind for quite >> > some time now: >> > >> > Aside from the capacity different (e.g. 40GB vs. 1GB), is there a >> > benefit to using a dedicated RAM disk (e.g. md(4)) to a pool for >> > L2ARC/cache? The ZFS documentation explicitly states that cache >> > device content is considered volatile. >> >> Using a ramdisk as an L2ARC vdev doesn't make any sense at all. If you >> have RAM to spare, it should be used by regular ARC. > > ...except that it's already been proven on FreeBSD that the ARC getting > out of control can cause kernel panics[1], horrible performance until There are other ways (not related to ZFS) to shoot into your feet too, I'm tempted to say that this is a) a documentation bug and b) a lack of sanity checking of the values... anyone out there with a good algorithm for something like this? Normally you do some testing with the values you use, so once you resolved the issues, the system should be stable. > ZFS has had its active/inactive lists flushed[2], and brings into Someone needs to sit down and play a little bit with ways to tell the ARC that there is free memory. The mail you reference already tells that the inactive/cached lists should maybe taken into account too (I didn't had a look at this part of the ZFS code). > question how proper tuning is to be established and what the effects are > on the rest of the system[3]. There are still reports of people That's what I talk about regarding b) above. If you specify an arc_max which is too big (arc_max > kmem_size - SOME_SAVE_VALUE), there should be a message from the kernel and the value should be adjusted to a save amount. Until the problems are fixed, a MD for L2ARC may be a viable alternative (if you have enough mem to give for this). Feel free to provide benchmark numbers, but in general I see this just as a workaround for the current issues. > disabling ZIL "for stability reasons" as well. For the ZIL you definitively do not want to have a MD. If you do not specify a log vdev for the pool, the ZIL will be written somewhere on the disks of the pool. When the data hits the ZIL, it has to be really on a non-volatile storage. If you lose the ZIL, you lose data. > The "Internals" section of Brendan Gregg's blog[4] outlines where the > L2ARC sits in the scheme of things, or if the ARC could essentially > be disabled by setting the minimum size to something very small (a few > megabytes) and instead using L2ARC which is manageable. At least in 7-stable, 8-stable and 9-current, the arc_max now really corresponds to a max value, so it is more of providing a save arc_max than a minimal arc_max. No matter how you construct the L2ARC, ARC access will be faster than L2ARC access. > [1]: > http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211009.html > [2]: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053949.html > [3]: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055073.html > [4]: http://blogs.sun.com/brendan/entry/test Bye, Alexander. -- BOFH excuse #439: Hot Java has gone cold http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 09:53:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AF051065672 for ; Mon, 15 Feb 2010 09:53:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 13D028FC19 for ; Mon, 15 Feb 2010 09:53:23 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta01.emeryville.ca.mail.comcast.net with comcast id i9sF1d00117UAYkA19tQkm; Mon, 15 Feb 2010 09:53:24 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta13.emeryville.ca.mail.comcast.net with comcast id i9tP1d0063S48mS8Z9tP57; Mon, 15 Feb 2010 09:53:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5A1621E301A; Mon, 15 Feb 2010 01:53:22 -0800 (PST) Date: Mon, 15 Feb 2010 01:53:22 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215095322.GA55575@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mav@freebsd.org Subject: Re: kernel compile failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 09:53:24 -0000 On Mon, Feb 15, 2010 at 03:43:36AM -0600, Larry Rosenman wrote: > I'm getting: > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/cam/ata/ata_xpt.c > /usr/src/sys/cam/ata/ata_xpt.c: In function 'probestart': > /usr/src/sys/cam/ata/ata_xpt.c:331: error: 'ATA_SF_PUIS_SPINUP' undeclared (first use in this function) > /usr/src/sys/cam/ata/ata_xpt.c:331: error: (Each undeclared identifier is reported only once > /usr/src/sys/cam/ata/ata_xpt.c:331: error: for each function it appears in.) > /usr/src/sys/cam/ata/ata_xpt.c: In function 'probedone': > /usr/src/sys/cam/ata/ata_xpt.c:789: error: 'ATA_RESP_INCOMPLETE' undeclared (first use in this function) > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/BORG. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > with a RELENG_8 csup'ed yesterday. > > Any ideas? 1) When running csup, always take note of what src-all pieces are getting touched. I'm 100% certain your csup would have shown that the above code had recently been modified (commits done to it). I tend to review every single source code piece that gets committed that appears relevant or interests me. ATA or CAM subsystem, SMP, VM, or UFS/FFS "stuff" is a big focus of mine, so I watch these like a hawk. 2) When encountering a kernel build error like the above, start reviewing commits on the web: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c You can see there that code was modified ~14 hours ago, and who the committer was. It's safe to say this commit is responsible for your problem, since the error is in regards to PUIS (Power Up In Stand-by): ===== Revision 1.3.2.20: download - view: text, markup, annotated - select for diffs Sun Feb 14 19:50:33 2010 UTC (14 hours ago) by mav Branches: RELENG_8 Diff to: previous 1.3.2.19: preferred, colored; branchpoint 1.3: preferred, colored Changes since revision 1.3.2.19: +36 -2 lines SVN rev 203893 on 2010-02-14 19:50:33Z by mav MFC r203421: Add Power Up In Stand-by feature support. Device with PUIS enabled require explicit command to do initial spin-up. Mark that command with CAM_HIGH_POWER flag, to allow CAM manage staggered spin-up. ===== I've CC'd the committer here. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 09:55:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA0C1106566C for ; Mon, 15 Feb 2010 09:55:49 +0000 (UTC) (envelope-from nino80@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 43BDB8FC0A for ; Mon, 15 Feb 2010 09:55:49 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so370612fgg.13 for ; Mon, 15 Feb 2010 01:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=XCvdgkd21iW+iuf6mVXZqhhnkNJPgfCVarjTfJ0YgFs=; b=R4tj+ytybVVpcJ2tSJoMKHs/K479w4fLZSp7XF2l11vy3eNVPbg8d6/PhbyIITuDVR 5aaknNXe6QiKPKR8Nj0FWZ4oAqaMEIpwu8u1HR8fgC8ODo5npxCqXTPck0Rdk6BFbE7n MM/upH7ibqp3nVxNi4mtN8l+ZadXAvDmpbtwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=XbicEKMeRO5pkBS661UlK0o95zDX+D242PlwM7vuYQ9qD2XZWRO7GFI+VxO+Zv1RaF cTiQ2qAFx8qIxJJqHwEMl4Tf0pB3Qg6tECE+wITln0kpwYdr7KavXB+k/YJcNkktxrO1 k9rV0Br6I/uiAa9NnAFsQBGpm1ZaJhl3aLX2U= MIME-Version: 1.0 Received: by 10.102.16.13 with SMTP id 13mr3660433mup.62.1266226251210; Mon, 15 Feb 2010 01:30:51 -0800 (PST) From: n j Date: Mon, 15 Feb 2010 10:30:31 +0100 Message-ID: <92bcbda51002150130i3a1baa4eha06b8ce4f90de486@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ACK and RST packets sent after successfully terminating TCP connection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 09:55:49 -0000 Hi all, I'm reposting this from the freebsd-questions hoping for some answers. I feel there is something wrong here, but would really appreciate a second opinion before opening a bug report. The problematic part is marked with [what is this?]. - in case of successful connection: [begin handshake] 14:52:57.866040 IP client.example.net.6524 > server.example.net.9002: S 813851098:813851098(0) win 8192 14:52:57.866057 IP server.example.net.9002 > client.example.net.6524: S 3888621507:3888621507(0) ack 813851099 win 65535 14:52:57.867143 IP client.example.net.6524 > server.example.net.9002: . ack 3888621508 win 16560 [end handshake & begin data] 14:52:57.868333 IP client.example.net.6524 > server.example.net.9002: P 813851099:813852180(1081) ack 3888621508 win 16560 14:52:57.967858 IP server.example.net.9002 > client.example.net.6524: . ack 813852180 win 8144 14:53:35.533165 IP server.example.net.9002 > client.example.net.6524: P 3888621508:3888621542(34) ack 813852180 win 8144 [end data & begin teardown] 14:53:35.564542 IP server.example.net.9002 > client.example.net.6524: FP 3888621542:3888621675(133) ack 813852180 win 8280 14:53:35.566228 IP client.example.net.6524 > server.example.net.9002: . ack 3888621676 win 16518 14:53:35.566289 IP client.example.net.6524 > server.example.net.9002: F 813852180:813852180(0) ack 3888621676 win 16518 14:53:35.566318 IP server.example.net.9002 > client.example.net.6524: . ack 813852181 win 8279 [end teardown] [what is this?] 14:53:36.172081 IP server.example.net.9002 > client.example.net.6524: . ack 813852180 win 0 14:53:36.172101 IP server.example.net.9002 > client.example.net.6524: . ack 813852181 win 8279 - in case of unsuccessful connection: [begin handshake] 14:53:00.411337 IP client.example.net.6547 > server.example.net.9002: S 1055031875:1055031875(0) win 8192 14:53:00.411354 IP server.example.net.9002 > client.example.net.6547: S 2849043653:2849043653(0) ack 1055031876 win 65535 14:53:00.412242 IP client.example.net.6547 > server.example.net.9002: . ack 2849043654 win 16560 [end handshake & reset connection] 14:53:00.412251 IP server.example.net.9002 > client.example.net.6547: R 2849043654:2849043654(0) win 0 [what is this?] 14:53:01.168076 IP server.example.net.9002 > client.example.net.6547: . ack 1055031876 win 0 14:53:01.168100 IP server.example.net.9002 > client.example.net.6547: R 2849043654:2849043654(0) win 0 14:53:01.168393 IP client.example.net.6547 > server.example.net.9002: R 1055031876:1055031876(0) ack 2849043653 win 0 The server is running 7.2 GENERIC. Thanks, -- Nino From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 10:11:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A5311065672 for ; Mon, 15 Feb 2010 10:11:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id F18E88FC12 for ; Mon, 15 Feb 2010 10:11:49 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta03.emeryville.ca.mail.comcast.net with comcast id iAAM1d0031smiN4A3ABqMu; Mon, 15 Feb 2010 10:11:50 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id iABp1d0033S48mS8gABpxP; Mon, 15 Feb 2010 10:11:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 905E61E301A; Mon, 15 Feb 2010 02:11:48 -0800 (PST) Date: Mon, 15 Feb 2010 02:11:48 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215101148.GA56308@icarus.home.lan> References: <92bcbda51002150130i3a1baa4eha06b8ce4f90de486@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92bcbda51002150130i3a1baa4eha06b8ce4f90de486@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ACK and RST packets sent after successfully terminating TCP connection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 10:11:51 -0000 On Mon, Feb 15, 2010 at 10:30:31AM +0100, n j wrote: > Hi all, > > I'm reposting this from the freebsd-questions hoping for some answers. > I feel there is something wrong here, but would really appreciate a > second opinion before opening a bug report. The problematic part is > marked with [what is this?]. > > - in case of successful connection: > > [begin handshake] > 14:52:57.866040 IP client.example.net.6524 > server.example.net.9002: > S 813851098:813851098(0) win 8192 2,nop,nop,sackOK> > 14:52:57.866057 IP server.example.net.9002 > client.example.net.6524: > S 3888621507:3888621507(0) ack 813851099 win 65535 1380,nop,wscale 3,sackOK,eol> > 14:52:57.867143 IP client.example.net.6524 > server.example.net.9002: > . ack 3888621508 win 16560 > [end handshake & begin data] > 14:52:57.868333 IP client.example.net.6524 > server.example.net.9002: > P 813851099:813852180(1081) ack 3888621508 win 16560 > 14:52:57.967858 IP server.example.net.9002 > client.example.net.6524: > . ack 813852180 win 8144 > 14:53:35.533165 IP server.example.net.9002 > client.example.net.6524: > P 3888621508:3888621542(34) ack 813852180 win 8144 > [end data & begin teardown] > 14:53:35.564542 IP server.example.net.9002 > client.example.net.6524: > FP 3888621542:3888621675(133) ack 813852180 win 8280 > 14:53:35.566228 IP client.example.net.6524 > server.example.net.9002: > . ack 3888621676 win 16518 > 14:53:35.566289 IP client.example.net.6524 > server.example.net.9002: > F 813852180:813852180(0) ack 3888621676 win 16518 > 14:53:35.566318 IP server.example.net.9002 > client.example.net.6524: > . ack 813852181 win 8279 > [end teardown] > [what is this?] > 14:53:36.172081 IP server.example.net.9002 > client.example.net.6524: > . ack 813852180 win 0 > 14:53:36.172101 IP server.example.net.9002 > client.example.net.6524: > . ack 813852181 win 8279 > > - in case of unsuccessful connection: > > [begin handshake] > 14:53:00.411337 IP client.example.net.6547 > server.example.net.9002: > S 1055031875:1055031875(0) win 8192 2,nop,nop,sackOK> > 14:53:00.411354 IP server.example.net.9002 > client.example.net.6547: > S 2849043653:2849043653(0) ack 1055031876 win 65535 1380,nop,wscale 3,sackOK,eol> > 14:53:00.412242 IP client.example.net.6547 > server.example.net.9002: > . ack 2849043654 win 16560 > [end handshake & reset connection] > 14:53:00.412251 IP server.example.net.9002 > client.example.net.6547: > R 2849043654:2849043654(0) win 0 > [what is this?] > 14:53:01.168076 IP server.example.net.9002 > client.example.net.6547: > . ack 1055031876 win 0 > 14:53:01.168100 IP server.example.net.9002 > client.example.net.6547: > R 2849043654:2849043654(0) win 0 > 14:53:01.168393 IP client.example.net.6547 > server.example.net.9002: > R 1055031876:1055031876(0) ack 2849043653 win 0 > > The server is running 7.2 GENERIC. Is it possible for you to upload these captures somewhere on the web? tcpdump -p -i {iface} -s 0 -n -w {somefile} should be sufficient. Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 10:34:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 808FA106566C for ; Mon, 15 Feb 2010 10:34:37 +0000 (UTC) (envelope-from ga9@york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 20B698FC1B for ; Mon, 15 Feb 2010 10:34:36 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id o1FAYQ0S007699; Mon, 15 Feb 2010 10:34:26 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160]) by mail-gw7.york.ac.uk with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NgyHa-0000Ud-EA; Mon, 15 Feb 2010 10:34:26 +0000 From: Gavin Atkinson To: Sean McCullough In-Reply-To: <4B747009.9000706@frii.com> References: <4B747009.9000706@frii.com> Content-Type: text/plain; charset="ASCII" Date: Mon, 15 Feb 2010 10:34:25 +0000 Message-ID: <1266230065.39591.7.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Sender: ga9@york.ac.uk X-York-MailScanner: Found to be clean X-York-MailScanner-From: ga9@york.ac.uk Cc: freebsd-stable@freebsd.org Subject: Re: Hello and a small problem with 8.0-RELEASE (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 10:34:37 -0000 On Thu, 2010-02-11 at 14:00 -0700, Sean McCullough wrote: > Hello, freebsd-stable folks! > > I sincerely hope I am in the correct place to inquire about a small > problem I am having implementing FreeBSD 8.0-RELEASE on my AMD Athlon-64 > machine. This machine runs FreeBSD 7.2 (amd64 version) without the > slightest problem; but when I attempt to load 8.0 onto the machine, I > can't even get sysinstall to put the kernel on to boot it. Attempting to > compile and install the 8.0 kernel from source code results in a kernel > which locks up at boot time after emitting a message stating "attempting > to mount volumes"; a reboot of this system results in a bootloader > prompt and an error message stating that no bootable kernel can be found. Can you provide a verbose "dmesg -a" from the system while it is running 7.2? It would be useful if you could also boot 8.0 with verbose messages, and mark on it where exactly you see the hang, as I don't know where the "attempting to mount volumes" message is coming from (I don't see it on my 8.0 machine, and I can't see it anywhere in the source). Thanks! Gavin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 12:27:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C43811065672 for ; Mon, 15 Feb 2010 12:27:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id A9D228FC0C for ; Mon, 15 Feb 2010 12:27:45 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta09.emeryville.ca.mail.comcast.net with comcast id iCSn1d0021ZMdJ4A9CTmxF; Mon, 15 Feb 2010 12:27:46 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta16.emeryville.ca.mail.comcast.net with comcast id iCW11d0043S48mS8cCW1lv; Mon, 15 Feb 2010 12:30:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5B53B1E301A; Mon, 15 Feb 2010 04:27:44 -0800 (PST) Date: Mon, 15 Feb 2010 04:27:44 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215122744.GA57382@icarus.home.lan> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100215105000.101326yj01j0f64g@webmail.leidinger.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 12:27:45 -0000 On Mon, Feb 15, 2010 at 10:50:00AM +0100, Alexander Leidinger wrote: > Quoting Jeremy Chadwick (from Mon, 15 Feb > 2010 01:07:56 -0800): > > >On Mon, Feb 15, 2010 at 10:49:47AM +0200, Dan Naumov wrote: > >>> I had a feeling someone would bring up L2ARC/cache devices. This gives > >>> me the opportunity to ask something that's been on my mind for quite > >>> some time now: > >>> > >>> Aside from the capacity different (e.g. 40GB vs. 1GB), is there a > >>> benefit to using a dedicated RAM disk (e.g. md(4)) to a pool for > >>> L2ARC/cache? The ZFS documentation explicitly states that cache > >>> device content is considered volatile. > >> > >>Using a ramdisk as an L2ARC vdev doesn't make any sense at all. If you > >>have RAM to spare, it should be used by regular ARC. > > > >...except that it's already been proven on FreeBSD that the ARC getting > >out of control can cause kernel panics[1], horrible performance until First and foremost, sorry for the long post. I tried to keep it short, but sometimes there's just a lot to be said. > There are other ways (not related to ZFS) to shoot into your feet > too, I'm tempted to say that this is > a) a documentation bug > and > b) a lack of sanity checking of the values... anyone out there with > a good algorithm for something like this? > > Normally you do some testing with the values you use, so once you > resolved the issues, the system should be stable. What documentation? :-) The Wiki? If so, that's been outdated for some time; I know Ivan Voras was doing his best to put good information there, but it's hard given the below chaos. The following tunables are recurrently mentioned as focal points, but no one's explained in full how to tune these "properly", or which does what (perfect example: vm.kmem_size_max vs. vm.kmem_size. _max used to be what you'd adjust to solve kmem exhaustion issues, but now people are saying otherwise?). I realise it may differ per system (given how much RAM the system has), so different system configurations/examples would need to be provided. I realise that the behaviour of some have changed too (e.g. -RELEASE differs from -STABLE, and 7.x differs from 8.x). I've marked commonly-referred-to tunables with an asterisk: kern.maxvnodes * vm.kmem_size * vm.kmem_size_max * vfs.zfs.arc_min * vfs.zfs.arc_max vfs.zfs.prefetch_disable (auto-tuned based on available RAM on 8-STABLE) vfs.zfs.txg.timeout vfs.zfs.vdev.cache.size vfs.zfs.vdev.cache.bshift vfs.zfs.vdev.max_pending vfs.zfs.zil_disable Then, when it comes to debugging problems as a result of tuning improperly (or entire lack of), the following counters (not tunables) are thrown into the mix as "things people should look at": kstat.zfs.misc.arcstats.c kstat.zfs.misc.arcstats.c_min kstat.zfs.misc.arcstats.c_max kstat.zfs.misc.arcstats.evict_skip kstat.zfs.misc.arcstats.memory_throttle_count kstat.zfs.misc.arcstats.size None of these have sysctl descriptions (sysctl -d) either. I can provide posts to freebsd-stable, freebsd-current, freebsd-fs, or freebsd-questions, or freebsd-users referencing these variables or counters if you need context. All that said: I would be more than happy to write some coherent documentation that folks could refer to "officially", but rather than spend my entire lifetime reverse-engineering the ZFS code I think it'd make more sense to get some official parties involved to explain things. I'd like to add some kind of monitoring section as well -- how administrators could keep an eye on things and detect, semi-early, if additional tuning is required or something along those lines. > >ZFS has had its active/inactive lists flushed[2], and brings into > > Someone needs to sit down and play a little bit with ways to tell > the ARC that there is free memory. The mail you reference already > tells that the inactive/cached lists should maybe taken into account > too (I didn't had a look at this part of the ZFS code). > > >question how proper tuning is to be established and what the effects are > >on the rest of the system[3]. There are still reports of people > > That's what I talk about regarding b) above. If you specify an > arc_max which is too big (arc_max > kmem_size - SOME_SAVE_VALUE), > there should be a message from the kernel and the value should be > adjusted to a save amount. > > Until the problems are fixed, a MD for L2ARC may be a viable > alternative (if you have enough mem to give for this). Feel free to > provide benchmark numbers, but in general I see this just as a > workaround for the current issues. I've played with this a bit (2-disk mirror + one 256MB md), but I'm not completely sure how to read the bonnie++ results, nor am I sure I'm using the right arguments (bonnie++ -s8192 -n64 -d/pool on a machine that has 4GB). L2ARC ("cache" vdev) is supposed to improve random reads, while a "log" vdev (presumably something that links in with the ZIL) improves random writes. I'm not sure where bonnie++ tests random reads, but I do see it testing random seeks. > >disabling ZIL "for stability reasons" as well. > > For the ZIL you definitively do not want to have a MD. If you do not > specify a log vdev for the pool, the ZIL will be written somewhere > on the disks of the pool. When the data hits the ZIL, it has to be > really on a non-volatile storage. If you lose the ZIL, you lose > data. Thanks for the clarification here. In my case, I never disable the ZIL. I never have and I never will given the above risk. However there's lots of folks who advocate doing this because they have systems which crash if they don't. I've never understood how/why that is (I've never seen the ZIL responsible for any crash I've witnessed either). > >The "Internals" section of Brendan Gregg's blog[4] outlines where the > >L2ARC sits in the scheme of things, or if the ARC could essentially > >be disabled by setting the minimum size to something very small (a few > >megabytes) and instead using L2ARC which is manageable. > > At least in 7-stable, 8-stable and 9-current, the arc_max now really > corresponds to a max value, so it is more of providing a save > arc_max than a minimal arc_max. Ahh, that might explain this semi-old post where a user was stating that arc_max didn't appear to really be a hard limit, but just some kind of high water mark. > No matter how you construct the L2ARC, ARC access will be faster than > L2ARC access. Yes, based on Brendan's blog, I can see how that'd be the case; there'd be some added overhead given the design/placement of L2ARC. The options as I see them are (a)) figure out some *reliable* way to describe to folks how to tune their systems to not experience ARC or memory exhaustion related issues, or (b) utilise L2ARC exclusively and set the ARC (arc_max) to something fairly small. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 12:47:21 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8F551065670 for ; Mon, 15 Feb 2010 12:47:21 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 889038FC14 for ; Mon, 15 Feb 2010 12:47:21 +0000 (UTC) Received: from [192.168.1.38] ([70.71.167.197]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o1FCOjQL007986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Feb 2010 04:24:46 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <4B793D1D.1000108@FreeBSD.org> Date: Mon, 15 Feb 2010 04:25:01 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: FreeBSD Hackers Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Sudden mbuf demand increase and shortage under the load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 12:47:22 -0000 Hi, Our company have a FreeBSD based product that consists of the numerous interconnected processes and it does some high-PPS UDP processing (30-50K PPS is not uncommon). We are seeing some strange periodic failures under the load in several such systems, which usually evidences itself in IPC (even through unix domain sockets) suddenly either breaking down or pausing and restoring only some time later (like 5-10 minutes). The only sign of failure I managed to find was the increase of the "requests for mbufs denied" in the netstat -m and number of total mbuf clusters (nmbclusters) raising up to the limit. I have tried to raise some network-related limits (most notably maxusers and nmbclusters), but it has not helped with the issue - it's still happening from time to time to us. Below you can find output from the netstat -m few minutes right after that shortage period - you see that somehow the system has allocated huge amount of memory for the network (700MB), with only tiny amount of that being actually in use. This is for the kern.ipc.nmbclusters: 302400. Eventually the system reclaims all that memory and goes back to its normal use of 30-70MB. This problem is killing us, so any suggestions are greatly appreciated. My current hypothesis is that due to some issues either with the network driver or network subsystem itself, the system goes insane and "eats" up all mbufs up to nmbclusters limit. But since mbufs are shared between network and local IPC, IPC goes down as well. We observe this issue with systems using both em(4) driver and igb(4) driver. I believe both drivers share the same design, however I am not sure if this is some kind of design flaw in the driver or part of a larger problem with the network subsystem. This happens on amd64 7.2-RELEASE and 7.3-PRERELEASE alike, with 8GB of memory. I have not tried upgrading to 8.0, this is production system so upgrading will not be easy. I don't believe there are some differences that let us hope that this problem will go away after upgrade, but I can try it as the last resort. As I said, this is very critical issue, so I can provide any additional debug information upon request. We are ready to go as far as paying somebody reasonable amount of money for tracking down and resolving the issue. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft [ssp-root@ds-467 /usr/src]$ netstat -m 17061/417669/434730 mbufs in use (current/cache/total) 10420/291980/302400/302400 mbuf clusters in use (current/cache/total/max) 10420/0 mbuf+clusters out of packet secondary zone in use (current/cache) 19/1262/1281/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/25600 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 25181K/693425K/718606K bytes allocated to network (current/cache/total) 1246681/129567494/67681640 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines [FEW MINUTES LATER] [ssp-root@ds-467 /usr/src]$ netstat -m 10001/84574/94575 mbufs in use (current/cache/total) 6899/6931/13830/302400 mbuf clusters in use (current/cache/total/max) 6899/6267 mbuf+clusters out of packet secondary zone in use (current/cache) 2/1151/1153/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/25600 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 16306K/39609K/55915K bytes allocated to network (current/cache/total) 1246681/129567494/67681640 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 13:01:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6439B1065672 for ; Mon, 15 Feb 2010 13:01:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id DEE2D8FC18 for ; Mon, 15 Feb 2010 13:01:22 +0000 (UTC) Received: by fxm26 with SMTP id 26so4941335fxm.13 for ; Mon, 15 Feb 2010 05:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=bdejbRzI3ubohHiXynXPoXxIojUvmd8iQ3tmGDm0A/8=; b=SUCpLxTn/X/wZCIgmf757jwIm49VnfyK3MuLbHevOSM4bJz5piRXrxkZVgtfFL28/O JGHcLUdDtrp1A5LvUFwn9ajcPedwXKTP/tkbkArLbj7SMdp7SCX1N7jDtN+W+mZj8lPb 1Hbm5OcFAjLmHhmOliHtq1lr/YeKPJ/bVpdLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=GTkGDK3Pg3kGW7wccSwUFdp7JqO7uZbHQ6qUXoEYHm1ndkla8+GK2ctFDNqqpXrCWu ulfgtTIeAL2T3G+iILys9bj8Xj8f9zaNEaTAeuBilSLFAC42LMZTVZe2+cetZoF5u6v6 gr6gJvcAfr3Dp0wxK+r5+znTOufwirb3jaKjs= Received: by 10.223.110.29 with SMTP id l29mr5904497fap.64.1266238881597; Mon, 15 Feb 2010 05:01:21 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2982362fxm.8.2010.02.15.05.01.20 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Feb 2010 05:01:21 -0800 (PST) Sender: Alexander Motin Message-ID: <4B79459E.2090207@FreeBSD.org> Date: Mon, 15 Feb 2010 15:01:18 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Larry Rosenman References: <20100215095322.GA55575@icarus.home.lan> In-Reply-To: <20100215095322.GA55575@icarus.home.lan> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: kernel compile failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 13:01:23 -0000 Jeremy Chadwick wrote: > On Mon, Feb 15, 2010 at 03:43:36AM -0600, Larry Rosenman wrote: >> I'm getting: >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/cam/ata/ata_xpt.c >> /usr/src/sys/cam/ata/ata_xpt.c: In function 'probestart': >> /usr/src/sys/cam/ata/ata_xpt.c:331: error: 'ATA_SF_PUIS_SPINUP' undeclared (first use in this function) >> /usr/src/sys/cam/ata/ata_xpt.c:331: error: (Each undeclared identifier is reported only once >> /usr/src/sys/cam/ata/ata_xpt.c:331: error: for each function it appears in.) >> /usr/src/sys/cam/ata/ata_xpt.c: In function 'probedone': >> /usr/src/sys/cam/ata/ata_xpt.c:789: error: 'ATA_RESP_INCOMPLETE' undeclared (first use in this function) >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/BORG. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> >> with a RELENG_8 csup'ed yesterday. >> >> Any ideas? Try to update sources again. Updated sys/ata.h file was committed same time and it includes all these constants. CVSWEB also shows all required pieces in place there. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 13:05:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814D51065672 for ; Mon, 15 Feb 2010 13:05:24 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 066058FC0A for ; Mon, 15 Feb 2010 13:05:23 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Nh0dc-000550-Ph for freebsd-stable@freebsd.org; Mon, 15 Feb 2010 14:05:20 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Feb 2010 14:05:20 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Feb 2010 14:05:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 15 Feb 2010 14:05:02 +0100 Lines: 54 Message-ID: References: <4B793D1D.1000108@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <4B793D1D.1000108@FreeBSD.org> Sender: news Cc: freebsd-net@freebsd.org Subject: Re: Sudden mbuf demand increase and shortage under the load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 13:05:24 -0000 On 02/15/10 13:25, Maxim Sobolev wrote: > Hi, > > Our company have a FreeBSD based product that consists of the numerous > interconnected processes and it does some high-PPS UDP processing > (30-50K PPS is not uncommon). We are seeing some strange periodic I have nothing very useful to help you with but maybe you can detect if it's a em/igp issue by buying a cheap Realtek gigabit (re) card and trying it out. Those can be bought for a few dollars now (e.g. from D-Link and many others), and I can confirm that at least the one I tried can carry around 50K pps, but not much more (I can tell you the exact chip later today if you are interested). > failures under the load in several such systems, which usually evidences > itself in IPC (even through unix domain sockets) suddenly either > breaking down or pausing and restoring only some time later (like 5-10 > minutes). The only sign of failure I managed to find was the increase of > the "requests for mbufs denied" in the netstat -m and number of total > mbuf clusters (nmbclusters) raising up to the limit. > > I have tried to raise some network-related limits (most notably maxusers > and nmbclusters), but it has not helped with the issue - it's still > happening from time to time to us. Below you can find output from the > netstat -m few minutes right after that shortage period - you see that > somehow the system has allocated huge amount of memory for the network > (700MB), with only tiny amount of that being actually in use. This is > for the kern.ipc.nmbclusters: 302400. Eventually the system reclaims all > that memory and goes back to its normal use of 30-70MB. > > This problem is killing us, so any suggestions are greatly appreciated. > My current hypothesis is that due to some issues either with the network > driver or network subsystem itself, the system goes insane and "eats" up > all mbufs up to nmbclusters limit. But since mbufs are shared between > network and local IPC, IPC goes down as well. > > We observe this issue with systems using both em(4) driver and igb(4) > driver. I believe both drivers share the same design, however I am not > sure if this is some kind of design flaw in the driver or part of a > larger problem with the network subsystem. > > This happens on amd64 7.2-RELEASE and 7.3-PRERELEASE alike, with 8GB of > memory. I have not tried upgrading to 8.0, this is production system so > upgrading will not be easy. I don't believe there are some differences > that let us hope that this problem will go away after upgrade, but I can > try it as the last resort. > > As I said, this is very critical issue, so I can provide any additional > debug information upon request. We are ready to go as far as paying > somebody reasonable amount of money for tracking down and resolving the > issue. > > Regards, From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 13:23:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E80B1106566B; Mon, 15 Feb 2010 13:22:59 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.freebsd.org (Postfix) with ESMTP id 8048F8FC0A; Mon, 15 Feb 2010 13:22:59 +0000 (UTC) Received: from miknet.dk (0x5738c147.rdnqu2.dynamic.dsl.tele.dk [87.56.193.71]) by pfepb.post.tele.dk (Postfix) with ESMTP id B2E2EF84060; Mon, 15 Feb 2010 14:22:57 +0100 (CET) Date: Mon, 15 Feb 2010 14:23:05 +0100 From: Martin Kristensen To: Robert Noland Message-ID: <20100215142305.3f0d7e65@miknet.dk> In-Reply-To: <1266096425.89452.30.camel@balrog.2hip.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> <201002131137.34812.npapke@acm.org> <1266096425.89452.30.camel@balrog.2hip.net> Organization: Private X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 13:23:00 -0000 On Sat, 13 Feb 2010 15:27:04 -0600 Robert Noland wrote: > On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: > > On February 13, 2010, Robert Noland wrote: > > > Ok, I've put up a patch at: > > > > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > > > > http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch > > This one should work on 8... > > robert. > > > > This is sort of a mega patch and includes: > > > > > > Re-worked drm mapping code, that ensures that we don't end up > > > incorrectly mapping certain maps with overlapping offsets. This > > > generally shows up as the ring buffer not being cleared > > > (contents != 0 in xorg.log) which leads to corruption and other > > > bad behavior. > > > > > > Re-written scatter gather allocation code. This interacts > > > directly with the VM system, rather than using bus_dma to allow > > > us to grab non-contiguous pages for the scatter gather backing of > > > the GART. It also makes it easier to handle the caching mode of > > > the backing pages. > > > > > > Disable cache snooping on radeon cards, since we have write > > > combining set properly now. > > > > > > I have at least done a test build on -CURRENT with this patch, > > > but I haven't had time to do much else without the rest of the > > > code in my tree. I've been running most all of this code for a > > > month or two now at least, so it is mostly just a question of > > > whether or not I got all of the conflicts sorted out properly > > > when I made this patch. > > > > > > The re-mapping code has the most widespread impact and has been > > > tested on radeon r600 amd64, intel g45 i386 and mga amd64. > > > > > > robert. The patch applied cleanly. I have applied the patch to a clean 8-STABLE environment with WITNESS, INVARIANTS and KDB_UNATTENDED in the kernel. I still see the crashes when starting X with DRI on. This is what I see in messages: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7b000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7c000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7d000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7e000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7f000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0xc0286415, nr=0x15, dev 0xffffff0001a79400, auth=1 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] offset = 0xfe8e0000, size = 0x00010000, type = 1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Found kernel map 1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Added map 1 0xfe8e0000/0x10000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0x80106459, nr=0x59, dev 0xffffff0001a79400, auth=1 There has been one odd development. If I startx with DRI off or NoAccel set it starts as usual. If I then quit and to cli and restart, I see the same crash as if I had DRI on. Martin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 13:55:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4D21065670; Mon, 15 Feb 2010 13:55:25 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6255F8FC0A; Mon, 15 Feb 2010 13:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=i0AN8RdDHL1wUMgSqPGdek+i6vrXlxKiUC5gVmxJUhM=; b=lp4j49oUMeitNtJBa71ZNVEE0FRiY7PruGZJkAPzzqFUwOJmFegw9WQ5I6dPFZix8vijD11j9ZAU4t/v6VJPv8L2l19Rej7+T5I99HeqXQIFCpYqdJiRrOdd6MEuk9cMCbOjkIXVpQiZAYiDa67IRVdv/snnXMMC9fdm8IY/wMs=; Received: from 64.3.1.253.ptr.us.xo.net ([64.3.1.253]:44192 helo=LROSENMAN) by thebighonker.lerctr.org with esmtpa (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nh1Q3-000Bl2-8s; Mon, 15 Feb 2010 07:55:25 -0600 From: "Larry Rosenman" To: "'Alexander Motin'" References: <20100215095322.GA55575@icarus.home.lan> <4B79459E.2090207@FreeBSD.org> In-Reply-To: <4B79459E.2090207@FreeBSD.org> Date: Mon, 15 Feb 2010 07:55:13 -0600 Message-ID: <000901caae46$84d73300$8e859900$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcquPwCdmopeQexkTWav4zB3cm7pwQAB3C3w Content-Language: en-us X-Spam-Score: -2.2 (--) X-LERCTR-Spam-Score: -2.2 (--) X-Spam-Report: SpamScore (-2.2/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.695 X-LERCTR-Spam-Report: SpamScore (-2.2/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.695 Cc: freebsd-stable@freebsd.org, 'Jeremy Chadwick' Subject: RE: kernel compile failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 13:55:25 -0000 For the record, it appears that cvsup17.us.freebsd.org is serving outdated files. $ find . -name ata.h ./sys/ata.h $ cd sys $ ls -l ata.h -rw-r--r-- 1 root wheel 25308 Feb 6 12:35 ata.h $ sudo -s Password: # rm ata.h # csup -h cvsup17.us.freebsd.org -L 2 -g /usr/share/examples/cvsup/stand* Parsing supfile "/usr/share/examples/cvsup/standard-supfile" Connecting to cvsup17.us.freebsd.org Connected to 65.212.71.21 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Checkout src/sys/sys/ata.h Shutting down connection to server Finished successfully # ls -l ata.h -rw-r--r-- 1 root wheel 25308 Jan 19 06:58 ata.h # csup -h cvsup14.us.freebsd.org -L 2 -g /usr/share/examples/cvsup/stand* Parsing supfile "/usr/share/examples/cvsup/standard-supfile" Connecting to cvsup14.us.freebsd.org Connected to 216.87.78.137 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Edit src/sys/netinet/libalias/alias_mod.c Add delta 1.4.2.3 2010.02.11.18.34.06 mjacob Edit src/sys/netinet/sctp_asconf.c Add delta 1.40.2.4 2010.02.11.18.34.06 mjacob Edit src/sys/netinet/sctputil.c Add delta 1.93.2.7 2010.02.11.18.34.06 mjacob Edit src/sys/nfsclient/bootp_subr.c Add delta 1.86.2.4 2010.02.11.18.34.06 mjacob Edit src/sys/nfsclient/nfs.h Add delta 1.110.2.2 2010.02.10.16.16.50 rmacklem Edit src/sys/nfsclient/nfs_bio.c Add delta 1.180.2.2 2010.02.10.16.16.50 rmacklem Edit src/sys/nfsclient/nfs_nfsiod.c Add delta 1.95.2.2 2010.02.10.16.16.50 rmacklem Edit src/sys/nfsclient/nfs_subs.c Add delta 1.163.2.3 2010.02.10.16.16.50 rmacklem Edit src/sys/nfsclient/nfs_vnops.c Add delta 1.318.2.8 2010.02.10.16.16.50 rmacklem Edit src/sys/nfsclient/nfsnode.h Add delta 1.66.2.3 2010.02.10.16.16.50 rmacklem Edit src/sys/pci/ncr.c Add delta 1.197.10.2 2010.02.11.18.34.06 mjacob Edit src/sys/powerpc/aim/mmu_oea.c Add delta 1.130.2.2 2010.02.11.18.34.06 mjacob Edit src/sys/rpc/clnt_dg.c Add delta 1.7.2.3 2010.02.11.18.34.06 mjacob Edit src/sys/sys/ata.h Add delta 1.41.2.7 2010.02.14.19.50.33 mav Edit src/sys/ufs/ffs/ffs_snapshot.c Add delta 1.150.2.2 2010.02.11.18.34.06 mjacob Edit src/tools/make_libdeps.sh Add delta 1.9.10.2 2010.02.15.11.29.27 ru Edit src/usr.bin/netstat/if.c Add delta 1.70.2.3 2010.02.10.00.34.13 delphij Edit src/usr.bin/netstat/main.c Add delta 1.96.2.3 2010.02.10.00.34.13 delphij Edit src/usr.bin/netstat/netstat.1 Add delta 1.63.2.2 2010.02.10.00.34.13 delphij Edit src/usr.bin/netstat/netstat.h Add delta 1.58.2.3 2010.02.10.00.34.13 delphij Edit src/usr.sbin/rtsold/rtsold.c Add delta 1.23.2.2 2010.02.13.16.25.33 ume Add delta 1.23.2.3 2010.02.13.16.28.25 ume Shutting down connection to server Finished successfully # $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----Original Message----- From: Alexander Motin [mailto:mavbsd@gmail.com] On Behalf Of Alexander Motin Sent: Monday, February 15, 2010 7:01 AM To: Larry Rosenman Cc: Jeremy Chadwick; freebsd-stable@freebsd.org Subject: Re: kernel compile failure Jeremy Chadwick wrote: > On Mon, Feb 15, 2010 at 03:43:36AM -0600, Larry Rosenman wrote: >> I'm getting: >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/cam/ata/ata_xpt.c >> /usr/src/sys/cam/ata/ata_xpt.c: In function 'probestart': >> /usr/src/sys/cam/ata/ata_xpt.c:331: error: 'ATA_SF_PUIS_SPINUP' undeclared (first use in this function) >> /usr/src/sys/cam/ata/ata_xpt.c:331: error: (Each undeclared identifier is reported only once >> /usr/src/sys/cam/ata/ata_xpt.c:331: error: for each function it appears in.) >> /usr/src/sys/cam/ata/ata_xpt.c: In function 'probedone': >> /usr/src/sys/cam/ata/ata_xpt.c:789: error: 'ATA_RESP_INCOMPLETE' undeclared (first use in this function) >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/BORG. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> >> with a RELENG_8 csup'ed yesterday. >> >> Any ideas? Try to update sources again. Updated sys/ata.h file was committed same time and it includes all these constants. CVSWEB also shows all required pieces in place there. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 14:30:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24C71065670 for ; Mon, 15 Feb 2010 14:30:19 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4398FC0A for ; Mon, 15 Feb 2010 14:30:19 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1Nh1xp-0005BR-Oc; Mon, 15 Feb 2010 17:30:17 +0300 From: Boris Samorodov To: Jonathan Belson References: <33c6b0bc1002141315y6671e91dife7e80b926cb9d0b@mail.gmail.com> Date: Mon, 15 Feb 2010 17:30:18 +0300 In-Reply-To: (Jonathan Belson's message of "Sun, 14 Feb 2010 22:58:58 +0000") Message-ID: <54946837@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 14:30:19 -0000 On Sun, 14 Feb 2010 22:58:58 +0000 Jonathan Belson wrote: > On 14 Feb 2010, at 21:15, Joshua Boyd wrote: > > Here are my relevant settings: > > > > vfs.zfs.prefetch_disable=0 ^^^^^^^^^^^^^^^^^^^^^^^^^^ [1] > I already had prefetch disabled, but ... Just a note: prefetch is not disabled here [1]. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 14:34:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A5411065670 for ; Mon, 15 Feb 2010 14:34:43 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8FA8FC15 for ; Mon, 15 Feb 2010 14:34:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 5275950830; Mon, 15 Feb 2010 14:34:42 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWPPy2BPcygz; Mon, 15 Feb 2010 14:34:41 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id AD1AC50823 ; Mon, 15 Feb 2010 14:34:41 +0000 (GMT) Message-ID: <4B795B80.40805@langille.org> Date: Mon, 15 Feb 2010 09:34:40 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ulf@Alameda.net References: <4B786D3A.3000408@langille.org> <4B789643.7020606@langille.org> <20100215085655.GL30353@evil.alameda.net> In-Reply-To: <20100215085655.GL30353@evil.alameda.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , Dan Naumov Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 14:34:43 -0000 Ulf Zimmermann wrote: > On Sun, Feb 14, 2010 at 07:33:07PM -0500, Dan Langille wrote: >>> Get a dock for holding 2 x 2,5" disks in a single 5,25" slot and put >>> it at the top, in the only 5,25" bay of the case. >> That sounds very interesting. I just looking around for such a thing, >> and could not find it. Is there a more specific name? URL? > > I had an Addonics 5.25" frame for 4x 2.5" SAS/SATA but the small fans in it > are unfortunatly of the cheap kind. I ended up using the 2x2.5" to 3.5" > frame from Silverstone (for the small Silverstone case I got). Ahh, something like this: http://silverstonetek.com/products/p_contents.php?pno=SDP08&area=usa I understand now. Thank you. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 14:49:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53094106566C for ; Mon, 15 Feb 2010 14:49:35 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id 12D1E8FC0C for ; Mon, 15 Feb 2010 14:49:34 +0000 (UTC) Received: from furia.intranet ([93.104.121.188]) (AUTH: CRAM-MD5 lopez.on.the.lists@yellowspace.net, SSL: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.yellowspace.net with esmtp; Mon, 15 Feb 2010 15:39:28 +0100 id 0036A15C.000000004B795CA0.0001541C Message-ID: <4B795CA0.10408@yellowspace.net> Date: Mon, 15 Feb 2010 15:39:28 +0100 From: Lorenzo On The Lists User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jonathan Belson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 14:49:35 -0000 On 14.02.10 18:28, Jonathan Belson wrote: > The machine is a Dell SC440, dual core 2GHz E2180, 2GB of RAM and ICH7 SATA300 controller. There are three Hitachi 500GB drives (HDP725050GLA360) in a raidz1 configuration (version 13). I'm running amd64 7.2-STABLE from 14th Jan. > > First of all, I tried creating a 200MB file on / (the only non-zfs partition): > <..snip..> Hi, FYI, I Just made the same tests, on a FreeBSD 8.0-STABLE #4: Thu Dec 3 19:00:06 CET 2009, 4GB RAM, zpool comprised of: NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 1.81T 1.57T 251G 86% ONLINE - NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 zpool upgrade This system is currently running ZFS pool version 13. I'm getting near-to-hardware performance on all tests, i.e. 94MB/s minimum. Tried with 200MB, 2000MB, 4000MB and 8000MB files repeatedly. All wonderful. E.g.: dd if=/tank/testfs/testfile.dat bs=1m of=/dev/null count=8000 8388608000 bytes transferred in 83.569786 secs (100378479 bytes/sec) marx# dd if=/tank/testfs/testfile.dat bs=1m of=/dev/null count=8000 8388608000 bytes transferred in 78.234149 secs (107224378 bytes/sec) Did repeated writing and reading. I have NO ZFS-related tunables at all in /boot/loader.conf. All left to self-tuning and defaults as advised since 8.0. kstat.zfs.misc.arcstats.memory_throttle_count: 0 at all times. Regards, Lorenzo From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 15:11:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E8261065670 for ; Mon, 15 Feb 2010 15:11:17 +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 8F1D48FC12 for ; Mon, 15 Feb 2010 15:11:16 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2C3B6.dip.t-dialin.net [217.226.195.182]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 3FBB1844F62; Mon, 15 Feb 2010 16:11:09 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id CBA921A5E25; Mon, 15 Feb 2010 16:11:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1266246666; bh=EahJVXDmu5wxPFfUheNp15bUEXFE+Qj5BDIZHBB4gHQ=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=y665JfNFt8D4FK7OZAXmHOUEZoBg9kRKpvDi/zaIsJSm8xNcKRvLWjqcdASKHfNfF Nx7qBMC/QVzLKopZFozXIavITxM3wjYZw0QOTueAshR5n+jRNZiC6mhpO412ZbRSvc o4vcOLX4Mrhpo0ZlAto6Uf3qawNPfgKq87B3+/De/E/vyzN0Gpaug6kUnsRDGbq4W9 nBVqgFuW+ZuCuvxgNQEW23+sf1yiqZf2hsABfsz20n+X3DecU7Z5byfe8kSNR4lu30 TAmhmzhP0a/E7gg5X/o/2pKV80NyACpmoMAasEBzZ/ep1+XHXu8ydbyu9IBLB/n/mO zgHcSDxaX+4Xg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o1FFB5YC058730; Mon, 15 Feb 2010 16:11:05 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 15 Feb 2010 16:11:05 +0100 Message-ID: <20100215161105.14071eiflhc9le68@webmail.leidinger.net> Date: Mon, 15 Feb 2010 16:11:05 +0100 From: Alexander Leidinger To: Jeremy Chadwick References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> In-Reply-To: <20100215122744.GA57382@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 3FBB1844F62.5D740 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.363, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, TW_TX 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1266851471.73292@0Z5rk+V8krbyk2iwm+PJdA X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 15:11:17 -0000 Quoting Jeremy Chadwick (from Mon, 15 Feb 2010 04:27:44 -0800): > On Mon, Feb 15, 2010 at 10:50:00AM +0100, Alexander Leidinger wrote: >> Quoting Jeremy Chadwick (from Mon, 15 Feb >> 2010 01:07:56 -0800): >> >> >On Mon, Feb 15, 2010 at 10:49:47AM +0200, Dan Naumov wrote: >> >>> I had a feeling someone would bring up L2ARC/cache devices. This gives >> >>> me the opportunity to ask something that's been on my mind for quite >> >>> some time now: >> >>> >> >>> Aside from the capacity different (e.g. 40GB vs. 1GB), is there a >> >>> benefit to using a dedicated RAM disk (e.g. md(4)) to a pool for >> >>> L2ARC/cache? The ZFS documentation explicitly states that cache >> >>> device content is considered volatile. >> >> >> >>Using a ramdisk as an L2ARC vdev doesn't make any sense at all. If you >> >>have RAM to spare, it should be used by regular ARC. >> > >> >...except that it's already been proven on FreeBSD that the ARC getting >> >out of control can cause kernel panics[1], horrible performance until > > First and foremost, sorry for the long post. I tried to keep it short, > but sometimes there's just a lot to be said. And sometimes a shorter answer takes longer... >> There are other ways (not related to ZFS) to shoot into your feet >> too, I'm tempted to say that this is >> a) a documentation bug >> and >> b) a lack of sanity checking of the values... anyone out there with >> a good algorithm for something like this? >> >> Normally you do some testing with the values you use, so once you >> resolved the issues, the system should be stable. > > What documentation? :-) The Wiki? If so, that's been outdated for Hehe... :) > some time; I know Ivan Voras was doing his best to put good information > there, but it's hard given the below chaos. Do you want write access to it (in case you haven't, I didn't check)? > The following tunables are recurrently mentioned as focal points, but no > one's explained in full how to tune these "properly", or which does what > (perfect example: vm.kmem_size_max vs. vm.kmem_size. _max used to be > what you'd adjust to solve kmem exhaustion issues, but now people are > saying otherwise?). I realise it may differ per system (given how much > RAM the system has), so different system configurations/examples would > need to be provided. I realise that the behaviour of some have changed > too (e.g. -RELEASE differs from -STABLE, and 7.x differs from 8.x). > I've marked commonly-referred-to tunables with an asterisk: It can also be that some people just tell something without really knowing what they say (based upon some kind of observed evidence, not because of being a bad guy). > kern.maxvnodes Needs to be tuned if you run out of vnodes... ok, this is obvious. I do not know how it will show up (panic or graceful error handling, e.g. ENOMEM). > * vm.kmem_size > * vm.kmem_size_max I tried kmem_size_max on -current (this year), and I got a panic during use, I changed kmem_size to the same value I have for _max and it didn't panic anymore. It looks (from mails on the lists) that _max is supposed to give a max value for auto-enhancement, but at least it was not working with ZFS last month (and I doubt it works now). > * vfs.zfs.arc_min > * vfs.zfs.arc_max _min = minimum even when the system is running out of memory (the ARC gives back memory if other parts of the kernel need it). _max = maximum (with a recent ZFS on 7/8/9 (7.3 will have it, 8.1 will have it too) I've never seen the size exceed the _max anymore) > vfs.zfs.prefetch_disable (auto-tuned based on available RAM on 8-STABLE) > vfs.zfs.txg.timeout It looks like the txg is just a workaround. I've read a little bit in Brendan's blog and it seems they noticed the periodic writes too (with the nice graphical performance monitoring of OpenStorage) and they are investigating the issue. It looks like we are more affected by this (for whatever reason). What it is doing (attention, this is an observation, not a technical description of code I've read!) seems to be to write out data to the disks more early (and thus there is less data to write -> less blocking to notice). > vfs.zfs.vdev.cache.size > vfs.zfs.vdev.cache.bshift > vfs.zfs.vdev.max_pending Uhm... this smells like you got it out of one of my posts where I told that I experiment with this on a system. I can tell you that I have no system with this tuned anymore, tuning kmem_size (and KVA_PAGES during kernel compile) has a bigger impact. > vfs.zfs.zil_disable What it does should be obvious. IMHO this should not help much regarding stability (changing kmem_size should give a bigger impact). As don't know what was tested on systems where this is disabled, I want to highlight the "IMHO" in the sentence before... > Then, when it comes to debugging problems as a result of tuning > improperly (or entire lack of), the following counters (not tunables) > are thrown into the mix as "things people should look at": > > kstat.zfs.misc.arcstats.c > kstat.zfs.misc.arcstats.c_min > kstat.zfs.misc.arcstats.c_max c_max is vfs.zfs.arc_max, c_min is vfs.zfs.arc_min. > kstat.zfs.misc.arcstats.evict_skip > kstat.zfs.misc.arcstats.memory_throttle_count > kstat.zfs.misc.arcstats.size I'm not very sure about size and c... both represent some kind of current size, but they are not the same. About the tuning I would recommend to depend upon a more human readable representation. I've seen someone posting something like this, but I do not know how it was generated (some kind of script, but I do not know where to get it). > All that said: > > I would be more than happy to write some coherent documentation that > folks could refer to "officially", but rather than spend my entire > lifetime reverse-engineering the ZFS code I think it'd make more sense > to get some official parties involved to explain things. http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide > I'd like to add some kind of monitoring section as well -- how > administrators could keep an eye on things and detect, semi-early, if > additional tuning is required or something along those lines. > >> >ZFS has had its active/inactive lists flushed[2], and brings into >> >> Someone needs to sit down and play a little bit with ways to tell >> the ARC that there is free memory. The mail you reference already >> tells that the inactive/cached lists should maybe taken into account >> too (I didn't had a look at this part of the ZFS code). >> >> >question how proper tuning is to be established and what the effects are >> >on the rest of the system[3]. There are still reports of people >> >> That's what I talk about regarding b) above. If you specify an >> arc_max which is too big (arc_max > kmem_size - SOME_SAVE_VALUE), >> there should be a message from the kernel and the value should be >> adjusted to a save amount. >> >> Until the problems are fixed, a MD for L2ARC may be a viable >> alternative (if you have enough mem to give for this). Feel free to >> provide benchmark numbers, but in general I see this just as a >> workaround for the current issues. > > I've played with this a bit (2-disk mirror + one 256MB md), but I'm not > completely sure how to read the bonnie++ results, nor am I sure I'm > using the right arguments (bonnie++ -s8192 -n64 -d/pool on a machine > that has 4GB). > > L2ARC ("cache" vdev) is supposed to improve random reads, while a "log" It is supposed to improve random reads, if the working set is in the cache... > vdev (presumably something that links in with the ZIL) improves random > writes. I'm not sure where bonnie++ tests random reads, but I do see it It is not supposed to improve random writes, it is supposed to improve direct writes (man 2 open, search for O_FSYNC... in Solaris it is O_DSYNC). > testing random seeks. [...] > The options as I see them are (a)) figure out some *reliable* way to > describe to folks how to tune their systems to not experience ARC or > memory exhaustion related issues, or (b) utilise L2ARC exclusively and > set the ARC (arc_max) to something fairly small. I would prefer a) together with some more sanity checking when changing the values. :) It is just that it is not easy to come up with a correct sanity checking... Bye, Alexander. -- If sarcasm were posted on Usenet, would anybody notice? -- James Nicoll http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 15:45:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCB8B1065679 for ; Mon, 15 Feb 2010 15:45:37 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf03.insightbb.com (mxsf03.insightbb.com [74.128.0.64]) by mx1.freebsd.org (Postfix) with ESMTP id 933A88FC1A for ; Mon, 15 Feb 2010 15:45:36 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,478,1262581200"; d="scan'208";a="799750723" Received: from unknown (HELO asav00.insightbb.com) ([172.31.249.123]) by mxsf03.insightbb.com with ESMTP; 15 Feb 2010 10:45:35 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEP7eEvQLicL/2dsb2JhbACcEL0jhFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,478,1262581200"; d="scan'208";a="8676895" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout00.insightbb.com with ESMTP; 15 Feb 2010 10:45:35 -0500 From: Steven Friedrich To: Gavin Atkinson Date: Mon, 15 Feb 2010 10:45:29 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; i386; ; ) References: <201001300708.37683.freebsd@insightbb.com> In-Reply-To: X-Face: i~b2iK'Z*tJ)pO9@6lJG=k7>N, V~YMq":Iwdl!m|A"g, N@)'|zb[{ Cc: freebsd-stable@freebsd.org Subject: Re: loading module sdhci causes panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 15:45:37 -0000 On Sunday 14 February 2010 01:53:11 pm Gavin Atkinson wrote: > On Sat, 30 Jan 2010, Steven Friedrich wrote: > What happens if you just load sdhci? panic > WHat happens if you load sdhci and mmcsd, but not mmc? panic > WHat happens if you load sdhci and mmc, but not mmcsd? panic > > Given how early in the boot process you see problems, I'm wondering if > this is somehow related to PR kern/141756... > > Thanks, > > Gavin > If I load sdhci as a module, the system panics with a page fault while in kernel mode. All is ok if I build sdhci into the kernel. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 15:57:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB717106566B for ; Mon, 15 Feb 2010 15:57:07 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id BE0BF8FC15 for ; Mon, 15 Feb 2010 15:57:07 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-37.bna.bellsouth.net [74.241.172.37]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1FFv498047602 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Feb 2010 10:57:05 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Martin Kristensen In-Reply-To: <20100215142305.3f0d7e65@miknet.dk> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> <201002131137.34812.npapke@acm.org> <1266096425.89452.30.camel@balrog.2hip.net> <20100215142305.3f0d7e65@miknet.dk> Content-Type: text/plain Organization: FreeBSD Date: Mon, 15 Feb 2010 09:56:58 -0600 Message-Id: <1266249418.11131.7.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 15:57:08 -0000 On Mon, 2010-02-15 at 14:23 +0100, Martin Kristensen wrote: > On Sat, 13 Feb 2010 15:27:04 -0600 > Robert Noland wrote: > > > On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: > > > On February 13, 2010, Robert Noland wrote: > > > > Ok, I've put up a patch at: > > > > > > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > > > > > > > http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch > > > > This one should work on 8... > > > > robert. > > > > > > This is sort of a mega patch and includes: > > > > > > > > Re-worked drm mapping code, that ensures that we don't end up > > > > incorrectly mapping certain maps with overlapping offsets. This > > > > generally shows up as the ring buffer not being cleared > > > > (contents != 0 in xorg.log) which leads to corruption and other > > > > bad behavior. > > > > > > > > Re-written scatter gather allocation code. This interacts > > > > directly with the VM system, rather than using bus_dma to allow > > > > us to grab non-contiguous pages for the scatter gather backing of > > > > the GART. It also makes it easier to handle the caching mode of > > > > the backing pages. > > > > > > > > Disable cache snooping on radeon cards, since we have write > > > > combining set properly now. > > > > > > > > I have at least done a test build on -CURRENT with this patch, > > > > but I haven't had time to do much else without the rest of the > > > > code in my tree. I've been running most all of this code for a > > > > month or two now at least, so it is mostly just a question of > > > > whether or not I got all of the conflicts sorted out properly > > > > when I made this patch. > > > > > > > > The re-mapping code has the most widespread impact and has been > > > > tested on radeon r600 amd64, intel g45 i386 and mga amd64. > > > > > > > > robert. > > The patch applied cleanly. I have applied the patch to a clean 8-STABLE > environment with WITNESS, INVARIANTS and KDB_UNATTENDED in the kernel. > I still see the crashes when starting X with DRI on. This is what I see > in messages: > > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7b000 > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7c000 > Feb 14 19:13:44 alpha kernel: > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7d000 > Feb 14 19:13:44 alpha kernel: > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7e000 > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 0000070001c7f000 > Feb 14 19:13:44 alpha kernel: > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0xc0286415, nr=0x15, dev 0xffffff0001a79400, auth=1 > Feb 14 19:13:44 alpha kernel: > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] offset = 0xfe8e0000, size = 0x00010000, type = 1 > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Found kernel map 1 > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Added map 1 0xfe8e0000/0x10000 > Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0x80106459, nr=0x59, dev 0xffffff0001a79400, auth=1 > > > There has been one odd development. If I startx with DRI off or NoAccel > set it starts as usual. If I then quit and to cli and restart, I see the > same crash as if I had DRI on. I'm really starting to think that this is a bug in the Xserver somewhere... If DRI is off, the kernel drm is not involved at all. The radeon driver does grope around on the pci bus (via libpciaccess) which could potentially cause issues, but... miwi and a few other folks have picked up the ball to get us up to xorg 7.5, since I just don't have time to do it all now. That might be a good thing to try, I expect that they will have a patch ready soon, like within a few days. robert. > Martin -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 16:25:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1801B106568B for ; Mon, 15 Feb 2010 16:25:50 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E071D8FC0C for ; Mon, 15 Feb 2010 16:25:49 +0000 (UTC) Received: by pxi12 with SMTP id 12so3392519pxi.33 for ; Mon, 15 Feb 2010 08:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=y0VjKFeqLvtrFxFqALSSoT+DO6mt9oTD5KH0cDl/c44=; b=u+N1pbbetSow17vpCWXcWOa5rrfpmCrn1vFSXgwLN0VcnWjCGKf7HcTYG4CoZICAn9 OJ4Ho5p/MRajed6+kiV0t0Y2KwLPs4ol4PusM/F9uiUttvHPFHK7KGZO1DTwtPoJy1NS uxBnErEQKP2Oab3rvAnTPUAEHUI6V7RZqG3QY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F9A6p4N6L6pEX5D4mvFeGeqOQMezBTRcjZ7VFgcXNlJzmr33TNUf/QD4fBsEqrCIjq e+aZ/WMCMTypnDE1BYQlWYyyZtGsa27XRJ//EmovhL62xRQluiJGUtQtStyV3R9EiGiO mXx75cKTFRO7ryTCV0VegIVsm4fpHsQGDXMaI= MIME-Version: 1.0 Received: by 10.142.56.12 with SMTP id e12mr3487196wfa.332.1266251149332; Mon, 15 Feb 2010 08:25:49 -0800 (PST) In-Reply-To: References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> Date: Mon, 15 Feb 2010 08:25:49 -0800 Message-ID: <147432021002150825v7b3fedb6y64f6dbfdf588dc93@mail.gmail.com> From: Nick Rogers To: Giacomo Olgeni Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 16:25:50 -0000 hw.bge.allow_asf: 0 On Mon, Feb 15, 2010 at 2:23 AM, Giacomo Olgeni wrote: > > Hello, > > Are you running with hw.bge.allow_asf enabled? > > > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 16:41:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 359B41065692 for ; Mon, 15 Feb 2010 16:41:52 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailC.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.204]) by mx1.freebsd.org (Postfix) with ESMTP id 05F9D8FC08 for ; Mon, 15 Feb 2010 16:41:51 +0000 (UTC) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BCF70233A7 for ; Mon, 15 Feb 2010 11:31:33 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id 7FFB9233D1 for ; Mon, 15 Feb 2010 11:31:28 -0500 (EST) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id 78076233A7 for ; Mon, 15 Feb 2010 11:31:28 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id 6256A5B003A for ; Mon, 15 Feb 2010 11:31:19 -0500 (EST) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-PrVDe/8OmMfgFYglvmGl" Date: Mon, 15 Feb 2010 11:31:19 -0500 Message-Id: <1266251479.6979.28.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Subject: 7.3-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 16:41:52 -0000 --=-PrVDe/8OmMfgFYglvmGl Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The second of the test builds for the 7.3-RELEASE cycle, 7.3-RC1, is now available for amd64, i386, pc98, and sparc64 architectures. The target schedule as well as the current status of the release is available here: http://wiki.freebsd.org/Releng/7.3TODO The schedule has slipped by about a week but so far it looks like we are on track for just having one more public test build (7.3-RC2) followed by the release itself. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-stable mailing list. ISO images for the architectures listed above are available on the FTP mirror sites. Packages were included for amd64 and i386 architectures though the list of packages is still preliminary and the packages themselves were taken from what is currently available in the packages-7-stable directories on the FTP servers. There have been some significant changes to the ports that are not incorporated in this set of pre-built packages (e.g. the default version of perl has been updated to 5.10). If you are using csup/cvsup methods to update an older system the branch tag to use is now RELENG_7_3. Note that due to the mechanism still in place for exporting the SVN repository to CVS unfortunately the version numbers for all the files get changed. If you have not looked into it before check out the -F argument for mergemaster(8). The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.1-RELEASE 7.2-RELEASE, or 7.3-BETA1 can upgrade as follows: =20 # freebsd-update upgrade -r 7.3-RC1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. =20 # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now =20 After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to upgrade to FreeBSD 7.3-RC1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 6.x and FreeBSD 7.x. Checksums: MD5 (FreeBSD-7.3-RC1-amd64-bootonly.iso) =3D 9203d41e40bfaa916a493e0ec7de7b= 43 MD5 (FreeBSD-7.3-RC1-amd64-disc1.iso) =3D e6601834cb700e4c250439ada6e55684 MD5 (FreeBSD-7.3-RC1-amd64-disc2.iso) =3D 4e8b9f30078b0bee18b8cded3b9889b4 MD5 (FreeBSD-7.3-RC1-amd64-disc3.iso) =3D 045cb0e6fb365d3542fe1ff22bdb386b MD5 (FreeBSD-7.3-RC1-amd64-docs.iso) =3D 6f84de26ee4141c84dfbc3e75937553f MD5 (FreeBSD-7.3-RC1-amd64-dvd1.iso) =3D 3db866ef9b922a2ee4fa05860370f66f MD5 (FreeBSD-7.3-RC1-amd64-livefs.iso) =3D 0bd317eaacb4b410c6a9b505570cdcf2 MD5 (FreeBSD-7.3-RC1-i386-bootonly.iso) =3D 72e07086fd7d772dab19b3c37158228= e MD5 (FreeBSD-7.3-RC1-i386-disc1.iso) =3D 94beb0afaa3f7b90403842b32d23e5f8 MD5 (FreeBSD-7.3-RC1-i386-disc2.iso) =3D 2972b3033fb5f49c46e5896ce59c0de6 MD5 (FreeBSD-7.3-RC1-i386-disc3.iso) =3D 129eb39afdb5ed80b08cc425cdd838af MD5 (FreeBSD-7.3-RC1-i386-docs.iso) =3D d754c44cee26f1d386db9550d3839c0e MD5 (FreeBSD-7.3-RC1-i386-dvd1.iso) =3D 53553d8b3197f2146e1e135e3779ab39 MD5 (FreeBSD-7.3-RC1-i386-livefs.iso) =3D 72bfb8309379e2f2b0cb00fa82aa4329 MD5 (FreeBSD-7.3-RC1-pc98-bootonly.iso) =3D ef34e0b903a16212c40d3a28c124bf1= e MD5 (FreeBSD-7.3-RC1-pc98-disc1.iso) =3D f6df8cf617a96d4fbcc6732cbd92de27 MD5 (FreeBSD-7.3-RC1-pc98-livefs.iso) =3D 72816364465e561074d6260e862c40ee MD5 (FreeBSD-7.3-RC1-sparc64-bootonly.iso) =3D fa2d3a04b3524c0a6441b27ab3e9= c260 MD5 (FreeBSD-7.3-RC1-sparc64-disc1.iso) =3D 8b7c20c4de27bd6f8dcdcacc9c3086f= d MD5 (FreeBSD-7.3-RC1-sparc64-disc2.iso) =3D 856250a506426adea48a2d8c36eaaf6= 0 MD5 (FreeBSD-7.3-RC1-sparc64-disc3.iso) =3D 9e91eba398769bb3b8bf88b3a45a7e9= f MD5 (FreeBSD-7.3-RC1-sparc64-docs.iso) =3D 392698fa73e325a49ca8a350bca7e15c SHA256 (FreeBSD-7.3-RC1-amd64-bootonly.iso) =3D 244a7b3a14cdd03b69038d19236= 929085b76867b238ecaab0bdeda21be98e6f8 SHA256 (FreeBSD-7.3-RC1-amd64-disc1.iso) =3D 55b62c9926c4b15561d9fb8b4dae74= ce051f0389e00fbf08d888f41491288bc1 SHA256 (FreeBSD-7.3-RC1-amd64-disc2.iso) =3D 3f8d314d917ace574c98957cb99e60= 94d6b3ee43e15a27786fe305afcb61c267 SHA256 (FreeBSD-7.3-RC1-amd64-disc3.iso) =3D 349c0da03bf42c399da2e8235dbdf8= 877dfc5ca601b38110c1decd88b8322239 SHA256 (FreeBSD-7.3-RC1-amd64-docs.iso) =3D 901bb101d7c428f10065b2b78a2a276= 70c36d832afb4e96f239f3ff1b5f3603a SHA256 (FreeBSD-7.3-RC1-amd64-dvd1.iso) =3D 6ebfba0e66d3a23077c74407bb6d1bd= ff7f45d690aae7f1c08753c7a41ee5125 SHA256 (FreeBSD-7.3-RC1-amd64-livefs.iso) =3D 88b2c22f37ed5a80eb2600aaa85d3= 47af534a18ff41450462bd8174c06f033b2 SHA256 (FreeBSD-7.3-RC1-i386-bootonly.iso) =3D dd7a06c197c62f10b85b9fd9bad2= 09b677d9c0a497bb84b9f5276ee088e55b1d SHA256 (FreeBSD-7.3-RC1-i386-disc1.iso) =3D 226153815575aa4e43e3772f1abdfc6= 9084a825e4f269fbe953ffafb5be2112d SHA256 (FreeBSD-7.3-RC1-i386-disc2.iso) =3D 976172cf5c4c67c589c6f8234ab9616= 210509c34ab485e1384a7a589a6459d6a SHA256 (FreeBSD-7.3-RC1-i386-disc3.iso) =3D ddeaed4ef86d3c69d7096b6a363ca43= 226e0c923881e1a70846e87ce8f20782f SHA256 (FreeBSD-7.3-RC1-i386-docs.iso) =3D 4adcb739cf5d0ed54ac564129d3d972f= f76439cba8e8027f80ea7242d5272bcb SHA256 (FreeBSD-7.3-RC1-i386-dvd1.iso) =3D f7f5663b1b2b7716edd96517c3f511ea= 7ec1605f46c453d58b0f31c6ab7df5be SHA256 (FreeBSD-7.3-RC1-i386-livefs.iso) =3D 42e28e767afe8ff8b51199a8891416= 37576d939d3adf4566b07bb7360b7e98b2 SHA256 (FreeBSD-7.3-RC1-pc98-bootonly.iso) =3D 83f7e822e7e18794ff3a5b6f8b04= 1c9dd3eb7d54a9b7b49803ceb49fee3c0113 SHA256 (FreeBSD-7.3-RC1-pc98-disc1.iso) =3D e9f0072b4f4f0053a1967fdc0b0456d= 156abc1df17481eac6083c1527331912e SHA256 (FreeBSD-7.3-RC1-pc98-livefs.iso) =3D f93258ea2f25fe84c9a69014ef6677= 8585e1d34a18167d99bf7f59147544af2f SHA256 (FreeBSD-7.3-RC1-sparc64-bootonly.iso) =3D ef40738bc1f02d4d93a984656= 0fd553de52b8cd350eec0ba9377d3cf23ed2319 SHA256 (FreeBSD-7.3-RC1-sparc64-disc1.iso) =3D d922a754de7c826679281887eadd= 78fb520cc428fea6bc8f0c14178b01ab559d SHA256 (FreeBSD-7.3-RC1-sparc64-disc2.iso) =3D 5e99fc0d9324c5acfed3498b111b= 081f9b11a035457822fb1fee187a71abc74c SHA256 (FreeBSD-7.3-RC1-sparc64-disc3.iso) =3D 5e78718de7898753d2701f7ff27e= a09d44544a0cfa4a7aba3bbaa855c22b0636 SHA256 (FreeBSD-7.3-RC1-sparc64-docs.iso) =3D 048e045a418ebea6cbe2a27c36f8d= 9e56de19c107a6ffc8d776bf3c4207eb6ae --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-PrVDe/8OmMfgFYglvmGl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkt5dswACgkQ/G14VSmup/bJ2gCaA/0eC4x24xFdekrGjgbhc5jp H44AoJvP1/oirl1GL1KY9RbkS+RVlw7R =zDNO -----END PGP SIGNATURE----- --=-PrVDe/8OmMfgFYglvmGl-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 16:54:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5211110656A9 for ; Mon, 15 Feb 2010 16:54:49 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 142158FC08 for ; Mon, 15 Feb 2010 16:54:48 +0000 (UTC) Received: by iwn5 with SMTP id 5so1929657iwn.9 for ; Mon, 15 Feb 2010 08:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=P67gEQvaCwFLa+xIiOAPs1oeRs08Jio8HQd294OhM/w=; b=ai49KclE+bMsErS0sQwue415Ur0FBA2qE+w58hjLBqRUN8mQVJvRIUiebgK88tvGNv jhX3EbXjAdfKXFSlK0SalQozj+rYIyV008eEW8PER88wNQFItc6TfQt6LgyvjSflty5s 8oUwhcG4Cc8XUL7lMQDlx7fvaMBDVBWJUKy3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wAQwOeHeR+C2cK3m8r1WilcaNSdHuBIWQsqH55+6h8+VXDYbujcK6YGTtAI/LAaqlr iGXy35chCSQ4ePmiAFauj/Fb3JtkhYtTX+SLRpznjpxBokYuPQSt0XIdu+36Ux7bgb13 BMUgudGDRa7geouLW1LifOMig/0QHDmsj5kUc= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.147.199 with SMTP id m7mr5643404ibv.87.1266252888230; Mon, 15 Feb 2010 08:54:48 -0800 (PST) In-Reply-To: <20100215161105.14071eiflhc9le68@webmail.leidinger.net> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> Date: Mon, 15 Feb 2010 08:54:48 -0800 X-Google-Sender-Auth: 96546ad3d5fbdc38 Message-ID: From: Artem Belevich To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 16:54:49 -0000 >> * vm.kmem_size >> * vm.kmem_size_max > > I tried kmem_size_max on -current (this year), and I got a panic during u= se, > I changed kmem_size to the same value I have for _max and it didn't panic > anymore. It looks (from mails on the lists) that _max is supposed to give= a > max value for auto-enhancement, but at least it was not working with ZFS > last month (and I doubt it works now). It used to be that vm.kmem_size_max needed to be bumped to allow for larger vm.kmem_size. It's no longer needed on amd64. Not sure about i386. vm.kmem_size still needs tuning, though. While vm.kmem_size_max is no longer a limit, there are other checks in place that result in default vm.kmem_size being a bit on the conservative side for ZFS. >> Then, when it comes to debugging problems as a result of tuning >> improperly (or entire lack of), the following counters (not tunables) >> are thrown into the mix as "things people should look at": >> >> =A0kstat.zfs.misc.arcstats.c >> =A0kstat.zfs.misc.arcstats.c_min >> =A0kstat.zfs.misc.arcstats.c_max > > c_max is vfs.zfs.arc_max, c_min is vfs.zfs.arc_min. > >> =A0kstat.zfs.misc.arcstats.evict_skip >> =A0kstat.zfs.misc.arcstats.memory_throttle_count >> =A0kstat.zfs.misc.arcstats.size > > I'm not very sure about size and c... both represent some kind of current > size, but they are not the same. arcstats.c -- adaptive ARC target size. I.e. that's what ZFS thinks it can grow ARC to. It's dynamically adjusted based on when/how ZFS is back-pressured for memory. arcstats.size -- current ARC size arcstats.p -- portion of arcstats.c that's used by "Most Recently Used" items. What's left of arcstats.c is used by "Most Frequently Used" items. --Artem From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 17:01:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 645AC10656CD for ; Mon, 15 Feb 2010 17:01:59 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2AC8FC26 for ; Mon, 15 Feb 2010 17:01:57 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta07.emeryville.ca.mail.comcast.net with comcast id iEG81d0090FhH24A7H1yoL; Mon, 15 Feb 2010 17:01:58 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.emeryville.ca.mail.comcast.net with comcast id iH1x1d00J3S48mS8UH1x65; Mon, 15 Feb 2010 17:01:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8D2641E301A; Mon, 15 Feb 2010 09:01:56 -0800 (PST) Date: Mon, 15 Feb 2010 09:01:56 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215170156.GA64731@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 17:01:59 -0000 On Sun, Feb 14, 2010 at 05:28:28PM +0000, Jonathan Belson wrote: > Hiya > > After reading some earlier threads about zfs performance, I decided to test my own server. I found the results rather surprising... Below are my results from my home machine. Note that my dd size and count differ from what the OP provided. I should note that powerd(8) is in effect on this box; I probably should have disabled it and forced the CPU frequency to be at max before doing these tests. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | # uname -a FreeBSD icarus.home.lan 8.0-STABLE FreeBSD 8.0-STABLE #0: Sat Jan 16 17:48:04 PST 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 # uptime 6:51AM up 29 days, 12:48, 2 users, load averages: 0.06, 0.04, 0.01 # sysctl hw.machine hw.model hw.ncpu hw.physmem hw.usermem hw.realmem hw.pagesizes hw.machine: amd64 hw.model: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz hw.ncpu: 2 hw.physmem: 4285317120 hw.usermem: 3520425984 hw.realmem: 5100273664 hw.pagesizes: 4096 2097152 0 # sysctl vm.kmem_size vm.kmem_size_min vm.kmem_size_max vm.kmem_size_scale vm.kmem_size: 1378439168 vm.kmem_size_min: 0 vm.kmem_size_max: 329853485875 vm.kmem_size_scale: 3 # dmesg | egrep '(ata[57]|atapci0)' atapci0: port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x18e0-0x18ff mem 0xdc000800-0xdc000fff irq 17 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM supported ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata7: on atapci0 ata7: [ITHREAD] ad10: 953869MB at ata5-master UDMA100 SATA 3Gb/s ad14: 953869MB at ata7-master UDMA100 SATA 3Gb/s # egrep '^[a-z]' /boot/loader.conf kern.maxdsiz="1536M" kern.dfldsiz="1536M" kern.maxssiz="256M" hint.sio.1.disabled="1" vm.pmap.pg_ps_enabled="1" vfs.zfs.prefetch_disable="1" debug.cpufreq.lowest="1500" # zpool status pool: storage state: ONLINE scrub: scrub stopped after 0h27m with 0 errors on Fri Feb 12 10:55:49 2010 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 mirror ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad14 ONLINE 0 0 0 errors: No known data errors kstat.zfs.misc.arcstats before tests ====================================== kstat.zfs.misc.arcstats.hits: 102892520 kstat.zfs.misc.arcstats.misses: 1043985 kstat.zfs.misc.arcstats.demand_data_hits: 100502054 kstat.zfs.misc.arcstats.demand_data_misses: 1010714 kstat.zfs.misc.arcstats.demand_metadata_hits: 2390466 kstat.zfs.misc.arcstats.demand_metadata_misses: 33271 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 4675003 kstat.zfs.misc.arcstats.mru_ghost_hits: 11655 kstat.zfs.misc.arcstats.mfu_hits: 98217517 kstat.zfs.misc.arcstats.mfu_ghost_hits: 15079 kstat.zfs.misc.arcstats.deleted: 2456180 kstat.zfs.misc.arcstats.recycle_miss: 6236 kstat.zfs.misc.arcstats.mutex_miss: 1238 kstat.zfs.misc.arcstats.evict_skip: 0 kstat.zfs.misc.arcstats.hash_elements: 5753 kstat.zfs.misc.arcstats.hash_elements_max: 23704 kstat.zfs.misc.arcstats.hash_collisions: 643164 kstat.zfs.misc.arcstats.hash_chains: 229 kstat.zfs.misc.arcstats.hash_chain_max: 5 kstat.zfs.misc.arcstats.p: 839285616 kstat.zfs.misc.arcstats.c: 841024368 kstat.zfs.misc.arcstats.c_min: 107690560 kstat.zfs.misc.arcstats.c_max: 861524480 kstat.zfs.misc.arcstats.size: 96783432 kstat.zfs.misc.arcstats.hdr_size: 1196624 kstat.zfs.misc.arcstats.l2_hits: 258 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 3337 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 576 kstat.zfs.misc.arcstats.l2_writes_done: 576 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 6 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 2 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 797 kstat.zfs.misc.arcstats.l2_abort_lowmem: 14 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 8929 test #1 (327,680,000 bytes) ============================= # dd if=/dev/zero of=/storage/test01 bs=64k count=5000 5000+0 records in 5000+0 records out 327680000 bytes transferred in 0.500110 secs (655215969 bytes/sec) test #1 (kstat.zfs.misc.arcstats) =================================== kstat.zfs.misc.arcstats.hits: 102894825 kstat.zfs.misc.arcstats.misses: 1043985 kstat.zfs.misc.arcstats.demand_data_hits: 100504066 kstat.zfs.misc.arcstats.demand_data_misses: 1010714 kstat.zfs.misc.arcstats.demand_metadata_hits: 2390759 kstat.zfs.misc.arcstats.demand_metadata_misses: 33271 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 4675145 kstat.zfs.misc.arcstats.mru_ghost_hits: 11655 kstat.zfs.misc.arcstats.mfu_hits: 98219680 kstat.zfs.misc.arcstats.mfu_ghost_hits: 15079 kstat.zfs.misc.arcstats.deleted: 2456182 kstat.zfs.misc.arcstats.recycle_miss: 6236 kstat.zfs.misc.arcstats.mutex_miss: 1238 kstat.zfs.misc.arcstats.evict_skip: 0 kstat.zfs.misc.arcstats.hash_elements: 8275 kstat.zfs.misc.arcstats.hash_elements_max: 23704 kstat.zfs.misc.arcstats.hash_collisions: 643458 kstat.zfs.misc.arcstats.hash_chains: 436 kstat.zfs.misc.arcstats.hash_chain_max: 5 kstat.zfs.misc.arcstats.p: 839285616 kstat.zfs.misc.arcstats.c: 841024368 kstat.zfs.misc.arcstats.c_min: 107690560 kstat.zfs.misc.arcstats.c_max: 861524480 kstat.zfs.misc.arcstats.size: 425377840 kstat.zfs.misc.arcstats.hdr_size: 1721200 kstat.zfs.misc.arcstats.l2_hits: 258 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 3337 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 576 kstat.zfs.misc.arcstats.l2_writes_done: 576 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 6 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 2 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 797 kstat.zfs.misc.arcstats.l2_abort_lowmem: 14 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 8929 test #2 (3,276,800,000 bytes) =============================== # dd if=/dev/zero of=/storage/test02 bs=64k count=50000 50000+0 records in 50000+0 records out 3276800000 bytes transferred in 36.670274 secs (89358481 bytes/sec) test #2 (kstat.zfs.misc.arcstats) =================================== kstat.zfs.misc.arcstats.hits: 102897079 kstat.zfs.misc.arcstats.misses: 1043986 kstat.zfs.misc.arcstats.demand_data_hits: 100506196 kstat.zfs.misc.arcstats.demand_data_misses: 1010715 kstat.zfs.misc.arcstats.demand_metadata_hits: 2390883 kstat.zfs.misc.arcstats.demand_metadata_misses: 33271 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 4677086 kstat.zfs.misc.arcstats.mru_ghost_hits: 11655 kstat.zfs.misc.arcstats.mfu_hits: 98219993 kstat.zfs.misc.arcstats.mfu_ghost_hits: 15080 kstat.zfs.misc.arcstats.deleted: 2474133 kstat.zfs.misc.arcstats.recycle_miss: 6275 kstat.zfs.misc.arcstats.mutex_miss: 1238 kstat.zfs.misc.arcstats.evict_skip: 0 kstat.zfs.misc.arcstats.hash_elements: 14185 kstat.zfs.misc.arcstats.hash_elements_max: 23704 kstat.zfs.misc.arcstats.hash_collisions: 649617 kstat.zfs.misc.arcstats.hash_chains: 2277 kstat.zfs.misc.arcstats.hash_chain_max: 5 kstat.zfs.misc.arcstats.p: 832921238 kstat.zfs.misc.arcstats.c: 834619760 kstat.zfs.misc.arcstats.c_min: 107690560 kstat.zfs.misc.arcstats.c_max: 861524480 kstat.zfs.misc.arcstats.size: 834412096 kstat.zfs.misc.arcstats.hdr_size: 3222752 kstat.zfs.misc.arcstats.l2_hits: 258 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 3337 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 576 kstat.zfs.misc.arcstats.l2_writes_done: 576 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 6 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 2 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 797 kstat.zfs.misc.arcstats.l2_abort_lowmem: 14 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 8962 test #3 (6,553,600,000 bytes) =============================== # dd if=/dev/zero of=/storage/test03 bs=64k count=100000 100000+0 records in 100000+0 records out 6553600000 bytes transferred in 75.465144 secs (86842741 bytes/sec) test #3 (kstat.zfs.misc.arcstats) =================================== kstat.zfs.misc.arcstats.hits: 102903298 kstat.zfs.misc.arcstats.misses: 1043991 kstat.zfs.misc.arcstats.demand_data_hits: 100511551 kstat.zfs.misc.arcstats.demand_data_misses: 1010720 kstat.zfs.misc.arcstats.demand_metadata_hits: 2391747 kstat.zfs.misc.arcstats.demand_metadata_misses: 33271 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 4681172 kstat.zfs.misc.arcstats.mru_ghost_hits: 11655 kstat.zfs.misc.arcstats.mfu_hits: 98222126 kstat.zfs.misc.arcstats.mfu_ghost_hits: 15083 kstat.zfs.misc.arcstats.deleted: 2523071 kstat.zfs.misc.arcstats.recycle_miss: 6281 kstat.zfs.misc.arcstats.mutex_miss: 1238 kstat.zfs.misc.arcstats.evict_skip: 0 kstat.zfs.misc.arcstats.hash_elements: 16782 kstat.zfs.misc.arcstats.hash_elements_max: 23704 kstat.zfs.misc.arcstats.hash_collisions: 659104 kstat.zfs.misc.arcstats.hash_chains: 2014 kstat.zfs.misc.arcstats.hash_chain_max: 5 kstat.zfs.misc.arcstats.p: 832935741 kstat.zfs.misc.arcstats.c: 834601840 kstat.zfs.misc.arcstats.c_min: 107690560 kstat.zfs.misc.arcstats.c_max: 861524480 kstat.zfs.misc.arcstats.size: 834578624 kstat.zfs.misc.arcstats.hdr_size: 3490656 kstat.zfs.misc.arcstats.l2_hits: 258 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 3337 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 576 kstat.zfs.misc.arcstats.l2_writes_done: 576 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 6 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 2 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 797 kstat.zfs.misc.arcstats.l2_abort_lowmem: 14 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 9037 test #4 (9,830,400,000 bytes) =============================== # dd if=/dev/zero of=/storage/test04 bs=64k count=150000 150000+0 records in 150000+0 records out 9830400000 bytes transferred in 117.682951 secs (83532915 bytes/sec) test #4 (kstat.zfs.misc.arcstats) =================================== kstat.zfs.misc.arcstats.hits: 102918486 kstat.zfs.misc.arcstats.misses: 1043999 kstat.zfs.misc.arcstats.demand_data_hits: 100522773 kstat.zfs.misc.arcstats.demand_data_misses: 1010728 kstat.zfs.misc.arcstats.demand_metadata_hits: 2395713 kstat.zfs.misc.arcstats.demand_metadata_misses: 33271 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 4689852 kstat.zfs.misc.arcstats.mru_ghost_hits: 11655 kstat.zfs.misc.arcstats.mfu_hits: 98228634 kstat.zfs.misc.arcstats.mfu_ghost_hits: 15088 kstat.zfs.misc.arcstats.deleted: 2596202 kstat.zfs.misc.arcstats.recycle_miss: 6284 kstat.zfs.misc.arcstats.mutex_miss: 1251 kstat.zfs.misc.arcstats.evict_skip: 0 kstat.zfs.misc.arcstats.hash_elements: 16150 kstat.zfs.misc.arcstats.hash_elements_max: 23704 kstat.zfs.misc.arcstats.hash_collisions: 674642 kstat.zfs.misc.arcstats.hash_chains: 1482 kstat.zfs.misc.arcstats.hash_chain_max: 5 kstat.zfs.misc.arcstats.p: 832717343 kstat.zfs.misc.arcstats.c: 834765680 kstat.zfs.misc.arcstats.c_min: 107690560 kstat.zfs.misc.arcstats.c_max: 861524480 kstat.zfs.misc.arcstats.size: 46233760 kstat.zfs.misc.arcstats.hdr_size: 3360032 kstat.zfs.misc.arcstats.l2_hits: 258 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 3337 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 576 kstat.zfs.misc.arcstats.l2_writes_done: 576 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 6 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 2 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 797 kstat.zfs.misc.arcstats.l2_abort_lowmem: 14 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 9151 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 17:14:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEB78106566B for ; Mon, 15 Feb 2010 17:14:12 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id C442E8FC0A for ; Mon, 15 Feb 2010 17:14:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 1502F50830; Mon, 15 Feb 2010 17:14:12 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+tBc2jg34Vv; Mon, 15 Feb 2010 17:14:11 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 913D250823 ; Mon, 15 Feb 2010 17:14:10 +0000 (GMT) Message-ID: <4B7980E0.1020907@langille.org> Date: Mon, 15 Feb 2010 12:14:08 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Naumov References: <4B786D3A.3000408@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 17:14:13 -0000 Dan Naumov wrote: > On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille wrote: >> Dan Naumov wrote: >>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>> After creating three different system configurations (Athena, >>>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>>> setup: >>>>> >>>>> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>> 2. SuperMicro 5046A $750 (+$43 shipping) >>>>> 3. LSI SAS 3081E-R $235 >>>>> 4. SATA cables $60 >>>>> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>>>> 6. Xeon W3520 $310 >>> You do realise how much of a massive overkill this is and how much you >>> are overspending? >> >> I appreciate the comments and feedback. I'd also appreciate alternative >> suggestions in addition to what you have contributed so far. Spec out the >> box you would build. > > ====================== > Case: Fractal Design Define R2 - 89 euro: > http://www.fractal-design.com/?view=product&prod=32 > > Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > > PSU: Corsair 400CX 80+ - 59 euro: > http://www.corsair.com/products/cx/default.aspx > > RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro > ====================== > Total: ~435 euro > > The motherboard has 6 native AHCI-capable ports on ICH9R controller > and you have a PCI-E slot free if you want to add an additional > controller card. Feel free to blow the money you've saved on crazy > fast SATA disks and if your system workload is going to have a lot of > random reads, then spend 200 euro on a 80gb Intel X25-M for use as a > dedicated L2ARC device for your pool. Based on the Fractal Design case mentioned above, I was told about Lian Lia cases, which I think are great. As a result, I've gone with a tower case without hot-swap. The parts are listed at and reproduced below: http://dan.langille.org/2010/02/15/a-full-tower-case/ 1. LIAN LI PC-A71F Black Aluminum ATX Full Tower Computer Case $240 (from mwave) 2. Antec EarthWatts EA650 650W PSU $80 3. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) 4. Intel S3200SHV LGA 775 Intel 3200 m/b $200 5. Intel Core2 Quad Q9400 CPU $190 6. SATA cables $22 7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 8. Kingston ValueRAM 4GB (2 x 2GB) 240-Pin DDR2 SDRAM ECC $97 Total cost is about $1020 with shipping. Plus HDD. No purchases yet, but the above is what appeals to me now. Thank you. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 17:19:03 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C78E1065670; Mon, 15 Feb 2010 17:19:03 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id 17E148FC1B; Mon, 15 Feb 2010 17:19:02 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 7072C1CD4E; Mon, 15 Feb 2010 18:19:01 +0100 (CET) Date: Mon, 15 Feb 2010 18:19:01 +0100 From: Erwin Lansing To: ports@FreeBSD.org, stable@FreeBSD.org Message-ID: <20100215171858.GB13685@droso.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c1qHkdEbEbCG94PZ" Content-Disposition: inline X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: re@FreeBSD.org, portmgr@FreeBSD.org Subject: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 17:19:03 -0000 --c1qHkdEbEbCG94PZ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. Normal upgrade, new ports, and changes that only affect other branches are allowed without prior approval but with the extra Feature safe: yes tag in the commit message. Any commit that is sweeping, i.e. touches a large number of ports, infrastructural changes, commts to ports with unusually high number of dependent ports, and any other commit that requires the rebuilding of many packages is not allowed without prior explicit approval from portmgr after that date. When in doubt, please do not hesitate to contact portmgr. -erwin --=20 Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org --c1qHkdEbEbCG94PZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFLeYICefbgcXQUYpwRAq7YAJoDhOnnv6guMHZtTqPYjPZWJi8w2gCdFTBP EPBpgLnEU3aKO6qEozmkk1Y= =Ghas -----END PGP SIGNATURE----- --c1qHkdEbEbCG94PZ-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 17:52:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0FE01065694 for ; Mon, 15 Feb 2010 17:52:17 +0000 (UTC) (envelope-from jon@witchspace.com) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.freebsd.org (Postfix) with ESMTP id 19B7A8FC14 for ; Mon, 15 Feb 2010 17:52:16 +0000 (UTC) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100215175211.JCOX10950.mtaout03-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Mon, 15 Feb 2010 17:52:11 +0000 Received: from witchspace.com ([86.28.98.4]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with SMTP id <20100215175211.BYGU2093.aamtaout03-winn.ispmail.ntl.com@witchspace.com> for ; Mon, 15 Feb 2010 17:52:11 +0000 Received: (qmail 3107 invoked from network); 15 Feb 2010 16:51:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (192.168.0.1) by 192.168.0.100 with SMTP; 15 Feb 2010 16:51:30 -0000 Message-ID: <4B7989AE.1050203@witchspace.com> Date: Mon, 15 Feb 2010 17:51:42 +0000 From: Jonathan Belson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=ZtHxNT4mZm3rCuM0SmWmgWxeBwJsziC8EqOrwwVkrhA= c=1 sm=0 a=vReAG17O2aoGzJlzF_gA:9 a=76Uednzbgf3FhY5xRNYA:7 a=1xavW79Q4bOIrv8VOWIJ4ppVZeoA:4 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 17:52:18 -0000 On 14/02/2010 17:28, Jonathan Belson wrote: > After reading some earlier threads about zfs performance, I decided to test my own server. I found the results rather surprising... Thanks to everyone who responded. I experimented with my load.conf settings, leaving me with the following: vm.kmem_size="1280M" vfs.zfs.prefetch_disable="1" That kmem_size seems quite big for a machine with only (!) 2GB of RAM, but I wanted to see if it gave better results than 1024MB (it did, an extra ~5MB/s). The rest of the settings are defaults: vm.kmem_size_scale: 3 vm.kmem_size_max: 329853485875 vm.kmem_size_min: 0 vm.kmem_size: 1342177280 vfs.zfs.arc_min: 104857600 vfs.zfs.arc_max: 838860800 My numbers are a lot better with these settings: # dd if=/dev/zero of=/tank/test/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 63.372441 secs (33092492 bytes/sec) # dd if=/dev/zero of=/tank/test/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 60.647568 secs (34579326 bytes/sec) # dd if=/dev/zero of=/tank/test/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 68.241539 secs (30731312 bytes/sec) # dd if=/dev/zero of=/tank/test/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 68.722902 secs (30516057 bytes/sec) Writing a 200MB file to a UFS partition gives around 37MB/s, so the zfs overhead is costing me a few MB per second. I'm guessing that the hard drives themselves have rather sucky performance (I used to use Spinpoints, but receiving three faulty ones in a row put me off them). Reading from a raw device: # dd if=/dev/ad4s1a of=/dev/null bs=1M count=2000 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 11.286550 secs (95134635 bytes/sec) # dd if=/dev/ad4s1a of=/dev/null bs=1M count=2000 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 11.445131 secs (93816473 bytes/sec) # dd if=/dev/ad4s1a of=/dev/null bs=1M count=2000 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 11.284961 secs (95148032 bytes/sec) Reading from zfs file: # dd if=/tank/test/zerofile.000 of=/dev/null bs=1M count=4000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 25.643737 secs (81780281 bytes/sec) # dd if=/tank/test/zerofile.000 of=/dev/null bs=1M count=4000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 25.444214 secs (82421567 bytes/sec) # dd if=/tank/test/zerofile.000 of=/dev/null bs=1M count=4000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 25.572888 secs (82006851 bytes/sec) So, the value of arc_max from the zfs tuning wiki seemed to be the main brake on performance. Cheers, --Jon From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 18:00:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74130106566C for ; Mon, 15 Feb 2010 18:00:23 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7E88FC19 for ; Mon, 15 Feb 2010 18:00:22 +0000 (UTC) Received: from lock.simons-rock.edu (lock.simons-rock.edu [192.168.2.211]) by hedwig.simons-rock.edu (Postfix) with ESMTP id 5E0A72BB360; Mon, 15 Feb 2010 13:00:22 -0500 (EST) Received: from lock.simons-rock.edu (lock.simons-rock.edu [127.0.0.1]) by lock.simons-rock.edu (8.13.1/8.13.1) with ESMTP id o1FI0M9J000588; Mon, 15 Feb 2010 13:00:22 -0500 Received: (from apache@localhost) by lock.simons-rock.edu (8.13.1/8.13.1/Submit) id o1FI0KbQ000587; Mon, 15 Feb 2010 13:00:20 -0500 X-Authentication-Warning: lock.simons-rock.edu: apache set sender to peter@simons-rock.edu using -f Received: from 69.37.94.221 (SquirrelMail authenticated user peter) by lock.simons-rock.edu with HTTP; Mon, 15 Feb 2010 13:00:20 -0500 (EST) Message-ID: <1140.69.37.94.221.1266256820.squirrel@lock.simons-rock.edu> In-Reply-To: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> Date: Mon, 15 Feb 2010 13:00:20 -0500 (EST) From: "Peter C. Lai" To: "Artem Belevich" User-Agent: SquirrelMail/1.4.8-5.el4_8.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Alexander Leidinger , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:00:23 -0000 >>> * vm.kmem_size >>> * vm.kmem_size_max >> >> I tried kmem_size_max on -current (this year), and I got a panic during >> use, >> I changed kmem_size to the same value I have for _max and it didn't >> panic >> anymore. It looks (from mails on the lists) that _max is supposed to >> give a >> max value for auto-enhancement, but at least it was not working with ZFS >> last month (and I doubt it works now). > > It used to be that vm.kmem_size_max needed to be bumped to allow for > larger vm.kmem_size. It's no longer needed on amd64. Not sure about > i386. > > vm.kmem_size still needs tuning, though. While vm.kmem_size_max is no > longer a limit, there are other checks in place that result in default > vm.kmem_size being a bit on the conservative side for ZFS. > >>> Then, when it comes to debugging problems as a result of tuning >>> improperly (or entire lack of), the following counters (not tunables) >>> are thrown into the mix as "things people should look at": >>> >>>  kstat.zfs.misc.arcstats.c >>>  kstat.zfs.misc.arcstats.c_min >>>  kstat.zfs.misc.arcstats.c_max >> >> c_max is vfs.zfs.arc_max, c_min is vfs.zfs.arc_min. >> >>>  kstat.zfs.misc.arcstats.evict_skip >>>  kstat.zfs.misc.arcstats.memory_throttle_count >>>  kstat.zfs.misc.arcstats.size >> >> I'm not very sure about size and c... both represent some kind of >> current >> size, but they are not the same. > > arcstats.c -- adaptive ARC target size. I.e. that's what ZFS thinks it > can grow ARC to. It's dynamically adjusted based on when/how ZFS is > back-pressured for memory. > arcstats.size -- current ARC size > arcstats.p -- portion of arcstats.c that's used by "Most Recently > Used" items. What's left of arcstats.c is used by "Most Frequently > Used" items. > > --Artem > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > How much ram are you running with? In a latest test with 8.0-R on i386 with 2GB of ram, an install to a ZFS root *will* panic the kernel with kmem_size too small with default settings. Even dropping down to Cy Schubert's uber-small config will panic the kernel (vm.kmem_size_max = 330M, vfs.zfs.arc_size = 40M, vfs.zfs.vdev.cache_size = 5M); the system is currently stable using DIST kernel, vm.kmem_size/max = 512M, arc_size = 40M and vdev.cache_size = 5M. -- Peter C. Lai ITS Systems Administrator Bard College at Simon's Rock 84 Alford Rd. Great Barrington, MA 01230 (413) 528-7428 peter at simons-rock.edu From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 18:03:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE94106568D for ; Mon, 15 Feb 2010 18:03:41 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id C8D3F8FC26 for ; Mon, 15 Feb 2010 18:03:40 +0000 (UTC) Received: by iwn5 with SMTP id 5so1997598iwn.9 for ; Mon, 15 Feb 2010 10:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=NjadGosjeWzMzvByncnbZBevOTP8F22ZaZNjpwRiObE=; b=al8GbBvM1hX6uLAFvVdPyPRnkTf1ZcyJGAlXg5glhb1eVQguTT5VOBMCNVYo7aWBSF 9wm7KaRdxjtDUi6T5AlF2iwmdbpjf2QuAmhr70M2481YH1VOC6RstPjXGD/3ALtMCBCA 18rbfW786tfTxigOr27b+XMuftxFlkMYUyn6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=p+PARGMetKfdFc96OjdO3R0hoJHXji4HNvG+1PEsDU6sEVMXQDv2ii9L8bEyhIJIlf 9ZKRRQ6JWPUcwlvUQxWOjiL6lrt5q+EdmVYLhFHiVshdQ7Sb6v/tyQOhohxAyWUg34xQ nqZ5GVsBBl6b9rsZULrjdgis50xZQij5Oqr1E= MIME-Version: 1.0 Received: by 10.231.159.207 with SMTP id k15mr4402832ibx.52.1266257020207; Mon, 15 Feb 2010 10:03:40 -0800 (PST) In-Reply-To: <4B7989AE.1050203@witchspace.com> References: <4B7989AE.1050203@witchspace.com> Date: Mon, 15 Feb 2010 10:03:40 -0800 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:03:41 -0000 On Mon, Feb 15, 2010 at 9:51 AM, Jonathan Belson wrote: > On 14/02/2010 17:28, Jonathan Belson wrote: > >> After reading some earlier threads about zfs performance, I decided to >> test my own server. I found the results rather surprising... >> > > Thanks to everyone who responded. I experimented with my load.conf > settings, leaving me with the following: > > vm.kmem_size="1280M" > vfs.zfs.prefetch_disable="1" > > That kmem_size seems quite big for a machine with only (!) 2GB of RAM, but > I wanted to see if it gave better results than 1024MB (it did, an extra > ~5MB/s). > For a system with 2 GB of RAM, and possibly slow harddrives, consider adding a "cache" vdev (L2ARC). The 4 GB and larger USB flash drives are getting to be pretty fast for reads (which is what the L2ARC is for). On my home system, which is a 32-bit FreeBSD 8-STABLE box with a 3.0 GHz P4 and 2 GB of RAM, adding a 4 GB Transcend JetFlash has done wonders for improving stability and read speed. Most of my apps now load from the USB stick instead of the slow raidz1 vdev (3x 120 GB SATA drives). Haven't done any real benchmarks yet (still upgrading to KDE 4.4), but things feel smoother, and it hasn't locked up since adding the USB stick. On this box, running ktorrent 24/7 used to lock up the box after 3-5 days (can't even toggle numlock). This box uses a kmem_max of 1 GB, and an arc_max of 512 MB. With a 4 GB L2ARC. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 18:07:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77AF8106566C; Mon, 15 Feb 2010 18:07:55 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0A9A08FC21; Mon, 15 Feb 2010 18:07:54 +0000 (UTC) Received: by gxk10 with SMTP id 10so4197598gxk.3 for ; Mon, 15 Feb 2010 10:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NGYzNaasNYljdlL3wgw7cL1c/RKQDfP5pILOr2jbuOc=; b=rRrmZEeYDsaqFbdMxRDGsi5ZEsnoGMP3kQplajTXfDtClfukuAZILbLov627vYCs6s cjK34rufBD5LW4SbaBHk/zN7/0ZmIi2oYDn+2Gms1Jwkmw324IV8RiMx4cHsZLLcSNrJ 1Oaw96NghLzMM4B1wtbOJO93A5liakxcQiy5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nOvjWnn5Z7dBl7nP3D3Sk1lWVj3fp7rdvrHYBT8pWInicaAwEp5NAHF4py36PmI+Jf Z1H15W97RMCv+ltmriCOEXfWK2tLA1th6IFWqkHkZ2lQqXAxwFXaSwDYOkN3bgYN/mCT uGAkh1oW9mv1a1OAV5HhfzsZHaSogZgvL8XrA= MIME-Version: 1.0 Received: by 10.150.67.13 with SMTP id p13mr6644871yba.15.1266257274199; Mon, 15 Feb 2010 10:07:54 -0800 (PST) In-Reply-To: References: Date: Mon, 15 Feb 2010 10:07:54 -0800 Message-ID: From: Matt Reimer To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:07:55 -0000 On Sat, Feb 13, 2010 at 12:04 PM, Dan Naumov wrote: > Hello > > I have succesfully tested and used a "full ZFS install" of FreeBSD 8.0 > on both single disk and mirror disk configurations using both MBR and > GPT partitioning. AFAIK, with the more recent -CURRENT and -STABLE it > is also possible to boot off a root filesystem located on raidz/raidz2 > pools. But what about booting off pools consisting of multiple striped > mirror or raidz vdevs? Like this: > > Assume each disk looks like a half of a traditional ZFS mirror root > configuration using GPT > > 1: freebsd-boot > 2: freebsd-swap > 3: freebsd-zfs > > |disk1+disk2| + |disk3+disk4| + |disk5+disk6| > > My logic tells me that while booting off any of the 6 disks, boot0 and > boot1 stage should obviously work fine, but what about the boot2 > stage? Can it properly handle booting off a root filesystem thats > striped across 3 mirror vdevs or is booting off a single mirror vdev > the best that one can do right now? > > I don't know, but I plan to test that scenario in a few days. Matt From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 18:12:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC34E1065672 for ; Mon, 15 Feb 2010 18:12:58 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 423FF8FC1B for ; Mon, 15 Feb 2010 18:12:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o1FICusT014243; Mon, 15 Feb 2010 21:12:56 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 15 Feb 2010 21:12:56 +0300 (MSK) From: Dmitry Morozovsky To: Artem Belevich In-Reply-To: Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Mon, 15 Feb 2010 21:12:56 +0300 (MSK) Cc: Alexander Leidinger , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:12:58 -0000 On Mon, 15 Feb 2010, Artem Belevich wrote: AB> It used to be that vm.kmem_size_max needed to be bumped to allow for AB> larger vm.kmem_size. It's no longer needed on amd64. Not sure about AB> i386. AB> AB> vm.kmem_size still needs tuning, though. While vm.kmem_size_max is no AB> longer a limit, there are other checks in place that result in default AB> vm.kmem_size being a bit on the conservative side for ZFS. it seems so at least: on a machine with 8G RAM kmem_size is set to 2G, from which 1.5G is allocated for arc_max. I'll try to increase them to 4G / 3G and test whether machine is stable... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 18:26:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67D76106568D; Mon, 15 Feb 2010 18:25:59 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC9F8FC1C; Mon, 15 Feb 2010 18:25:58 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-37.bna.bellsouth.net [74.241.172.37]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1FIPreD048453 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Feb 2010 13:25:55 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Matt Reimer In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Date: Mon, 15 Feb 2010 12:25:48 -0600 Message-Id: <1266258348.11131.21.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List , Dan Naumov , freebsd-questions@freebsd.org Subject: Re: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:26:00 -0000 On Mon, 2010-02-15 at 10:07 -0800, Matt Reimer wrote: > On Sat, Feb 13, 2010 at 12:04 PM, Dan Naumov wrote: > > > Hello > > > > I have succesfully tested and used a "full ZFS install" of FreeBSD 8.0 > > on both single disk and mirror disk configurations using both MBR and > > GPT partitioning. AFAIK, with the more recent -CURRENT and -STABLE it > > is also possible to boot off a root filesystem located on raidz/raidz2 > > pools. But what about booting off pools consisting of multiple striped > > mirror or raidz vdevs? Like this: > > > > Assume each disk looks like a half of a traditional ZFS mirror root > > configuration using GPT > > > > 1: freebsd-boot > > 2: freebsd-swap > > 3: freebsd-zfs > > > > |disk1+disk2| + |disk3+disk4| + |disk5+disk6| > > > > My logic tells me that while booting off any of the 6 disks, boot0 and > > boot1 stage should obviously work fine, but what about the boot2 > > stage? Can it properly handle booting off a root filesystem thats > > striped across 3 mirror vdevs or is booting off a single mirror vdev > > the best that one can do right now? > > > > > I don't know, but I plan to test that scenario in a few days. It *should* work... I made changes a while back that allow for multiple vdevs to attach to the root. In this case you should have 3 mirror vdevs attached to the root, so as long as the BIOS can enumerate all of the drives, we should find all of the vdevs and build the tree correctly. It should be simple enough to test in qemu, except that the BIOS in qemu is a little broken and might not id all of the drives. robert. > Matt > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 18:28:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8383B106566B for ; Mon, 15 Feb 2010 18:28:45 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id DA4928FC29 for ; Mon, 15 Feb 2010 18:28:44 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 5407819E023; Mon, 15 Feb 2010 19:28:43 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 5044B19E019; Mon, 15 Feb 2010 19:28:40 +0100 (CET) Message-ID: <4B799257.9080304@quip.cz> Date: Mon, 15 Feb 2010 19:28:39 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100215170156.GA64731@icarus.home.lan> In-Reply-To: <20100215170156.GA64731@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: More zfs benchmarks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:28:45 -0000 Jeremy Chadwick wrote: > On Sun, Feb 14, 2010 at 05:28:28PM +0000, Jonathan Belson wrote: >> Hiya >> >> After reading some earlier threads about zfs performance, I decided to test my own server. I found the results rather surprising... > > Below are my results from my home machine. Note that my dd size and > count differ from what the OP provided. > > I should note that powerd(8) is in effect on this box; I probably should > have disabled it and forced the CPU frequency to be at max before doing > these tests. I did the same tests as you on my backup storage server HP ML110 G5 with 4x 1TB Samsung drives in RAIDZ. Unfortunately there is no kstat.zfs.misc.arcstats.memory_throttle_count on FreeBSD 7.2 I can run this test on Sun Fire X2100 with 4GB RAM, 2x 500GB Hitachi drives in ZFS mirror on FreeBSD 7.2 (let me know if somebody is interested in results for comparision) root@kiwi ~/# uname -a FreeBSD kiwi.codelab.cz 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 08:22:32 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 root@kiwi ~/# uptime 6:46PM up 6 days, 7:30, 1 user, load averages: 0.00, 0.00, 0.00 root@kiwi ~/# sysctl hw.machine hw.model hw.ncpu hw.physmem hw.usermem hw.realmem hw.pagesizes hw.machine: amd64 hw.model: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz hw.ncpu: 2 hw.physmem: 5219966976 hw.usermem: 801906688 hw.realmem: 5637144576 sysctl: unknown oid 'hw.pagesizes' root@kiwi ~/# sysctl vm.kmem_size vm.kmem_size_min vm.kmem_size_max vm.kmem_size_scale vm.kmem_size: 1684733952 vm.kmem_size_min: 0 vm.kmem_size_max: 3865468109 vm.kmem_size_scale: 3 root@kiwi ~/# dmesg | egrep '(ata[01]|atapci0)' atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c10-0x1c1f,0x1c00-0x1c0f at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ad0: 953869MB at ata0-master SATA300 ad1: 953869MB at ata0-slave SATA300 ad2: 953869MB at ata1-master SATA300 ad3: 953869MB at ata1-slave SATA300 root@kiwi ~/# egrep '^[a-z]' /boot/loader.conf hw.bge.allow_asf="1" root@kiwi ~/# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad0 ONLINE 0 0 0 ad1 ONLINE 0 0 0 ad2 ONLINE 0 0 0 ad3 ONLINE 0 0 0 errors: No known data errors before tests root@kiwi ~/# sysctl kstat.zfs.misc.arcstats kstat.zfs.misc.arcstats.hits: 350294273 kstat.zfs.misc.arcstats.misses: 8369056 kstat.zfs.misc.arcstats.demand_data_hits: 4336959 kstat.zfs.misc.arcstats.demand_data_misses: 135936 kstat.zfs.misc.arcstats.demand_metadata_hits: 267825050 kstat.zfs.misc.arcstats.demand_metadata_misses: 6177625 kstat.zfs.misc.arcstats.prefetch_data_hits: 138128 kstat.zfs.misc.arcstats.prefetch_data_misses: 400434 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 77994136 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1655061 kstat.zfs.misc.arcstats.mru_hits: 158218094 kstat.zfs.misc.arcstats.mru_ghost_hits: 9777 kstat.zfs.misc.arcstats.mfu_hits: 114654575 kstat.zfs.misc.arcstats.mfu_ghost_hits: 244807 kstat.zfs.misc.arcstats.deleted: 9904481 kstat.zfs.misc.arcstats.recycle_miss: 2855906 kstat.zfs.misc.arcstats.mutex_miss: 9362 kstat.zfs.misc.arcstats.evict_skip: 1483848 kstat.zfs.misc.arcstats.hash_elements: 77770 kstat.zfs.misc.arcstats.hash_elements_max: 553646 kstat.zfs.misc.arcstats.hash_collisions: 8012499 kstat.zfs.misc.arcstats.hash_chains: 15382 kstat.zfs.misc.arcstats.hash_chain_max: 16 kstat.zfs.misc.arcstats.p: 1107222849 kstat.zfs.misc.arcstats.c: 1263550464 kstat.zfs.misc.arcstats.c_min: 52647936 kstat.zfs.misc.arcstats.c_max: 1263550464 kstat.zfs.misc.arcstats.size: 1263430144 test #1 (327,680,000 bytes) [~412MB/s - buffered] ============================= root@kiwi ~/# dd if=/dev/zero of=/tank/test01 bs=64k count=5000 5000+0 records in 5000+0 records out 327680000 bytes transferred in 0.758220 secs (432170107 bytes/sec) test #1 (kstat.zfs.misc.arcstats) =================================== root@kiwi ~/# sysctl kstat.zfs.misc.arcstats kstat.zfs.misc.arcstats.hits: 350294422 kstat.zfs.misc.arcstats.misses: 8369059 kstat.zfs.misc.arcstats.demand_data_hits: 4337042 kstat.zfs.misc.arcstats.demand_data_misses: 135936 kstat.zfs.misc.arcstats.demand_metadata_hits: 267825116 kstat.zfs.misc.arcstats.demand_metadata_misses: 6177628 kstat.zfs.misc.arcstats.prefetch_data_hits: 138128 kstat.zfs.misc.arcstats.prefetch_data_misses: 400434 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 77994136 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1655061 kstat.zfs.misc.arcstats.mru_hits: 158218145 kstat.zfs.misc.arcstats.mru_ghost_hits: 9777 kstat.zfs.misc.arcstats.mfu_hits: 114654673 kstat.zfs.misc.arcstats.mfu_ghost_hits: 244807 kstat.zfs.misc.arcstats.deleted: 9942641 kstat.zfs.misc.arcstats.recycle_miss: 2856395 kstat.zfs.misc.arcstats.mutex_miss: 9362 kstat.zfs.misc.arcstats.evict_skip: 1483848 kstat.zfs.misc.arcstats.hash_elements: 42137 kstat.zfs.misc.arcstats.hash_elements_max: 553646 kstat.zfs.misc.arcstats.hash_collisions: 8013282 kstat.zfs.misc.arcstats.hash_chains: 5506 kstat.zfs.misc.arcstats.hash_chain_max: 16 kstat.zfs.misc.arcstats.p: 1042257654 kstat.zfs.misc.arcstats.c: 1185812496 kstat.zfs.misc.arcstats.c_min: 52647936 kstat.zfs.misc.arcstats.c_max: 1263550464 kstat.zfs.misc.arcstats.size: 1185738752 test #2 (3,276,800,000 bytes) [~126MB/s] =============================== root@kiwi ~/# dd if=/dev/zero of=/tank/test02 bs=64k count=50000 50000+0 records in 50000+0 records out 3276800000 bytes transferred in 24.713113 secs (132593575 bytes/sec) test #2 (kstat.zfs.misc.arcstats) =================================== root@kiwi ~/# sysctl kstat.zfs.misc.arcstats kstat.zfs.misc.arcstats.hits: 350294793 kstat.zfs.misc.arcstats.misses: 8369070 kstat.zfs.misc.arcstats.demand_data_hits: 4337253 kstat.zfs.misc.arcstats.demand_data_misses: 135940 kstat.zfs.misc.arcstats.demand_metadata_hits: 267825276 kstat.zfs.misc.arcstats.demand_metadata_misses: 6177635 kstat.zfs.misc.arcstats.prefetch_data_hits: 138128 kstat.zfs.misc.arcstats.prefetch_data_misses: 400434 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 77994136 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1655061 kstat.zfs.misc.arcstats.mru_hits: 158218309 kstat.zfs.misc.arcstats.mru_ghost_hits: 9777 kstat.zfs.misc.arcstats.mfu_hits: 114654880 kstat.zfs.misc.arcstats.mfu_ghost_hits: 244807 kstat.zfs.misc.arcstats.deleted: 9982199 kstat.zfs.misc.arcstats.recycle_miss: 2857105 kstat.zfs.misc.arcstats.mutex_miss: 9375 kstat.zfs.misc.arcstats.evict_skip: 1483848 kstat.zfs.misc.arcstats.hash_elements: 27799 kstat.zfs.misc.arcstats.hash_elements_max: 553646 kstat.zfs.misc.arcstats.hash_collisions: 8018034 kstat.zfs.misc.arcstats.hash_chains: 2604 kstat.zfs.misc.arcstats.hash_chain_max: 16 kstat.zfs.misc.arcstats.p: 993103671 kstat.zfs.misc.arcstats.c: 1112857236 kstat.zfs.misc.arcstats.c_min: 52647936 kstat.zfs.misc.arcstats.c_max: 1263550464 kstat.zfs.misc.arcstats.size: 1112830464 test #3 (6,553,600,000 bytes) [~115MB/s] =============================== root@kiwi ~/# dd if=/dev/zero of=/tank/test03 bs=64k count=100000 100000+0 records in 100000+0 records out 6553600000 bytes transferred in 54.284611 secs (120726664 bytes/sec) root@kiwi ~/# iostat -x -w 5 ad{0,1,2,3} extended device statistics device r/s w/s kr/s kw/s wait svc_t %b ad0 0.0 948.3 0.0 39875.9 60 43.2 70 ad1 0.0 948.3 0.0 39863.3 58 43.2 70 ad2 0.0 936.1 0.0 39801.2 60 44.4 69 ad3 0.0 935.3 0.0 39799.2 67 49.3 70 extended device statistics device r/s w/s kr/s kw/s wait svc_t %b ad0 0.0 974.0 0.0 41074.1 0 45.5 71 ad1 0.0 974.3 0.0 41074.1 0 45.5 71 ad2 0.0 964.1 0.0 40861.7 50 40.9 71 ad3 0.0 962.5 0.0 40836.3 42 47.6 71 extended device statistics device r/s w/s kr/s kw/s wait svc_t %b ad0 0.0 1024.0 0.0 43083.7 64 41.9 75 ad1 0.0 1024.0 0.0 43079.5 63 42.0 75 ad2 0.0 1021.4 0.0 43140.5 64 42.1 75 ad3 0.0 1022.4 0.0 43112.4 68 47.6 75 test #3 (kstat.zfs.misc.arcstats) =================================== root@kiwi ~/# sysctl kstat.zfs.misc.arcstats kstat.zfs.misc.arcstats.hits: 350318200 kstat.zfs.misc.arcstats.misses: 8369077 kstat.zfs.misc.arcstats.demand_data_hits: 4353290 kstat.zfs.misc.arcstats.demand_data_misses: 135943 kstat.zfs.misc.arcstats.demand_metadata_hits: 267825457 kstat.zfs.misc.arcstats.demand_metadata_misses: 6177639 kstat.zfs.misc.arcstats.prefetch_data_hits: 145317 kstat.zfs.misc.arcstats.prefetch_data_misses: 400434 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 77994136 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1655061 kstat.zfs.misc.arcstats.mru_hits: 158234399 kstat.zfs.misc.arcstats.mru_ghost_hits: 9777 kstat.zfs.misc.arcstats.mfu_hits: 114655008 kstat.zfs.misc.arcstats.mfu_ghost_hits: 244807 kstat.zfs.misc.arcstats.deleted: 10034672 kstat.zfs.misc.arcstats.recycle_miss: 2857257 kstat.zfs.misc.arcstats.mutex_miss: 9375 kstat.zfs.misc.arcstats.evict_skip: 1483848 kstat.zfs.misc.arcstats.hash_elements: 25839 kstat.zfs.misc.arcstats.hash_elements_max: 553646 kstat.zfs.misc.arcstats.hash_collisions: 8026271 kstat.zfs.misc.arcstats.hash_chains: 2265 kstat.zfs.misc.arcstats.hash_chain_max: 16 kstat.zfs.misc.arcstats.p: 978217976 kstat.zfs.misc.arcstats.c: 1078080448 kstat.zfs.misc.arcstats.c_min: 52647936 kstat.zfs.misc.arcstats.c_max: 1263550464 kstat.zfs.misc.arcstats.size: 1077974016 test #4 (9,830,400,000 bytes) [~111MB/s] =============================== root@kiwi ~/# dd if=/dev/zero of=/tank/test04 bs=64k count=150000 150000+0 records in 150000+0 records out 9830400000 bytes transferred in 84.240802 secs (116694046 bytes/sec) test #4 (kstat.zfs.misc.arcstats) root@kiwi ~/# sysctl kstat.zfs.misc.arcstats kstat.zfs.misc.arcstats.hits: 350339957 kstat.zfs.misc.arcstats.misses: 8369627 kstat.zfs.misc.arcstats.demand_data_hits: 4368343 kstat.zfs.misc.arcstats.demand_data_misses: 135948 kstat.zfs.misc.arcstats.demand_metadata_hits: 267827004 kstat.zfs.misc.arcstats.demand_metadata_misses: 6177699 kstat.zfs.misc.arcstats.prefetch_data_hits: 150148 kstat.zfs.misc.arcstats.prefetch_data_misses: 400434 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 77994462 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1655546 kstat.zfs.misc.arcstats.mru_hits: 158249785 kstat.zfs.misc.arcstats.mru_ghost_hits: 9777 kstat.zfs.misc.arcstats.mfu_hits: 114656222 kstat.zfs.misc.arcstats.mfu_ghost_hits: 244808 kstat.zfs.misc.arcstats.deleted: 10114638 kstat.zfs.misc.arcstats.recycle_miss: 2857637 kstat.zfs.misc.arcstats.mutex_miss: 9384 kstat.zfs.misc.arcstats.evict_skip: 1483848 kstat.zfs.misc.arcstats.hash_elements: 22056 kstat.zfs.misc.arcstats.hash_elements_max: 553646 kstat.zfs.misc.arcstats.hash_collisions: 8038056 kstat.zfs.misc.arcstats.hash_chains: 1631 kstat.zfs.misc.arcstats.hash_chain_max: 16 kstat.zfs.misc.arcstats.p: 1009315376 kstat.zfs.misc.arcstats.c: 1078080448 kstat.zfs.misc.arcstats.c_min: 52647936 kstat.zfs.misc.arcstats.c_max: 1263550464 kstat.zfs.misc.arcstats.size: 1078049280 root@kiwi ~/# ~/bin/arc_summary.pl System Memory: Physical RAM: 4978 MB Free Memory : 0 MB ARC Size: Current Size: 1028 MB (arcsize) Target Size (Adaptive): 1028 MB (c) Min Size (Hard Limit): 50 MB (zfs_arc_min) Max Size (Hard Limit): 1205 MB (zfs_arc_max) ARC Size Breakdown: Most Recently Used Cache Size: 93% 962 MB (p) Most Frequently Used Cache Size: 6% 65 MB (c-p) ARC Efficency: Cache Access Total: 358711136 Cache Hit Ratio: 97% 350341492 [Defined State for buffer] Cache Miss Ratio: 2% 8369644 [Undefined State for Buffer] REAL Hit Ratio: 76% 272907542 [MRU/MFU Hits Only] Data Demand Efficiency: 96% Data Prefetch Efficiency: 27% CACHE HITS BY CACHE LIST: Anon: 22% 77179357 [ New Customer, First Cache Hit ] Most Recently Used: 45% 158250219 (mru) [ Return Customer ] Most Frequently Used: 32% 114657323 (mfu) [ Frequent Customer ] Most Recently Used Ghost: 0% 9777 (mru_ghost) [ Return Customer Evicted, Now Back ] Most Frequently Used Ghost: 0% 244816 (mfu_ghost) [ Frequent Customer Evicted, Now Back ] CACHE HITS BY DATA TYPE: Demand Data: 1% 4369362 Prefetch Data: 0% 150148 Demand Metadata: 76% 267827520 Prefetch Metadata: 22% 77994462 CACHE MISSES BY DATA TYPE: Demand Data: 1% 135954 Prefetch Data: 4% 400434 Demand Metadata: 73% 6177710 Prefetch Metadata: 19% 1655546 --------------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 20:33:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 388871065679 for ; Mon, 15 Feb 2010 20:33:48 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 8AAD98FC17 for ; Mon, 15 Feb 2010 20:33:47 +0000 (UTC) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 15 Feb 2010 20:33:30 +0000 (GMT) Date: Mon, 15 Feb 2010 20:33:27 +0000 From: David Malone To: Jeremy Chadwick Message-ID: <20100215203327.GA28078@walton.maths.tcd.ie> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100212194604.GA73961@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100212194604.GA73961@icarus.home.lan> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 20:33:48 -0000 On Fri, Feb 12, 2010 at 11:46:04AM -0800, Jeremy Chadwick wrote: > Technical footnote: I wish I understood 1) the difference between > ACPI-safe and ACPI-fast, and 2) how the system or OS "ranks" the > timecounters (the higher the value in parenthesis, supposedly the more > accurate/preferred it is). Xin, do you happen to know how this works? 1) When you read the ACPI timing register, you should get a sensible answer. However on some (most?) hardware, you can read the register and get it half way through an update. When the kernel finds the ACPI timer, it tries reading it a few times in a row, and checks the results look good - if they do, you get ACPI-fast. If it catches a half-updated register, then you get ACPI-slow, which reads the register multiple times in an effort to avoid the problem. 2) The ranking of timers is essentially hard wired, though for some times it is adjusted in some way. For example, the ranking of the TSC may be reduced if it looks like an SMP system. I believe the ranking was originally intended to be a measure of how fast the counter could be read, but things have turned out to be complicated by difficult hardware. David. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 20:39:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C19B3106566B for ; Mon, 15 Feb 2010 20:39:29 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C2498FC0A for ; Mon, 15 Feb 2010 20:39:29 +0000 (UTC) Received: by ywh12 with SMTP id 12so2467982ywh.7 for ; Mon, 15 Feb 2010 12:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bEYKtIEONDU5owm3I/pJNXbx9PRHRr/Tb9ByufcNiN0=; b=ES2lDfiUSEYUxzDWGzIQyy9mVaqcX43dFz2Z0nv+UW/LSFWjIpIM61J7jWNXgwgXGc 5uhgU99TMKQy559fxbwe8FR20740knxwTGh/5Uuff+YRcoMwWZWZiT67hkKipeFnwYt2 X806cd8c6BIPabeO1ewj5DuiOX9meM7pFb5RQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=K1JYmsazdDep5Ww/pCmDItSLWX6B7JRshFb4b1urLsh/92iQCR9kV8aB/WYGpN3tRA myzVKKnyAE2L1PIs0GDO6VDCd5ep8MwYjr8J5IwqU07yDzl2ZEab1DGMGW3CkXY7ef5x TNjn/SGWC6C3Y2hVKu9pBN2W/9n1RIz7h8y30= MIME-Version: 1.0 Received: by 10.150.251.16 with SMTP id y16mr10812586ybh.188.1266266368372; Mon, 15 Feb 2010 12:39:28 -0800 (PST) In-Reply-To: <4B7980E0.1020907@langille.org> References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> Date: Mon, 15 Feb 2010 22:39:28 +0200 Message-ID: From: Dan Naumov To: Dan Langille , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 20:39:29 -0000 On Mon, Feb 15, 2010 at 7:14 PM, Dan Langille wrote: > Dan Naumov wrote: >> >> On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille wrote: >>> >>> Dan Naumov wrote: >>>>> >>>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>>> >>>>>> After creating three different system configurations (Athena, >>>>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>>>> setup: >>>>>> >>>>>> =A0 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>>> =A0 2. SuperMicro 5046A $750 (+$43 shipping) >>>>>> =A0 3. LSI SAS 3081E-R $235 >>>>>> =A0 4. SATA cables $60 >>>>>> =A0 5. Crucial 3=D72G ECC DDR3-1333 $191 (+ $6 shipping) >>>>>> =A0 6. Xeon W3520 $310 >>>> >>>> You do realise how much of a massive overkill this is and how much you >>>> are overspending? >>> >>> I appreciate the comments and feedback. =A0I'd also appreciate alternat= ive >>> suggestions in addition to what you have contributed so far. =A0Spec ou= t >>> the >>> box you would build. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Case: Fractal Design Define R2 - 89 euro: >> http://www.fractal-design.com/?view=3Dproduct&prod=3D32 >> >> Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ= =3DH >> >> PSU: Corsair 400CX 80+ - 59 euro: >> http://www.corsair.com/products/cx/default.aspx >> >> RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Total: ~435 euro >> >> The motherboard has 6 native AHCI-capable ports on ICH9R controller >> and you have a PCI-E slot free if you want to add an additional >> controller card. Feel free to blow the money you've saved on crazy >> fast SATA disks and if your system workload is going to have a lot of >> random reads, then spend 200 euro on a 80gb Intel X25-M for use as a >> dedicated L2ARC device for your pool. > > Based on the Fractal Design case mentioned above, I was told about Lian L= ia > cases, which I think are great. =A0As a result, I've gone with a tower = =A0case > without hot-swap. =A0The parts are listed at and reproduced below: > > =A0http://dan.langille.org/2010/02/15/a-full-tower-case/ > > =A0 1. LIAN LI PC-A71F Black Aluminum ATX Full Tower Computer Case $240 (= from > mwave) > =A0 2. Antec EarthWatts EA650 650W PSU $80 > =A0 3. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) > =A0 4. Intel S3200SHV LGA 775 Intel 3200 m/b $200 > =A0 5. Intel Core2 Quad Q9400 CPU $190 > =A0 6. SATA cables $22 > =A0 7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 > =A0 8. Kingston ValueRAM 4GB (2 x 2GB) 240-Pin DDR2 SDRAM ECC $97 > > Total cost is about $1020 with shipping. =A0Plus HDD. > > No purchases yet, but the above is what appeals to me now. A C2Q CPU makes little sense right now from a performance POV. For the price of that C2Q CPU + LGA775 board you can get an i5 750 CPU and a 1156 socket motherboard that will run circles around that C2Q. You would lose the ECC though, since that requires the more expensive 1366 socket CPUs and boards. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 20:57:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36B1B106566B for ; Mon, 15 Feb 2010 20:57:54 +0000 (UTC) (envelope-from andrej@antiszoc.hu) Received: from mail.deployis.eu (mail.deployis.eu [217.20.135.253]) by mx1.freebsd.org (Postfix) with ESMTP id 83D0D8FC08 for ; Mon, 15 Feb 2010 20:57:53 +0000 (UTC) Received: from localhost ([127.0.0.1]:45774 helo=mail.deployis.eu) by mail.deployis.eu with esmtp (Exim 4.69 #1 (Debian)) id 1Nh80s-0007BB-W9 from ; Mon, 15 Feb 2010 21:57:51 +0100 Received: from 188.157.184.107 (SquirrelMail authenticated user andrej@antiszoc.hu) by mail.deployis.eu with HTTP; Mon, 15 Feb 2010 21:57:50 +0100 (CET) Message-ID: <33955.188.157.184.107.1266267470.squirrel@mail.deployis.eu> In-Reply-To: References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> Date: Mon, 15 Feb 2010 21:57:50 +0100 (CET) From: =?iso-8859-2?Q?G=F3t_Andr=E1s?= To: "Dan Naumov" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Spam-Score-deployiseu: -30 Cc: FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 20:57:54 -0000 On Hét, Február 15, 2010 9:39 pm, Dan Naumov wrote: > On Mon, Feb 15, 2010 at 7:14 PM, Dan Langille wrote: > >> Dan Naumov wrote: >> >>> >>> On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille >>> wrote: >>> >>>> >>>> Dan Naumov wrote: >>>> >>>>>> >>>>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>>> >>>>>>> >>>>>>> After creating three different system configurations (Athena, >>>>>>> Supermicro, and HP), my configuration of choice is this >>>>>>> Supermicro >>>>>>> setup: >>>>>>> >>>>>>> >>>>>>>   1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>>>>   2. SuperMicro 5046A $750 (+$43 shipping) >>>>>>>   3. LSI SAS 3081E-R $235 >>>>>>>   4. SATA cables $60 >>>>>>>   5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>>>>>>   6. Xeon W3520 $310 >>>>>>> >>>>> >>>>> You do realise how much of a massive overkill this is and how >>>>> much you are overspending? >>>> >>>> I appreciate the comments and feedback.  I'd also appreciate >>>> alternative suggestions in addition to what you have contributed so >>>> far.  Spec out the box you would build. >>> >>> ====================== >>> Case: Fractal Design Define R2 - 89 euro: >>> http://www.fractal-design.com/?view=product&prod=32 >>> >>> >>> Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: >>> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ >>> =H >>> >>> >>> PSU: Corsair 400CX 80+ - 59 euro: >>> http://www.corsair.com/products/cx/default.aspx >>> >>> >>> RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro >>> ====================== >>> Total: ~435 euro >>> >>> >>> The motherboard has 6 native AHCI-capable ports on ICH9R controller >>> and you have a PCI-E slot free if you want to add an additional >>> controller card. Feel free to blow the money you've saved on crazy >>> fast SATA disks and if your system workload is going to have a lot of >>> random reads, then spend 200 euro on a 80gb Intel X25-M for use as a >>> dedicated L2ARC device for your pool. >> >> Based on the Fractal Design case mentioned above, I was told about Lian >> Lia >> cases, which I think are great.  As a result, I've gone with a tower >>  case >> without hot-swap.  The parts are listed at and reproduced below: >> >>  http://dan.langille.org/2010/02/15/a-full-tower-case/ >> >> >>   1. LIAN LI PC-A71F Black Aluminum ATX Full Tower Computer Case $240 >> (from >> mwave)   2. Antec EarthWatts EA650 650W PSU $80 >>   3. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>   4. Intel S3200SHV LGA 775 Intel 3200 m/b $200 >>   5. Intel Core2 Quad Q9400 CPU $190 >>   6. SATA cables $22 >>   7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 >>   8. Kingston ValueRAM 4GB (2 x 2GB) 240-Pin DDR2 SDRAM ECC $97 >> >> >> Total cost is about $1020 with shipping.  Plus HDD. >> >> >> No purchases yet, but the above is what appeals to me now. >> > > A C2Q CPU makes little sense right now from a performance POV. For the > price of that C2Q CPU + LGA775 board you can get an i5 750 CPU and a 1156 > socket motherboard that will run circles around that C2Q. You would lose > the ECC though, since that requires the more expensive 1366 socket CPUs > and boards. > > - Sincerely, > Dan Naumov Hi, Do have test about this? I'm not really impressed with the i5 series. Regards, Andras From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 21:04:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAF3C1065676 for ; Mon, 15 Feb 2010 21:04:29 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 73C168FC16 for ; Mon, 15 Feb 2010 21:04:29 +0000 (UTC) Received: from reflector.ws.pitbpa0.priv.collaborativefusion.com ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 15 Feb 2010 16:25:39 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::438 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@freebsd.org X-SMFBL: ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= Message-ID: <4B79B6BB.1060809@comcast.net> Date: Mon, 15 Feb 2010 16:03:55 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100211 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dan Langille References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> In-Reply-To: <4B7980E0.1020907@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List , Dan Naumov Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:04:29 -0000 On 02/15/10 12:14, Dan Langille wrote: > Dan Naumov wrote: >> On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille wrote: >>> Dan Naumov wrote: >>>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>>> After creating three different system configurations (Athena, >>>>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>>>> setup: >>>>>> >>>>>> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>>> 2. SuperMicro 5046A $750 (+$43 shipping) >>>>>> 3. LSI SAS 3081E-R $235 >>>>>> 4. SATA cables $60 >>>>>> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>>>>> 6. Xeon W3520 $310 >>>> You do realise how much of a massive overkill this is and how much you >>>> are overspending? >>> >>> I appreciate the comments and feedback. I'd also appreciate >>> alternative >>> suggestions in addition to what you have contributed so far. Spec >>> out the >>> box you would build. >> >> ====================== >> Case: Fractal Design Define R2 - 89 euro: >> http://www.fractal-design.com/?view=product&prod=32 >> >> Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >> >> PSU: Corsair 400CX 80+ - 59 euro: >> http://www.corsair.com/products/cx/default.aspx >> >> RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro >> ====================== >> Total: ~435 euro >> >> The motherboard has 6 native AHCI-capable ports on ICH9R controller >> and you have a PCI-E slot free if you want to add an additional >> controller card. Feel free to blow the money you've saved on crazy >> fast SATA disks and if your system workload is going to have a lot of >> random reads, then spend 200 euro on a 80gb Intel X25-M for use as a >> dedicated L2ARC device for your pool. > > Based on the Fractal Design case mentioned above, I was told about > Lian Lia cases, which I think are great. As a result, I've gone with > a tower case without hot-swap. The parts are listed at and > reproduced below: > > http://dan.langille.org/2010/02/15/a-full-tower-case/ > > 1. LIAN LI PC-A71F Black Aluminum ATX Full Tower Computer Case $240 > (from mwave) > 2. Antec EarthWatts EA650 650W PSU $80 > 3. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) > 4. Intel S3200SHV LGA 775 Intel 3200 m/b $200 > 5. Intel Core2 Quad Q9400 CPU $190 > 6. SATA cables $22 > 7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 > 8. Kingston ValueRAM 4GB (2 x 2GB) 240-Pin DDR2 SDRAM ECC $97 > > Total cost is about $1020 with shipping. Plus HDD. > > No purchases yet, but the above is what appeals to me now. Dan, I'm not sure about that particular card, but we've never seen that great of performance out of the LSI MegaRAID cards that ship with Dell servers as the PERC. The newest incarnations are better, but I would try to get an Areca. The ones we have tested have displayed fantastic performance. They are fairly expensive in comparison, though. If you're using ZFS in place of the RAID on the LSI MegaRAID, I'd instead recommend other simpler SAS cards which are known to have good driver support. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 21:07:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A6FC1065679 for ; Mon, 15 Feb 2010 21:07:54 +0000 (UTC) (envelope-from nino80@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 92E718FC0A for ; Mon, 15 Feb 2010 21:07:53 +0000 (UTC) Received: by fxm26 with SMTP id 26so5465288fxm.13 for ; Mon, 15 Feb 2010 13:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=VZ/whFbMt6q/9N5555tAwyRdHU0+S0JkAMRFkJsvNOo=; b=KxPGjspRx4jnk6+qv/A5UZPpNHJE5VXuXUc05xhPYx6E/nVKJ2rHy0ucVlhNjvyizo hkBmQT4Pgp9vPQf7VluzT+FAsim7gNxkuFgFypvZiSHCVNRR6wwFVVuMMAXfDqm5B59y m1ssVdxNUQfZzdI2RfDblXCzCI+UM8bQL8CFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=jAPYpSNjE9sGa32lMe2CCAAr4Z5RMTZ617tNxxnz5fN6Hzg3ouasehynZVbVIgGF15 rJY4VyOnZ0S8tHunqKfj+kHuBbPKKW9mS8gzAmgAq/02lYyNOH4Pp1SD34V1GzLHuvxs I4NV2HEbBg0runEILlfzwUxcfR/aI7/c4rC0Q= MIME-Version: 1.0 Received: by 10.102.14.10 with SMTP id 10mr4204435mun.84.1266268072186; Mon, 15 Feb 2010 13:07:52 -0800 (PST) In-Reply-To: <20100215101148.GA56308@icarus.home.lan> References: <92bcbda51002150130i3a1baa4eha06b8ce4f90de486@mail.gmail.com> <20100215101148.GA56308@icarus.home.lan> From: n j Date: Mon, 15 Feb 2010 22:07:32 +0100 Message-ID: <92bcbda51002151307x21f2ac2ax39f890566407bd74@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: ACK and RST packets sent after successfully terminating TCP connection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:07:54 -0000 Hello Jeremy, > Is it possible for you to upload these captures somewhere on the web? > tcpdump -p -i {iface} -s 0 -n -w {somefile} should be sufficient. You can find the two pcaps at http://drop.io/llwiy8o. IP addresses and the data have been anonymized, everything else has been left intact. There was no ICMP traffic between the hosts. Thanks for looking into it! Regards, -- Nino From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 21:15:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890B81065694 for ; Mon, 15 Feb 2010 21:15:37 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 421168FC1C for ; Mon, 15 Feb 2010 21:15:36 +0000 (UTC) Received: by yxe2 with SMTP id 2so5718791yxe.7 for ; Mon, 15 Feb 2010 13:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dS0/77Fn51KXgTiPyYT/sqUV7oS86fhHbVwucHmmrQg=; b=E9ZuISHHZAl+1d7R1JhCzkXwBHpfw8DtxUFfsmsDUE3W0xs0sVKaWnMP5iSTDJcFaq YGsXrW/Ap8KsK2Ryn9YjyaYp7qoQ0SnghtRk8eSHwMcXdwQ0O0E/fPw+/8KyJ+sb6EbQ MekiU5lwCrebSLaPdyoLUCcjtlTQHozUCPKj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xJtY1u+pVDK2l1ufVVirDZ893ZJO8m0V6osy4F2S4wkrj84LMs4ML2+Em7QiGvTUNU 1uP1n+656/ezV09AkxgT0+v6LE60wzHkqpLZHNgG8dSzY2Dpf/T7yKUQ8Uon87HfFHvn SsEFZF5hQMeLLeQZWQvhiI1qnooKedRwfS+JE= MIME-Version: 1.0 Received: by 10.150.87.29 with SMTP id k29mr8587913ybb.134.1266268536473; Mon, 15 Feb 2010 13:15:36 -0800 (PST) In-Reply-To: <33955.188.157.184.107.1266267470.squirrel@mail.deployis.eu> References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> <33955.188.157.184.107.1266267470.squirrel@mail.deployis.eu> Date: Mon, 15 Feb 2010 23:15:36 +0200 Message-ID: From: Dan Naumov To: =?ISO-8859-1?Q?G=F3t_Andr=E1s?= Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:15:37 -0000 >> A C2Q CPU makes little sense right now from a performance POV. For the >> price of that C2Q CPU + LGA775 board you can get an i5 750 CPU and a 1156 >> socket motherboard that will run circles around that C2Q. You would lose >> the ECC though, since that requires the more expensive 1366 socket CPUs >> and boards. >> >> - Sincerely, >> Dan Naumov > > Hi, > > Do have test about this? I'm not really impressed with the i5 series. > > Regards, > Andras There: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3634&p=10 The i5 750, which is a 180 euro CPU, beats Q9650 C2Q, which is a 300 euro CPU. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 21:20:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA2891065695 for ; Mon, 15 Feb 2010 21:20:37 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id DCE278FC1B for ; Mon, 15 Feb 2010 21:20:36 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 61A5019E019; Mon, 15 Feb 2010 22:20:35 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 03D0A19E027; Mon, 15 Feb 2010 22:20:28 +0100 (CET) Message-ID: <4B79BA9C.3020402@quip.cz> Date: Mon, 15 Feb 2010 22:20:28 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Alexander Leidinger References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> In-Reply-To: <20100215161105.14071eiflhc9le68@webmail.leidinger.net> Content-Type: multipart/mixed; boundary="------------050007080204090204030503" Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:20:37 -0000 This is a multi-part message in MIME format. --------------050007080204090204030503 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Alexander Leidinger wrote: [...] >> kstat.zfs.misc.arcstats.c >> kstat.zfs.misc.arcstats.c_min >> kstat.zfs.misc.arcstats.c_max > > c_max is vfs.zfs.arc_max, c_min is vfs.zfs.arc_min. > >> kstat.zfs.misc.arcstats.evict_skip >> kstat.zfs.misc.arcstats.memory_throttle_count >> kstat.zfs.misc.arcstats.size > > I'm not very sure about size and c... both represent some kind of > current size, but they are not the same. > > > About the tuning I would recommend to depend upon a more human readable > representation. I've seen someone posting something like this, but I do > not know how it was generated (some kind of script, but I do not know > where to get it). I think you are referring to this script: http://cuddletech.com/arc_summary/ and its FreeBSD version http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ It gives output like this: # arc_summary.sh System Memory: Physical RAM: 4978 MB Free Memory : 755 MB ARC Size: Current Size: 1028 MB (arcsize) Target Size (Adaptive): 1028 MB (c) Min Size (Hard Limit): 50 MB (zfs_arc_min) Max Size (Hard Limit): 1205 MB (zfs_arc_max) ARC Size Breakdown: Most Recently Used Cache Size: 93% 963 MB (p) Most Frequently Used Cache Size: 6% 65 MB (c-p) ARC Efficency: Cache Access Total: 358720716 Cache Hit Ratio: 97% 350351031 [Defined State for buffer] Cache Miss Ratio: 2% 8369685 [Undefined State for Buffer] REAL Hit Ratio: 76% 272917080 [MRU/MFU Hits Only] Data Demand Efficiency: 96% Data Prefetch Efficiency: 27% CACHE HITS BY CACHE LIST: Anon: 22% 77179355 [ New Customer, First Cache Hit ] Most Recently Used: 45% 158252587 (mru) [ Return Customer ] Most Frequently Used: 32% 114664493 (mfu) [ Frequent Customer ] Most Recently Used Ghost: 0% 9777 (mru_ghost) [ Return Customer Evicted, Now Back ] Most Frequently Used Ghost: 0% 244819 (mfu_ghost) [ Frequent Customer Evicted, Now Back ] CACHE HITS BY DATA TYPE: Demand Data: 1% 4375918 Prefetch Data: 0% 150148 Demand Metadata: 76% 267830502 Prefetch Metadata: 22% 77994463 CACHE MISSES BY DATA TYPE: Demand Data: 1% 135956 Prefetch Data: 4% 400434 Demand Metadata: 73% 6177748 Prefetch Metadata: 19% 1655547 --------------------------------------------- Another useful script is arcstat.pl from http://blogs.sun.com/realneel/entry/zfs_arc_statistics There are FreeBSD version floating around but I can't find a link to it, so I am sending it as attachment. It would be nice to have some "standardized" scripts for monitoring & debugging ZFS issues attached to FreeBSD Wiki page about ZFS tuning. Then everebody will use the same scripts, same output format. It will be easier to compare results in discussions etc. So if anybody of you have write permissions to Wiki, can you add those two scripts? (or make some better ;]) Understanding to tuning of ZFS is really hard with lack of documentation ;( Miroslav Lachman --------------050007080204090204030503 Content-Type: text/plain; name="arcstat.freebsd.pl.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="arcstat.freebsd.pl.txt" IyEvdXNyL2Jpbi9wZXJsIC13CiMKIyBQcmludCBvdXQgWkZTIEFSQyBTdGF0aXN0aWNzIGV4 cG9ydGVkIHZpYSBrc3RhdCgxKQojIEZvciBhIGRlZmluaXRpb24gb2YgZmllbGRzLCBvciB1 c2FnZSwgdXNlIGFyY3RzdGF0LnBsIC12CiMKIyBBdXRob3I6IE5lZWxha2FudGggTmFkZ2ly IGh0dHA6Ly9ibG9ncy5zdW4uY29tL3JlYWxuZWVsCiMgQ29tbWVudHMvUXVlc3Rpb25zL0Zl ZWRiYWNrIHRvIG5lZWxfc3VuLmNvbSBvciBuZWVsX2dudS5vcmcKIwojIENEREwgSEVBREVS IFNUQVJUCiMgCiMgVGhlIGNvbnRlbnRzIG9mIHRoaXMgZmlsZSBhcmUgc3ViamVjdCB0byB0 aGUgdGVybXMgb2YgdGhlCiMgQ29tbW9uIERldmVsb3BtZW50IGFuZCBEaXN0cmlidXRpb24g TGljZW5zZSwgVmVyc2lvbiAxLjAgb25seQojICh0aGUgIkxpY2Vuc2UiKS4gIFlvdSBtYXkg bm90IHVzZSB0aGlzIGZpbGUgZXhjZXB0IGluIGNvbXBsaWFuY2UKIyB3aXRoIHRoZSBMaWNl bnNlLgojIAojIFlvdSBjYW4gb2J0YWluIGEgY29weSBvZiB0aGUgbGljZW5zZSBhdCB1c3Iv c3JjL09QRU5TT0xBUklTLkxJQ0VOU0UKIyBvciBodHRwOi8vd3d3Lm9wZW5zb2xhcmlzLm9y Zy9vcy9saWNlbnNpbmcuCiMgU2VlIHRoZSBMaWNlbnNlIGZvciB0aGUgc3BlY2lmaWMgbGFu Z3VhZ2UgZ292ZXJuaW5nIHBlcm1pc3Npb25zCiMgYW5kIGxpbWl0YXRpb25zIHVuZGVyIHRo ZSBMaWNlbnNlLgojIAojIFdoZW4gZGlzdHJpYnV0aW5nIENvdmVyZWQgQ29kZSwgaW5jbHVk ZSB0aGlzIENEREwgSEVBREVSIGluIGVhY2gKIyBmaWxlIGFuZCBpbmNsdWRlIHRoZSBMaWNl bnNlIGZpbGUgYXQgdXNyL3NyYy9PUEVOU09MQVJJUy5MSUNFTlNFLgojIElmIGFwcGxpY2Fi bGUsIGFkZCB0aGUgZm9sbG93aW5nIGJlbG93IHRoaXMgQ0RETCBIRUFERVIsIHdpdGggdGhl CiMgZmllbGRzIGVuY2xvc2VkIGJ5IGJyYWNrZXRzICJbXSIgcmVwbGFjZWQgd2l0aCB5b3Vy IG93biBpZGVudGlmeWluZwojIGluZm9ybWF0aW9uOiBQb3J0aW9ucyBDb3B5cmlnaHQgW3l5 eXldIFtuYW1lIG9mIGNvcHlyaWdodCBvd25lcl0KIyAKIyBDRERMIEhFQURFUiBFTkQKIwoj CiMgRmllbGRzIGhhdmUgYSBmaXhlZCB3aWR0aC4gRXZlcnkgaW50ZXJ2YWwsIHdlIGZpbGwg dGhlICJ2IgojIGhhc2ggd2l0aCBpdHMgY29ycmVzcG9uZGluZyB2YWx1ZSAodltmaWVsZF09 dmFsdWUpIHVzaW5nIGNhbGN1bGF0ZSgpLiAKIyBAaGRyIGlzIHRoZSBhcnJheSBvZiBmaWVs ZHMgdGhhdCBuZWVkcyB0byBiZSBwcmludGVkLCBzbyB3ZQojIGp1c3QgaXRlcmF0ZSBvdmVy IHRoaXMgYXJyYXkgYW5kIHByaW50IHRoZSB2YWx1ZXMgdXNpbmcgb3VyIHByZXR0eSBwcmlu dGVyLgoKdXNlIHN0cmljdDsKdXNlIFBPU0lYIHF3KHN0cmZ0aW1lKTsKI3VzZSBTdW46OlNv bGFyaXM6OktzdGF0Owp1c2UgR2V0b3B0OjpMb25nOwp1c2UgSU86OkhhbmRsZTsKCm15ICVj b2xzID0gKCMgSERSID0+IFtTaXplLCBEZXNjcmlwdGlvbl0KCSJUaW1lIgk9Pls4LCAiVGlt ZSJdLAoJImhpdHMiCT0+WzQsICJBcmMgcmVhZHMgcGVyIHNlY29uZCJdLAoJIm1pc3MiCT0+ WzQsICJBcmMgbWlzc2VzIHBlciBzZWNvbmQiXSwKCSJyZWFkIgk9Pls0LCAiVG90YWwgQXJj IGFjY2Vzc2VzIHBlciBzZWNvbmQiXSwKCSJIaXQlIgk9Pls0LCAiQXJjIEhpdCBwZXJjZW50 YWdlIl0sCgkibWlzcyUiCT0+WzUsICJBcmMgbWlzcyBwZXJjZW50YWdlIl0sCgkiZGhpdCIJ PT5bNCwgIkRlbWFuZCBEYXRhIGhpdHMgcGVyIHNlY29uZCJdLAoJImRtaXMiCT0+WzQsICJE ZW1hbmQgRGF0YSBtaXNzZXMgcGVyIHNlY29uZCJdLAoJImRoJSIJPT5bMywgIkRlbWFuZCBE YXRhIGhpdCBwZXJjZW50YWdlIl0sCgkiZG0lIgk9PlszLCAiRGVtYW5kIERhdGEgbWlzcyBw ZXJjZW50YWdlIl0sCgkicGhpdCIJPT5bNCwgIlByZWZldGNoIGhpdHMgcGVyIHNlY29uZCJd LAoJInBtaXMiCT0+WzQsICJQcmVmZXRjaCBtaXNzZXMgcGVyIHNlY29uZCJdLAoJInBoJSIJ PT5bMywgIlByZWZldGNoIGhpdHMgcGVyY2VudGFnZSJdLAoJInBtJSIJPT5bMywgIlByZWZl dGNoIG1pc3MgcGVyY2VudGFnZSJdLAoJIm1oaXQiCT0+WzQsICJNZXRhZGF0YSBoaXRzIHBl ciBzZWNvbmQiXSwKCSJtbWlzIgk9Pls0LCAiTWV0YWRhdGEgbWlzc2VzIHBlciBzZWNvbmQi XSwKCSJtcmVhZCIJPT5bNSwgIk1ldGFkYXRhIGFjY2Vzc2VzIHBlciBzZWNvbmQiXSwKCSJt aCUiCT0+WzMsICJNZXRhZGF0YSBoaXQgcGVyY2VudGFnZSJdLAoJIm1tJSIJPT5bMywgIk1l dGFkYXRhIG1pc3MgcGVyY2VudGFnZSJdLAoJImFyY3N6Igk9Pls1LCAiQXJjIFNpemUiXSwK CSJjIiAJPT5bNCwgIkFyYyBUYXJnZXQgU2l6ZSJdLAoJIm1mdSIgCT0+WzQsICJNRlUgTGlz dCBoaXRzIHBlciBzZWNvbmQiXSwKCSJtcnUiIAk9Pls0LCAiTVJVIExpc3QgaGl0cyBwZXIg c2Vjb25kIl0sCgkibWZ1ZyIgCT0+WzQsICJNRlUgR2hvc3QgTGlzdCBoaXRzIHBlciBzZWNv bmQiXSwKCSJtcnVnIiAJPT5bNCwgIk1SVSBHaG9zdCBMaXN0IGhpdHMgcGVyIHNlY29uZCJd LAoJImVza2lwIgk9Pls1LCAiZXZpY3Rfc2tpcCBwZXIgc2Vjb25kIl0sCgkibXR4bWlzIj0+ WzYsICJtdXRleF9taXNzIHBlciBzZWNvbmQiXSwKCSJybWlzIgk9Pls0LCAicmVjeWNsZV9t aXNzIHBlciBzZWNvbmQiXSwKCSJkcmVhZCIJPT5bNSwgIkRlbWFuZCBkYXRhIGFjY2Vzc2Vz IHBlciBzZWNvbmQiXSwKCSJwcmVhZCIJPT5bNSwgIlByZWZldGNoIGFjY2Vzc2VzIHBlciBz ZWNvbmQiXSwKKTsKbXkgJXY9KCk7Cm15IEBoZHIgPSBxdyhUaW1lIHJlYWQgbWlzcyBtaXNz JSBkbWlzIGRtJSBwbWlzIHBtJSBtbWlzIG1tJSBhcmNzeiBjKTsKbXkgQHhoZHIgPSBxdyhU aW1lIG1mdSBtcnUgbWZ1ZyBtcnVnIGVza2lwIG10eG1pcyBybWlzIGRyZWFkIHByZWFkIHJl YWQpOwpteSAkaW50ID0gMTsJCSMgUHJpbnQgc3RhdHMgZXZlcnkgMSBzZWNvbmQgYnkgZGVm YXVsdApteSAkY291bnQgPSAwOwkJIyBQcmludCBzdGF0cyBmb3JldmVyCm15ICRoZHJfaW50 ciA9IDIwOwkjIFByaW50IGhlYWRlciBldmVyeSAyMCBsaW5lcyBvZiBvdXRwdXQKbXkgJG9w ZmlsZSA9ICIiOwpteSAkc2VwID0gIiAgIjsJCSMgRGVmYXVsdCBzZXBlcmF0b3IgaXMgMiBz cGFjZXMKbXkgJHZlcnNpb24gPSAiMC4xIjsKbXkgJGNtZCA9ICJVc2FnZTogYXJjc3RhdC5w bCBbLWh2eF0gWy1mIGZpZWxkc10gWy1vIGZpbGVdIFtpbnRlcnZhbCBbY291bnRdXVxuIjsK bXkgJWN1cjsKbXkgJWQ7Cm15ICRvdXQ7Cm15ICRrc3RhdDsgIyA9IFN1bjo6U29sYXJpczo6 S3N0YXQtPm5ldygpOwpTVERPVVQtPmF1dG9mbHVzaDsKCnN1YiBrc3RhdF91cGRhdGUgewoJ bXkgQGsgPSBgc3lzY3RsICdrc3RhdC56ZnMubWlzYy5hcmNzdGF0cydgOwoKCXVuZGVmICRr c3RhdDsKCglmb3JlYWNoIG15ICRrIChAaykgewoJICBjaG9tcCAkazsKCSAgbXkgKCRuYW1l LCR2YWx1ZSkgPSBzcGxpdCAvOi8sICRrOwoJICBteSBAeiA9IHNwbGl0IC9cLi8sICRuYW1l OwoJICBteSAkbiA9IHBvcCBAejsKCSAgJHtrc3RhdH0tPnt6ZnN9LT57MH0tPnthcmNzdGF0 c30tPnskbn0gPSAkdmFsdWU7Cgl9Cn0KCnN1YiBkZXRhaWxlZF91c2FnZSB7CglwcmludCBT VERFUlIgIkFyY3N0YXQgdmVyc2lvbiAkdmVyc2lvblxuJGNtZCI7CglwcmludCBTVERFUlIg IkZpZWxkIGRlZmluaXRpb25zIGFyZSBhcyBmb2xsb3dzXG4iOwoJZm9yZWFjaCBteSAkaGRy IChrZXlzICVjb2xzKSB7CgkJcHJpbnQgU1RERVJSIHNwcmludGYoIiU2cyA6ICVzXG4iLCAk aGRyLCAkY29sc3skaGRyfVsxXSk7Cgl9CglwcmludCBTVERFUlIgIlxuTm90ZTogSz0xMF4z IE09MTBeNiBHPTEwXjkgYW5kIHNvIG9uXG4iOwoJZXhpdCgxKTsKCn0KCnN1YiB1c2FnZSB7 CglwcmludCBTVERFUlIgIkFyY3N0YXQgdmVyc2lvbiAkdmVyc2lvblxuJGNtZCI7Cglwcmlu dCBTVERFUlIgIlx0IC14IDogUHJpbnQgZXh0ZW5kZWQgc3RhdHNcbiI7CglwcmludCBTVERF UlIgIlx0IC1mIDogU3BlY2lmeSBzcGVjaWZpYyBmaWVsZHMgdG8gcHJpbnQgKHNlZSAtdilc biI7CglwcmludCBTVERFUlIgIlx0IC1vIDogUHJpbnQgc3RhdHMgdG8gZmlsZVxuIjsKCXBy aW50IFNUREVSUiAiXHQgLXMgOiBTcGVjaWZ5IGEgc2VwZXJhdG9yXG5cbkV4YW1wbGVzOlxu IjsKCXByaW50IFNUREVSUiAiXHRhcmNzdGF0IC1vIC90bXAvYS5sb2cgMiAxMFxuIjsKCXBy aW50IFNUREVSUiAiXHRhcmNzdGF0IC1zICwgLW8gL3RtcC9hLmxvZyAyIDEwXG4iOwoJcHJp bnQgU1RERVJSICJcdGFyY3N0YXQgLXZcbiI7CglwcmludCBTVERFUlIgIlx0YXJjc3RhdCAt ZiBUaW1lLEhpdCUsZGglLHBoJSxtaCVcbiI7CglleGl0KDEpOwp9CgpzdWIgaW5pdCB7Cglt eSAkZGVzaXJlZF9jb2xzOwoJbXkgJHhmbGFnID0gJyc7CglteSAkaGZsYWcgPSAnJzsKCW15 ICR2ZmxhZzsKCW15ICRyZXMgPSBHZXRPcHRpb25zKCd4JyA9PiBcJHhmbGFnLAoJCSdvPXMn ID0+IFwkb3BmaWxlLAoJCSdoZWxwfGh8PycgPT4gXCRoZmxhZywKCQkndicgPT4gXCR2Zmxh ZywKCQkncz1zJyA9PiBcJHNlcCwKCQknZj1zJyA9PiBcJGRlc2lyZWRfY29scyk7CgkkaW50 ID0gJEFSR1ZbMF0gfHwgJGludDsKCSRjb3VudCA9ICRBUkdWWzFdIHx8ICRjb3VudDsKCXVz YWdlKCkgaWYgISRyZXMgb3IgJGhmbGFnIG9yICgkeGZsYWcgYW5kICRkZXNpcmVkX2NvbHMp OwoJZGV0YWlsZWRfdXNhZ2UoKSBpZiAkdmZsYWc7CglAaGRyID0gQHhoZHIgaWYgJHhmbGFn OwkJI3Jlc2V0IGhlYWRlcnMgdG8geGhkcgoJaWYgKCRkZXNpcmVkX2NvbHMpIHsKCQlAaGRy ID0gc3BsaXQoL1sgLF0rLywgJGRlc2lyZWRfY29scyk7CgkJIyBOb3cgY2hlY2sgaWYgdGhl eSBhcmUgdmFsaWQgZmllbGRzCgkJbXkgQGludmFsaWQgPSAoKTsKCQlmb3JlYWNoIG15ICRl bGUgKEBoZHIpIHsKCQkJcHVzaChAaW52YWxpZCwgJGVsZSkgaWYgbm90IGV4aXN0cygkY29s c3skZWxlfSk7CgkJfQoJCWlmIChzY2FsYXIgQGludmFsaWQgPiAwKSB7CgkJCXByaW50IFNU REVSUiAiSW52YWxpZCBjb2x1bW4gZGVmaW5pdGlvbiEgLS0gIgoJCQkJLiAiQGludmFsaWRc blxuIjsKCQkJdXNhZ2UoKTsKCQl9Cgl9CglpZiAoJG9wZmlsZSkgewoJCW9wZW4oJG91dCwg Ij4kb3BmaWxlIikgfHxkaWUgIkNhbm5vdCBvcGVuICRvcGZpbGUgZm9yIHdyaXRpbmciOwoJ CSRvdXQtPmF1dG9mbHVzaDsKCQlzZWxlY3QgJG91dDsKCX0KfQoKIyBDYXB0dXJlIGtzdGF0 IHN0YXRpc3RpY3MuIFdlIG1haW50YWluIDMgaGFzaGVzLCBwcmV2LCBjdXIsIGFuZAojIGQg KGRlbHRhKS4gQXMgdGhlaXIgbmFtZXMgaW1wbHkgdGhleSBtYWludGFpbiB0aGUgcHJldmlv dXMsIGN1cnJlbnQsCiMgYW5kIGRlbHRhIChjdXIgLSBwcmV2KSBzdGF0aXN0aWNzLgpzdWIg c25hcF9zdGF0cyB7CglteSAlcHJldiA9ICVjdXI7Cglrc3RhdF91cGRhdGUoKTsKCglteSAk aGFzaHJlZl9jdXIgPSAka3N0YXQtPnsiemZzIn17MH17ImFyY3N0YXRzIn07CgklY3VyID0g JSRoYXNocmVmX2N1cjsKCWZvcmVhY2ggbXkgJGtleSAoa2V5cyAlY3VyKSB7CgkJbmV4dCBp ZiAka2V5ID1+IC9jbGFzcy87CgkJaWYgKGRlZmluZWQgJHByZXZ7JGtleX0pIHsKCQkJJGR7 JGtleX0gPSAkY3VyeyRrZXl9IC0gJHByZXZ7JGtleX07CgkJfSBlbHNlIHsKCQkJJGR7JGtl eX0gPSAkY3VyeyRrZXl9OwoJCX0KCX0KfQoKIyBQcmV0dHkgcHJpbnQgbnVtLiBBcmd1bWVu dHMgYXJlIHdpZHRoIGFuZCBudW0Kc3ViIHByZXR0eW51bSB7CglteSBAc3VmZml4PSgnICcs J0snLCAnTScsICdHJywgJ1QnLCAnUCcsICdFJywgJ1onKTsKCW15ICRudW0gPSAkX1sxXSB8 fCAwOwoJbXkgJHN6ID0gJF9bMF07CglteSAkaW5kZXggPSAwOwoJcmV0dXJuIHNwcmludGYo IiVzIiwgJG51bSkgaWYgbm90ICRudW0gPX4gL15bMC05XC5dKyQvOwoJd2hpbGUgKCRudW0g PiAxMDAwIGFuZCAkaW5kZXggPCA4KSB7CgkJJG51bSA9ICRudW0vMTAwMDsKCQkkaW5kZXgr KzsKCX0KCXJldHVybiBzcHJpbnRmKCIlKmQiLCAkc3osICRudW0pIGlmICgkaW5kZXggPT0g MCk7CglyZXR1cm4gc3ByaW50ZigiJSpkJXMiLCAkc3ogLSAxLCAkbnVtLCRzdWZmaXhbJGlu ZGV4XSk7Cn0KCnN1YiBwcmludF92YWx1ZXMgewoJZm9yZWFjaCBteSAkY29sIChAaGRyKSB7 CgkJcHJpbnRmKCIlcyVzIiwgcHJldHR5bnVtKCRjb2xzeyRjb2x9WzBdLCAkdnskY29sfSks ICRzZXApOwoJfQoJcHJpbnRmKCJcbiIpOwp9CgpzdWIgcHJpbnRfaGVhZGVyIHsKCWZvcmVh Y2ggbXkgJGNvbCAoQGhkcikgewoJCXByaW50ZigiJSpzJXMiLCAkY29sc3skY29sfVswXSwg JGNvbCwgJHNlcCk7Cgl9CglwcmludGYoIlxuIik7Cn0KCnN1YiBjYWxjdWxhdGUgewoJJXY9 KCk7CgkkdnsiVGltZSJ9ID0gc3RyZnRpbWUoIiVIOiVNOiVTIiwgbG9jYWx0aW1lKTsKCSR2 eyJoaXRzIn0gPSAkZHsiaGl0cyJ9LyRpbnQ7CgkkdnsibWlzcyJ9ID0gJGR7Im1pc3NlcyJ9 LyRpbnQ7CgkkdnsicmVhZCJ9ID0gJHZ7ImhpdHMifSArICR2eyJtaXNzIn07CgkkdnsiSGl0 JSJ9ID0gMTAwKiR2eyJoaXRzIn0vJHZ7InJlYWQifSBpZiAkdnsicmVhZCJ9ID4gMDsKCSR2 eyJtaXNzJSJ9ID0gMTAwIC0gJHZ7IkhpdCUifSBpZiAkdnsicmVhZCJ9ID4gMDsKCgkkdnsi ZGhpdCJ9ID0gKCRkeyJkZW1hbmRfZGF0YV9oaXRzIn0gKyAkZHsiZGVtYW5kX21ldGFkYXRh X2hpdHMifSkvJGludDsKCSR2eyJkbWlzIn0gPSAoJGR7ImRlbWFuZF9kYXRhX21pc3NlcyJ9 KyRkeyJkZW1hbmRfbWV0YWRhdGFfbWlzc2VzIn0pLyRpbnQ7CgkkdnsiZHJlYWQifSA9ICR2 eyJkaGl0In0gKyAkdnsiZG1pcyJ9OwoJJHZ7ImRoJSJ9ID0gMTAwKiR2eyJkaGl0In0vJHZ7 ImRyZWFkIn0gaWYgJHZ7ImRyZWFkIn0gPiAwOwoJJHZ7ImRtJSJ9ID0gMTAwIC0gJHZ7ImRo JSJ9IGlmICR2eyJkcmVhZCJ9ID4gMDsKCgkkdnsicGhpdCJ9PSgkZHsicHJlZmV0Y2hfZGF0 YV9oaXRzIn0gKyAkZHsicHJlZmV0Y2hfbWV0YWRhdGFfaGl0cyJ9KS8kaW50OwoJJHZ7InBt aXMifT0oJGR7InByZWZldGNoX2RhdGFfbWlzc2VzIn0KCQkrJGR7InByZWZldGNoX21ldGFk YXRhX21pc3NlcyJ9KS8kaW50OwoJJHZ7InByZWFkIn0gPSAkdnsicGhpdCJ9ICsgJHZ7InBt aXMifTsKCSR2eyJwaCUifSA9IDEwMCokdnsicGhpdCJ9LyR2eyJwcmVhZCJ9IGlmICR2eyJw cmVhZCJ9ID4gMDsKCSR2eyJwbSUifSA9IDEwMCAtICR2eyJwaCUifSBpZiAkdnsicHJlYWQi fSA+IDA7CgoJJHZ7Im1oaXQifT0oJGR7InByZWZldGNoX21ldGFkYXRhX2hpdHMifSskZHsi ZGVtYW5kX21ldGFkYXRhX2hpdHMifSkvJGludDsKCSR2eyJtbWlzIn09KCRkeyJwcmVmZXRj aF9tZXRhZGF0YV9taXNzZXMifQoJCSskZHsiZGVtYW5kX21ldGFkYXRhX21pc3NlcyJ9KS8k aW50OwoJJHZ7Im1yZWFkIn0gPSAkdnsibWhpdCJ9ICsgJHZ7Im1taXMifTsKCSR2eyJtaCUi fSA9IDEwMCokdnsibWhpdCJ9LyR2eyJtcmVhZCJ9IGlmICR2eyJtcmVhZCJ9ID4gMDsKCSR2 eyJtbSUifSA9IDEwMCAtICR2eyJtaCUifSBpZiAkdnsibXJlYWQifSA+IDA7CgoJJHZ7ImFy Y3N6In0gPSAkY3VyeyJzaXplIn07CgkkdnsiYyJ9ID0gJGN1cnsiYyJ9OwoJJHZ7Im1mdSJ9 ID0gJGR7ImhpdHMifS8kaW50OwoJJHZ7Im1ydSJ9ID0gJGR7Im1ydV9oaXRzIn0vJGludDsK CSR2eyJtcnVnIn0gPSAkZHsibXJ1X2dob3N0X2hpdHMifS8kaW50OwoJJHZ7Im1mdWcifSA9 ICRkeyJtcnVfZ2hvc3RfaGl0cyJ9LyRpbnQ7CgkkdnsiZXNraXAifSA9ICRkeyJldmljdF9z a2lwIn0vJGludDsKCSR2eyJybWlzcyJ9ID0gJGR7InJlY3ljbGVfbWlzcyJ9LyRpbnQ7Cgkk dnsibXR4bWlzIn0gPSAkZHsibXV0ZXhfbWlzcyJ9LyRpbnQ7Cn0KCnN1YiBtYWluIHsKCW15 ICRpID0gMDsKCW15ICRjb3VudF9mbGFnID0gMDsKCglpbml0KCk7CglpZiAoJGNvdW50ID4g MCkgeyAkY291bnRfZmxhZyA9IDE7IH0KCXdoaWxlICgxKSB7CgkJcHJpbnRfaGVhZGVyKCkg aWYgKCRpID09IDApOwoJCXNuYXBfc3RhdHMoKTsKCQljYWxjdWxhdGUoKTsKCQlwcmludF92 YWx1ZXMoKTsKCQlsYXN0IGlmICgkY291bnRfZmxhZyA9PSAxICYmICRjb3VudC0tIDw9IDEp OwoJCSRpID0gKCRpID09ICRoZHJfaW50cikgPyAwIDogJGkrMTsKCQlzbGVlcCgkaW50KTsK CX0KCWNsb3NlKCRvdXQpIGlmIGRlZmluZWQgJG91dDsKfQoKJm1haW47Cg== --------------050007080204090204030503-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 21:29:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D40B61065670 for ; Mon, 15 Feb 2010 21:29:25 +0000 (UTC) (envelope-from andrej@antiszoc.hu) Received: from mail.deployis.eu (mail.deployis.eu [217.20.135.253]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD2C8FC12 for ; Mon, 15 Feb 2010 21:29:25 +0000 (UTC) Received: from localhost ([127.0.0.1]:45503 helo=mail.deployis.eu) by mail.deployis.eu with esmtp (Exim 4.69 #1 (Debian)) id 1Nh8VO-0003Sp-Tm from ; Mon, 15 Feb 2010 22:29:24 +0100 Received: from 188.157.184.107 (SquirrelMail authenticated user andrej@antiszoc.hu) by mail.deployis.eu with HTTP; Mon, 15 Feb 2010 22:29:22 +0100 (CET) Message-ID: <35489.188.157.184.107.1266269362.squirrel@mail.deployis.eu> In-Reply-To: References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> <33955.188.157.184.107.1266267470.squirrel@mail.deployis.eu> Date: Mon, 15 Feb 2010 22:29:22 +0100 (CET) From: =?iso-8859-2?Q?G=F3t_Andr=E1s?= To: "Dan Naumov" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Spam-Score-deployiseu: -43 Cc: FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:29:25 -0000 On Hét, Február 15, 2010 10:15 pm, Dan Naumov wrote: >>> A C2Q CPU makes little sense right now from a performance POV. For >>> the price of that C2Q CPU + LGA775 board you can get an i5 750 CPU and >>> a 1156 socket motherboard that will run circles around that C2Q. You >>> would lose the ECC though, since that requires the more expensive 1366 >>> socket CPUs and boards. >>> >>> - Sincerely, >>> Dan Naumov >>> >> >> Hi, >> >> >> Do have test about this? I'm not really impressed with the i5 series. >> >> >> Regards, >> Andras >> > > There: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3634&p=10 > > > The i5 750, which is a 180 euro CPU, beats Q9650 C2Q, which is a 300 euro > CPU. > > > > - Sincerely, > Dan Naumov > > Oh, I was not up to date on price performance ratio. However I'd compare the i5 750 to the Q8400 which is also a 2,66GHz one. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 21:42:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52506106566B for ; Mon, 15 Feb 2010 21:42:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 31B4A8FC14 for ; Mon, 15 Feb 2010 21:42:19 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta11.emeryville.ca.mail.comcast.net with comcast id iLu81d0041zF43QABMffkE; Mon, 15 Feb 2010 21:39:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta24.emeryville.ca.mail.comcast.net with comcast id iMje1d0043S48mS8kMjlYW; Mon, 15 Feb 2010 21:43:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 90F651E301A; Mon, 15 Feb 2010 13:42:01 -0800 (PST) Date: Mon, 15 Feb 2010 13:42:01 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215214201.GA71304@icarus.home.lan> References: <92bcbda51002150130i3a1baa4eha06b8ce4f90de486@mail.gmail.com> <20100215101148.GA56308@icarus.home.lan> <92bcbda51002151307x21f2ac2ax39f890566407bd74@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92bcbda51002151307x21f2ac2ax39f890566407bd74@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ACK and RST packets sent after successfully terminating TCP connection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:42:20 -0000 On Mon, Feb 15, 2010 at 10:07:32PM +0100, n j wrote: > Hello Jeremy, > > > Is it possible for you to upload these captures somewhere on the web? > > tcpdump -p -i {iface} -s 0 -n -w {somefile} should be sufficient. > > You can find the two pcaps at http://drop.io/llwiy8o. IP addresses and > the data have been anonymized, everything else has been left intact. > There was no ICMP traffic between the hosts. Thanks for looking into > it! succ.pcap -- Packet #9: client --> server: client requests TCP connection close (FIN+ACK) Packet #10: server --> client: server sends ACK Packet #11: server --> client: server announces TCP window size of 0, indicating TCP receive buffers are exhausted and that the client should wait before doing anything more Packet #12: server --> client: identical re-sent ACK of packet #10 fail.pcap -- Packet #3: client --> server: initial handshake; TCP ACK Packet #4: server --> client: server sends TCP RST. Software on server likely closed the socket/fd Packet #5: server --> client: server announces TCP window size of 0, indicating TCP receive buffers are exhausted and that the client should wait before doing anything more Packet #6: server --> client: identical re-sent RST of packet #4 Packet #7: client --> server: confirms reset (RST+ACK) Whatever this client/server protocol is, it isn't normal/standard. It's not something like, for example, HTTP, SSH, or FTP; It's a custom protocol and one I haven't seen before. Do you see the above awkward behaviour (zero-sized TCP window packets followed by a retransmission of a prior packet) when using standardised protocols or software, such as Apache (HTTP), OpenSSH (SSH), or FTP? If not, then the client/server software is probably to blame. It may be operating on a raw socket level, populating IP and/or TCP portions of the packet itself rather than relying on socket(2) entirely. If it uses standard kernel socket(2) functionality with PF_INET and SOCK_STREAM, then I'd ask if the source is available publicly to be analysed to determine if this behaviour is intentional or not. Is there VPN and/or NAT involved between the client and server (re: NAT: particularly around the server)? Finally, is it possible to get "ifconfig -a" and "netstat -m" output from the server? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:11:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60029106566B; Mon, 15 Feb 2010 22:11:50 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf03.insightbb.com (mxsf03.insightbb.com [74.128.0.64]) by mx1.freebsd.org (Postfix) with ESMTP id AA5DD8FC15; Mon, 15 Feb 2010 22:11:49 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,480,1262581200"; d="scan'208";a="799998266" Received: from unknown (HELO asav03.insightbb.com) ([172.31.249.123]) by mxsf03.insightbb.com with ESMTP; 15 Feb 2010 17:11:48 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAENVeUvQLicL/2dsb2JhbACcCrxNhFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,480,1262581200"; d="scan'208";a="124794704" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout03.insightbb.com with ESMTP; 15 Feb 2010 17:11:48 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Mon, 15 Feb 2010 17:11:47 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; i386; ; ) References: <20100215171858.GB13685@droso.net> In-Reply-To: <20100215171858.GB13685@droso.net> X-Face: i~b2iK'Z*tJ)pO9@6lJG=k7>N, V~YMq":Iwdl!m|A"g, N@)'|zb[{ Cc: ports@freebsd.org, stable@freebsd.org, re@freebsd.org, portmgr@freebsd.org Subject: Re: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:11:50 -0000 On Monday 15 February 2010 12:19:01 pm Erwin Lansing wrote: > In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. > > Normal upgrade, new ports, and changes that only affect other branches > are allowed without prior approval but with the extra > Feature safe: yes tag in the commit message. Any commit that is > sweeping, i.e. touches a large number of ports, infrastructural changes, > commts to ports with unusually high number of dependent ports, and any > other commit that requires the rebuilding of many packages is not allowed > without prior explicit approval from portmgr after that date. > > When in doubt, please do not hesitate to contact portmgr. > > -erwin > I suspect this means we won't get KDE 4.4 for quite some time... From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:11:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60029106566B; Mon, 15 Feb 2010 22:11:50 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf03.insightbb.com (mxsf03.insightbb.com [74.128.0.64]) by mx1.freebsd.org (Postfix) with ESMTP id AA5DD8FC15; Mon, 15 Feb 2010 22:11:49 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,480,1262581200"; d="scan'208";a="799998266" Received: from unknown (HELO asav03.insightbb.com) ([172.31.249.123]) by mxsf03.insightbb.com with ESMTP; 15 Feb 2010 17:11:48 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAENVeUvQLicL/2dsb2JhbACcCrxNhFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,480,1262581200"; d="scan'208";a="124794704" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout03.insightbb.com with ESMTP; 15 Feb 2010 17:11:48 -0500 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Mon, 15 Feb 2010 17:11:47 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; i386; ; ) References: <20100215171858.GB13685@droso.net> In-Reply-To: <20100215171858.GB13685@droso.net> X-Face: i~b2iK'Z*tJ)pO9@6lJG=k7>N, V~YMq":Iwdl!m|A"g, N@)'|zb[{ Cc: ports@freebsd.org, stable@freebsd.org, re@freebsd.org, portmgr@freebsd.org Subject: Re: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:11:50 -0000 On Monday 15 February 2010 12:19:01 pm Erwin Lansing wrote: > In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. > > Normal upgrade, new ports, and changes that only affect other branches > are allowed without prior approval but with the extra > Feature safe: yes tag in the commit message. Any commit that is > sweeping, i.e. touches a large number of ports, infrastructural changes, > commts to ports with unusually high number of dependent ports, and any > other commit that requires the rebuilding of many packages is not allowed > without prior explicit approval from portmgr after that date. > > When in doubt, please do not hesitate to contact portmgr. > > -erwin > I suspect this means we won't get KDE 4.4 for quite some time... From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:17:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEC871065729; Mon, 15 Feb 2010 22:17:17 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by mx1.freebsd.org (Postfix) with ESMTP id CD7FD8FC13; Mon, 15 Feb 2010 22:17:16 +0000 (UTC) Received: by bwz23 with SMTP id 23so632933bwz.33 for ; Mon, 15 Feb 2010 14:17:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.141.78 with SMTP id l14mr3589935bku.50.1266272235079; Mon, 15 Feb 2010 14:17:15 -0800 (PST) In-Reply-To: <201002151711.47297.freebsd@insightbb.com> References: <20100215171858.GB13685@droso.net> <201002151711.47297.freebsd@insightbb.com> Date: Mon, 15 Feb 2010 23:17:14 +0100 Message-ID: <367b2c981002151417m6b6b4ed8v1e24a89263f65a7b@mail.gmail.com> From: Olivier Smedts To: Steven Friedrich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, re@freebsd.org, stable@freebsd.org, freebsd-stable@freebsd.org, portmgr@freebsd.org Subject: Re: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:17:18 -0000 2010/2/15 Steven Friedrich : > On Monday 15 February 2010 12:19:01 pm Erwin Lansing wrote: >> In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. >> >> Normal upgrade, new ports, and changes that only affect other branches >> are allowed without prior approval but with the extra >> Feature safe: yes tag in the commit message. =A0Any commit that is >> sweeping, i.e. touches a large number of ports, infrastructural changes, >> commts to ports with unusually high number of dependent ports, and any >> other commit that requires the rebuilding of many packages is not allowe= d >> without prior explicit approval from portmgr after that date. >> >> When in doubt, please do not hesitate to contact portmgr. >> >> -erwin >> > I suspect this means we won't get KDE 4.4 for quite some time... http://miwi.bsdcrew.de/2010/02/cft-kde-sc-4-4-0-for-freebsd/ > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:25:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C515106566C for ; Mon, 15 Feb 2010 22:25:58 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5BD8C8FC12 for ; Mon, 15 Feb 2010 22:25:58 +0000 (UTC) Received: by iwn5 with SMTP id 5so2204357iwn.9 for ; Mon, 15 Feb 2010 14:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=AHZ814NXUXCPg/nLvGFIyAivcqDaDU7aen4+RsqLibo=; b=FDmVULoUjtdaIRSTNDcMhLo7CplmWla3pP2a8Ao7DgY/m/jXiQDyXvYJdvtmcLsFq3 qLBHoVhygyHGk/kAxZs9YYLsuthw0RjiYkpLOA4upGc5Wnv1dDMshb02+Wh7bhJ65oZ6 CxsGQx97sP8y75z4VKBZIv6etFIGv6ZqqP+Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=T1/ayhWQ4bfAvRTyEa4hPXl3jXYn82GjxR44G7cUhzZFvSJSEABNY95+hRYCQi37Ke sw0iXcmNo4oh9EF5AZi97Ugho2bdt4Tmei9jvDP4Cudo7nC/aCX73bNdUZVGvQQ06GYe xi3pIxoccVuCV3K1EeqeXqrAS5n0TYexnILqo= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.147.148 with SMTP id l20mr1319405ibv.77.1266272757671; Mon, 15 Feb 2010 14:25:57 -0800 (PST) In-Reply-To: <1140.69.37.94.221.1266256820.squirrel@lock.simons-rock.edu> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <1140.69.37.94.221.1266256820.squirrel@lock.simons-rock.edu> Date: Mon, 15 Feb 2010 14:25:57 -0800 X-Google-Sender-Auth: bf16b9fa9d6878d3 Message-ID: From: Artem Belevich To: "Peter C. Lai" Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Leidinger , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:25:58 -0000 > How much ram are you running with? 8GB on amd64. kmem_size=16G, zfs.arc_max=6G > In a latest test with 8.0-R on i386 with 2GB of ram, an install to a ZFS > root *will* panic the kernel with kmem_size too small with default > settings. Even dropping down to Cy Schubert's uber-small config will panic > the kernel (vm.kmem_size_max = 330M, vfs.zfs.arc_size = 40M, > vfs.zfs.vdev.cache_size = 5M); the system is currently stable using DIST > kernel, vm.kmem_size/max = 512M, arc_size = 40M and vdev.cache_size = 5M. On i386 you don't really have much wiggle room. Your address space is 32-bit and, to make things more interesting, it's split between user-land and kernel. You can keep bumping KVA_PAGES only so far and that's what limits your vm.kmem_size_max which is the upper limit for vm.kmem_size. The bottom line -- if you're planning to use ZFS, do switch to amd64. Even with only 2GB of physical RAM available, your box will behave better. At the very least it will be possible to avoid the panics caused by kmem exhaustion. --Artem From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:31:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 094561065672 for ; Mon, 15 Feb 2010 22:31:37 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id BB6A08FC13 for ; Mon, 15 Feb 2010 22:31:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id B038E50830; Mon, 15 Feb 2010 22:31:35 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8A4M4qa+ObG; Mon, 15 Feb 2010 22:31:34 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 540E750823 ; Mon, 15 Feb 2010 22:31:34 +0000 (GMT) Message-ID: <4B79CB45.1060405@langille.org> Date: Mon, 15 Feb 2010 17:31:33 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Naumov References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:31:37 -0000 Dan Naumov wrote: > On Mon, Feb 15, 2010 at 7:14 PM, Dan Langille wrote: >> Dan Naumov wrote: >>> On Sun, Feb 14, 2010 at 11:38 PM, Dan Langille wrote: >>>> Dan Naumov wrote: >>>>>> On Sun, 14 Feb 2010, Dan Langille wrote: >>>>>>> After creating three different system configurations (Athena, >>>>>>> Supermicro, and HP), my configuration of choice is this Supermicro >>>>>>> setup: >>>>>>> >>>>>>> 1. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >>>>>>> 2. SuperMicro 5046A $750 (+$43 shipping) >>>>>>> 3. LSI SAS 3081E-R $235 >>>>>>> 4. SATA cables $60 >>>>>>> 5. Crucial 3×2G ECC DDR3-1333 $191 (+ $6 shipping) >>>>>>> 6. Xeon W3520 $310 >>>>> You do realise how much of a massive overkill this is and how much you >>>>> are overspending? >>>> I appreciate the comments and feedback. I'd also appreciate alternative >>>> suggestions in addition to what you have contributed so far. Spec out >>>> the >>>> box you would build. >>> ====================== >>> Case: Fractal Design Define R2 - 89 euro: >>> http://www.fractal-design.com/?view=product&prod=32 >>> >>> Mobo/CPU: Supermicro X7SPA-H / Atom D510 - 180-220 euro: >>> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >>> >>> PSU: Corsair 400CX 80+ - 59 euro: >>> http://www.corsair.com/products/cx/default.aspx >>> >>> RAM: Corsair 2x2GB, DDR2 800MHz SO-DIMM, CL5 - 85 euro >>> ====================== >>> Total: ~435 euro >>> >>> The motherboard has 6 native AHCI-capable ports on ICH9R controller >>> and you have a PCI-E slot free if you want to add an additional >>> controller card. Feel free to blow the money you've saved on crazy >>> fast SATA disks and if your system workload is going to have a lot of >>> random reads, then spend 200 euro on a 80gb Intel X25-M for use as a >>> dedicated L2ARC device for your pool. >> Based on the Fractal Design case mentioned above, I was told about Lian Lia >> cases, which I think are great. As a result, I've gone with a tower case >> without hot-swap. The parts are listed at and reproduced below: >> >> http://dan.langille.org/2010/02/15/a-full-tower-case/ >> >> 1. LIAN LI PC-A71F Black Aluminum ATX Full Tower Computer Case $240 (from >> mwave) >> 2. Antec EarthWatts EA650 650W PSU $80 >> 3. Samsung SATA CD/DVD Burner $20 (+ $8 shipping) >> 4. Intel S3200SHV LGA 775 Intel 3200 m/b $200 >> 5. Intel Core2 Quad Q9400 CPU $190 >> 6. SATA cables $22 >> 7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 >> 8. Kingston ValueRAM 4GB (2 x 2GB) 240-Pin DDR2 SDRAM ECC $97 >> >> Total cost is about $1020 with shipping. Plus HDD. >> >> No purchases yet, but the above is what appeals to me now. > > A C2Q CPU makes little sense right now from a performance POV. For the > price of that C2Q CPU + LGA775 board you can get an i5 750 CPU and a > 1156 socket motherboard that will run circles around that C2Q. You > would lose the ECC though, since that requires the more expensive 1366 > socket CPUs and boards. ECC RAM appeals and yes, that comes with a cost. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:43:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D187E106566B; Mon, 15 Feb 2010 22:43:10 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by mx1.freebsd.org (Postfix) with ESMTP id 90C178FC0A; Mon, 15 Feb 2010 22:43:10 +0000 (UTC) Received: by pzk14 with SMTP id 14so6281340pzk.3 for ; Mon, 15 Feb 2010 14:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UF8q7wAzxH35rxB45MjWkJqw+wU0/twxXQmjXBiF7sM=; b=Tb+GoP7dhZoOI92nsUsd/41FJIZ1y90hVKkxPsi9khORgF2Ks4U+IMLpHQ8YuqYTq8 tWVJnp6nj+Z9h7IuJ4BygxUJWIBdNVKp0EUX9zpLbgyQLtMAZAtpENeXljmTXe8nIq4Y coM33I+w2baPxIBpMS8EXwTzlzGHbj3apxPFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g2cPvry0vj0tBwiEVxvqU8nXR2F5W6mqZEmu6QiF+wiaKafwvQ/V0fEDW9KAeja9G4 53zqvISfryQu3QC5zEy+x8SKp34Hz+UGKiSOvQ6pT/g3qNPDAq8vR4eY62r6lebv+Mu4 rDT5HMiAYRD3H7bSDqX0txHoFbHpyBOkIxAGg= MIME-Version: 1.0 Received: by 10.142.55.16 with SMTP id d16mr3761597wfa.166.1266272227334; Mon, 15 Feb 2010 14:17:07 -0800 (PST) In-Reply-To: <201002151711.47297.freebsd@insightbb.com> References: <20100215171858.GB13685@droso.net> <201002151711.47297.freebsd@insightbb.com> Date: Mon, 15 Feb 2010 16:17:07 -0600 Message-ID: <11167f521002151417u52d92b37q706f291c181bf800@mail.gmail.com> From: "Sam Fourman Jr." To: Steven Friedrich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, re@freebsd.org, stable@freebsd.org, freebsd-stable@freebsd.org, portmgr@freebsd.org Subject: Re: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:43:10 -0000 On Mon, Feb 15, 2010 at 4:11 PM, Steven Friedrich w= rote: > On Monday 15 February 2010 12:19:01 pm Erwin Lansing wrote: >> In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. >> >> Normal upgrade, new ports, and changes that only affect other branches >> are allowed without prior approval but with the extra >> Feature safe: yes tag in the commit message. =A0Any commit that is >> sweeping, i.e. touches a large number of ports, infrastructural changes, >> commts to ports with unusually high number of dependent ports, and any >> other commit that requires the rebuilding of many packages is not allowe= d >> without prior explicit approval from portmgr after that date. >> >> When in doubt, please do not hesitate to contact portmgr. >> >> -erwin >> > I suspect this means we won't get KDE 4.4 for quite some time... > _______________________________________________ I am not sure how close KDE 4.4 is but it would have been nice to get KDE in before the freeze Sam Fourman Jr. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:43:10 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D187E106566B; Mon, 15 Feb 2010 22:43:10 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by mx1.freebsd.org (Postfix) with ESMTP id 90C178FC0A; Mon, 15 Feb 2010 22:43:10 +0000 (UTC) Received: by pzk14 with SMTP id 14so6281340pzk.3 for ; Mon, 15 Feb 2010 14:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UF8q7wAzxH35rxB45MjWkJqw+wU0/twxXQmjXBiF7sM=; b=Tb+GoP7dhZoOI92nsUsd/41FJIZ1y90hVKkxPsi9khORgF2Ks4U+IMLpHQ8YuqYTq8 tWVJnp6nj+Z9h7IuJ4BygxUJWIBdNVKp0EUX9zpLbgyQLtMAZAtpENeXljmTXe8nIq4Y coM33I+w2baPxIBpMS8EXwTzlzGHbj3apxPFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g2cPvry0vj0tBwiEVxvqU8nXR2F5W6mqZEmu6QiF+wiaKafwvQ/V0fEDW9KAeja9G4 53zqvISfryQu3QC5zEy+x8SKp34Hz+UGKiSOvQ6pT/g3qNPDAq8vR4eY62r6lebv+Mu4 rDT5HMiAYRD3H7bSDqX0txHoFbHpyBOkIxAGg= MIME-Version: 1.0 Received: by 10.142.55.16 with SMTP id d16mr3761597wfa.166.1266272227334; Mon, 15 Feb 2010 14:17:07 -0800 (PST) In-Reply-To: <201002151711.47297.freebsd@insightbb.com> References: <20100215171858.GB13685@droso.net> <201002151711.47297.freebsd@insightbb.com> Date: Mon, 15 Feb 2010 16:17:07 -0600 Message-ID: <11167f521002151417u52d92b37q706f291c181bf800@mail.gmail.com> From: "Sam Fourman Jr." To: Steven Friedrich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, re@freebsd.org, stable@freebsd.org, freebsd-stable@freebsd.org, portmgr@freebsd.org Subject: Re: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:43:10 -0000 On Mon, Feb 15, 2010 at 4:11 PM, Steven Friedrich w= rote: > On Monday 15 February 2010 12:19:01 pm Erwin Lansing wrote: >> In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. >> >> Normal upgrade, new ports, and changes that only affect other branches >> are allowed without prior approval but with the extra >> Feature safe: yes tag in the commit message. =A0Any commit that is >> sweeping, i.e. touches a large number of ports, infrastructural changes, >> commts to ports with unusually high number of dependent ports, and any >> other commit that requires the rebuilding of many packages is not allowe= d >> without prior explicit approval from portmgr after that date. >> >> When in doubt, please do not hesitate to contact portmgr. >> >> -erwin >> > I suspect this means we won't get KDE 4.4 for quite some time... > _______________________________________________ I am not sure how close KDE 4.4 is but it would have been nice to get KDE in before the freeze Sam Fourman Jr. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:44:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577971065696; Mon, 15 Feb 2010 22:44:12 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by mx1.freebsd.org (Postfix) with ESMTP id 4F11E8FC1C; Mon, 15 Feb 2010 22:44:09 +0000 (UTC) Received: by bwz23 with SMTP id 23so647961bwz.33 for ; Mon, 15 Feb 2010 14:44:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.141.78 with SMTP id l14mr3589935bku.50.1266272235079; Mon, 15 Feb 2010 14:17:15 -0800 (PST) In-Reply-To: <201002151711.47297.freebsd@insightbb.com> References: <20100215171858.GB13685@droso.net> <201002151711.47297.freebsd@insightbb.com> Date: Mon, 15 Feb 2010 23:17:14 +0100 Message-ID: <367b2c981002151417m6b6b4ed8v1e24a89263f65a7b@mail.gmail.com> From: Olivier Smedts To: Steven Friedrich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, re@freebsd.org, stable@freebsd.org, freebsd-stable@freebsd.org, portmgr@freebsd.org Subject: Re: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:44:12 -0000 2010/2/15 Steven Friedrich : > On Monday 15 February 2010 12:19:01 pm Erwin Lansing wrote: >> In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. >> >> Normal upgrade, new ports, and changes that only affect other branches >> are allowed without prior approval but with the extra >> Feature safe: yes tag in the commit message. =A0Any commit that is >> sweeping, i.e. touches a large number of ports, infrastructural changes, >> commts to ports with unusually high number of dependent ports, and any >> other commit that requires the rebuilding of many packages is not allowe= d >> without prior explicit approval from portmgr after that date. >> >> When in doubt, please do not hesitate to contact portmgr. >> >> -erwin >> > I suspect this means we won't get KDE 4.4 for quite some time... http://miwi.bsdcrew.de/2010/02/cft-kde-sc-4-4-0-for-freebsd/ > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:50:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE50D106566C for ; Mon, 15 Feb 2010 22:50:28 +0000 (UTC) (envelope-from jfarmer@goldsword.com) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.243.11]) by mx1.freebsd.org (Postfix) with SMTP id 794588FC0A for ; Mon, 15 Feb 2010 22:50:28 +0000 (UTC) Received: (qmail 9315 invoked from network); 15 Feb 2010 22:51:24 -0000 Received: from audi.websitewelcome.com (67.19.210.130) by gateway05.websitewelcome.com with SMTP; 15 Feb 2010 22:51:24 -0000 Received: from localhost ([127.0.0.1]:59952) by audi.websitewelcome.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nh9ln-0002Pj-3g for freebsd-stable@freebsd.org; Mon, 15 Feb 2010 16:50:23 -0600 Received: from 74.171.98.142 ([74.171.98.142]) by www.goldsword.com (Horde MIME library) with HTTP; Mon, 15 Feb 2010 17:50:22 -0500 Message-ID: <20100215175022.tthc9qe3moks0so4@www.goldsword.com> Date: Mon, 15 Feb 2010 17:50:22 -0500 From: jfarmer@goldsword.com To: freebsd-stable@freebsd.org References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> <33955.188.157.184.107.1266267470.squirrel@mail.deployis.eu> <35489.188.157.184.107.1266269362.squirrel@mail.deployis.eu> In-Reply-To: <35489.188.157.184.107.1266269362.squirrel@mail.deployis.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - audi.websitewelcome.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - goldsword.com Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:50:28 -0000 Just out of curiousity, would not an older server like this: http://www.geeks.com/details.asp?InvtId=DL145-5R (~$75 + shipping) or http://www.geeks.com/details.asp?invtid=DL360-6R&cat=SYS (~$190 + shipping) be a reasonable option? Unless you're looking to suck every last bit of speed or energy savings out the machine, I would think bumping the memory up on one of these, adding one or more eSATA or SAS interfaces and an external drive rack would result in an exceptional "home" server with several TB of storage, decent speed, still costing less than $1K usd.... John ----------------------------------------------------------------- J. T. Farmer GoldSword Systems, Knoxville TN Coach & Instructor Consulting, Knoxville Academy of the Blade Software Development, Maryville Fencing Club Project Management From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 22:55:22 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2EB61065694 for ; Mon, 15 Feb 2010 22:55:22 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9388FC22 for ; Mon, 15 Feb 2010 22:55:22 +0000 (UTC) Received: from lock.simons-rock.edu (lock.simons-rock.edu [192.168.2.211]) by hedwig.simons-rock.edu (Postfix) with ESMTP id A0B0B2BB341; Mon, 15 Feb 2010 17:28:18 -0500 (EST) Received: from lock.simons-rock.edu (lock.simons-rock.edu [127.0.0.1]) by lock.simons-rock.edu (8.13.1/8.13.1) with ESMTP id o1FMSI4h001401; Mon, 15 Feb 2010 17:28:18 -0500 Received: (from apache@localhost) by lock.simons-rock.edu (8.13.1/8.13.1/Submit) id o1FMSI4L001400; Mon, 15 Feb 2010 17:28:18 -0500 X-Authentication-Warning: lock.simons-rock.edu: apache set sender to peter@simons-rock.edu using -f Received: from 69.37.94.221 (SquirrelMail authenticated user peter) by lock.simons-rock.edu with HTTP; Mon, 15 Feb 2010 17:28:18 -0500 (EST) Message-ID: <2539.69.37.94.221.1266272898.squirrel@lock.simons-rock.edu> In-Reply-To: <74c3ddc41002121510w3d16168yca644f739bead74b@mail.gmail.com> References: <74c3ddc41002121510w3d16168yca644f739bead74b@mail.gmail.com> Date: Mon, 15 Feb 2010 17:28:18 -0500 (EST) From: "Peter C. Lai" To: "Adriaan" User-Agent: SquirrelMail/1.4.8-5.el4_8.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Charles Sprickman , stable@freebsd.org Subject: Re: ZFS on root, serial console install X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:55:22 -0000 I did a pxeboot zfs-root install the other day. If you copy the dvd to an nfs export as the root mount, hack the requisite files to do serial console then you will drop to a login prompt when it boots over pxe-tftp. Had no problems setting up zfs root install by skipping sysinstall and fixit entirely: setup your ZFS root, then set DESTDIR and use install.sh in the individual package dirs. http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ2 > On Fri, Feb 12, 2010 at 7:27 AM, Charles Sprickman wrote: >> Any hints on that one? >> >> I finally got around to getting dhcp/tftp/nfs setup on an internal >> network >> to perform normal installs (and with some pxelinux hackery, the ability >> to >> boot a DOS disk or memtest86 disk images). >> >> Sysinstall in general is kind of an unweildy beast over serial, but one >> thing I was not able to accomplish was to get a shell (no extra virtual >> consoles on serial) or attempt any mounting of fixit media.  From my >> last >> install that put ZFS on root, I had to do quite a bit of tapdancing >> since I >> had no DVD or bootable USB media - lots of switching from the install >> disk >> to fixit, which brought me to many chicken and egg moments.  I did it >> though... >> >> But remotely, I'm not seeing a good way to do this.  If mfsroot were >> larger >> and had more tools, then I'd be in business.  This is probably the >> direction >> I need to get shoved in. >> >> I've looked at some other options with pxelinux and perhaps booting the >> mini >> ISO, but I'm not sure that gets me anywhere. >> >> Any tips?  This isn't a make or break situation, I live 15 minutes from >> the >> colo...  It's more of a quest. :) >> > > I would installl a small UFS FBSD system of 1 or 2 Gig on say ad0s1. > That gives you more then the equivalent of a fixit CD. You then use > this mini system as base to install the "real one" on the other > slice(s) > > After having finished the install, you use fdisk to change the active > slice to the new install and reboot. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Peter C. Lai ITS Systems Administrator Bard College at Simon's Rock 84 Alford Rd. Great Barrington, MA 01230 (413) 528-7428 peter at simons-rock.edu From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 23:04:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16623106566B for ; Mon, 15 Feb 2010 23:04:49 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id DD7DB8FC1A for ; Mon, 15 Feb 2010 23:04:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 2EC8050830; Mon, 15 Feb 2010 23:04:48 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51Kq5MPj91ar; Mon, 15 Feb 2010 23:04:47 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 178C350823 ; Mon, 15 Feb 2010 23:04:47 +0000 (GMT) Message-ID: <4B79D30D.8090901@langille.org> Date: Mon, 15 Feb 2010 18:04:45 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Steve Polyack References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> <4B79B6BB.1060809@comcast.net> In-Reply-To: <4B79B6BB.1060809@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Naumov , FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 23:04:49 -0000 Steve Polyack wrote: > On 02/15/10 12:14, Dan Langille wrote: >> 7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 > Dan, > I'm not sure about that particular card, but we've never seen that great > of performance out of the LSI MegaRAID cards that ship with Dell servers > as the PERC. The newest incarnations are better, but I would try to get > an Areca. The ones we have tested have displayed fantastic > performance. They are fairly expensive in comparison, though. If > you're using ZFS in place of the RAID on the LSI MegaRAID, I'd instead > recommend other simpler SAS cards which are known to have good driver > support. Yes, the card will be used as a straight-through and not use for RAID. ZFS will be running raidz for me, possibly raidz2. Given that, I'm not sure if you're suggesting the3 Areca or something else. In addition, I'm not sure what makes a SAS card simpler and supported. Recommendation? Other cards I have considered include: LSI SAS3041E-R 4 port $120 http://www.google.com/products/catalog?q=lsi+sas+pcie&hl=en&cid=1824913543877548833&sa=title#p SYBA SY-PEX40008 PCI Express SATA II 4 port $60 http://www.newegg.com/Product/Product.aspx?Item=N82E16816124027 LSISAS1064 chipset -> SAS3042e http://www.lsi.com/DistributionSystem/AssetDocument/PCIe_3GSAS_UG.pdf SUPERMICRO AOC-SAT2-MV8 64-bit PCI-X133MHz SATA Controller Card $99 http://www.newegg.com/Product/Product.aspx?Item=N82E16815121009 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 23:18:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D47C21065670 for ; Mon, 15 Feb 2010 23:18:11 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7BDC98FC24 for ; Mon, 15 Feb 2010 23:18:11 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA11.westchester.pa.mail.comcast.net with comcast id iPCu1d01V1swQuc5BPJBNb; Mon, 15 Feb 2010 23:18:11 +0000 Received: from [10.0.0.51] ([71.199.122.142]) by omta15.westchester.pa.mail.comcast.net with comcast id iPL11d00n34Sj4f3bPL274; Mon, 15 Feb 2010 23:20:02 +0000 Message-ID: <4B79D63A.10706@comcast.net> Date: Mon, 15 Feb 2010 18:18:18 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dan Langille References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> <4B79B6BB.1060809@comcast.net> <4B79D30D.8090901@langille.org> In-Reply-To: <4B79D30D.8090901@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dan Naumov , FreeBSD-STABLE Mailing List Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 23:18:11 -0000 On 2/15/2010 6:04 PM, Dan Langille wrote: > Steve Polyack wrote: >> On 02/15/10 12:14, Dan Langille wrote: > >>> 7. Supermicro LSI MegaRAID 8 Port SAS RAID Controller $118 > >> Dan, >> I'm not sure about that particular card, but we've never seen that >> great of performance out of the LSI MegaRAID cards that ship with >> Dell servers as the PERC. The newest incarnations are better, but I >> would try to get an Areca. The ones we have tested have displayed >> fantastic performance. They are fairly expensive in comparison, >> though. If you're using ZFS in place of the RAID on the LSI >> MegaRAID, I'd instead recommend other simpler SAS cards which are >> known to have good driver support. > > Yes, the card will be used as a straight-through and not use for RAID. > ZFS will be running raidz for me, possibly raidz2. Given that, I'm > not sure if you're suggesting the3 Areca or something else. > > In addition, I'm not sure what makes a SAS card simpler and supported. > Recommendation? > > Other cards I have considered include: > > LSI SAS3041E-R 4 port $120 > http://www.google.com/products/catalog?q=lsi+sas+pcie&hl=en&cid=1824913543877548833&sa=title#p > > > SYBA SY-PEX40008 PCI Express SATA II 4 port $60 > http://www.newegg.com/Product/Product.aspx?Item=N82E16816124027 > > LSISAS1064 chipset -> SAS3042e > http://www.lsi.com/DistributionSystem/AssetDocument/PCIe_3GSAS_UG.pdf > > SUPERMICRO AOC-SAT2-MV8 64-bit PCI-X133MHz SATA Controller Card $99 > http://www.newegg.com/Product/Product.aspx?Item=N82E16815121009 > All I meant by simpler was that if you're not going to use the RAID portion then you do not have to pay for it. Same goes for SAS - if you're not going to use SAS disks, you only need a SATA controller. The SYBA card you have listed works great with the siis driver (NCQ support). If you don't need SAS support, I think there are Areca cards around $100 that just do SATA w/o RAID. As far as supported, I know that the Areca driver is very good, as is the recently revamped ahci generic and siis drivers. Like I said, those newer LSI cards may be fine, but I've had bad experiences with the PERC4 and PERC5 (/LSI/ MegaRAID SAS 8408E), which are both re-branded LSI MegaRAID cards. They were always very reliable and handled failed disks quite well, but performance was often ... just bad. YMMV. The PERC6 (one of the newer generations) isn't half as bad... If you end up with one of the LSI cards, let us know how it performs ;) From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 23:18:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B5E106579A for ; Mon, 15 Feb 2010 23:18:22 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3FA8FC14 for ; Mon, 15 Feb 2010 23:18:22 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta05.emeryville.ca.mail.comcast.net with comcast id iNBa1d0011eYJf8A5P5CJD; Mon, 15 Feb 2010 23:05:12 +0000 Received: from comcast.net ([98.203.142.76]) by omta19.emeryville.ca.mail.comcast.net with comcast id iP5A1d00Y1f6R9u01P5B5e; Mon, 15 Feb 2010 23:05:12 +0000 Received: by comcast.net (sSMTP sendmail emulation); Mon, 15 Feb 2010 15:05:09 -0800 Date: Mon, 15 Feb 2010 15:05:09 -0800 From: Charlie Kester To: freebsd-stable@freebsd.org Message-ID: <20100215230508.GC19201@comcast.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100215171858.GB13685@droso.net> <201002151711.47297.freebsd@insightbb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <201002151711.47297.freebsd@insightbb.com> X-Mailer: Mutt 1.5.20 X-Composer: VIM 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 23:18:22 -0000 On Mon 15 Feb 2010 at 14:11:47 PST Steven Friedrich wrote: >> >I suspect this means we won't get KDE 4.4 for quite some time... I don't think that it was ever in the plan to get it in before the freeze. Here's what Martin Wilke said in the call for testing: > Before you ask we don't want to put KDE 4.4.0 in the ports tree before > FreeBSD 7.3 was released. But there's no reason to think it will be "quite some time" before we see it in the portstree. Given the past history of the KDE porting team, I would expect to see it shortly after the 7.3 release. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 23:32:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 231D2106566C for ; Mon, 15 Feb 2010 23:32:17 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id DD5068FC0C for ; Mon, 15 Feb 2010 23:32:16 +0000 (UTC) Received: (qmail 12116 invoked by uid 0); 15 Feb 2010 23:32:16 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Feb 2010 23:32:16 -0000 Date: Mon, 15 Feb 2010 18:32:15 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@charles-sprickmans-imac.local To: "Peter C. Lai" In-Reply-To: <2539.69.37.94.221.1266272898.squirrel@lock.simons-rock.edu> Message-ID: References: <74c3ddc41002121510w3d16168yca644f739bead74b@mail.gmail.com> <2539.69.37.94.221.1266272898.squirrel@lock.simons-rock.edu> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1173747300-1266276736=:78881" Cc: stable@freebsd.org, Adriaan Subject: Re: ZFS on root, serial console install X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 23:32:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1173747300-1266276736=:78881 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 15 Feb 2010, Peter C. Lai wrote: > I did a pxeboot zfs-root install the other day. > > If you copy the dvd to an nfs export as the root mount, hack the requisite > files to do serial console then you will drop to a login prompt when it > boots over pxe-tftp. Had no problems setting up zfs root install by > skipping sysinstall and fixit entirely: setup your ZFS root, then set > DESTDIR and use install.sh in the individual package dirs. In short, did you do what I did somewhat accidentally? I did a netboot, set loader.conf to mount mfsroot as my root fs. For reasons I'm still unclear on, it did not grab mfsroot and proceeded to try and mount root over nfs (which happened to be exported RO). It seems like if my nfs was exported rw, I would have been running with all the tools I needed and the drives would be available to me... I'm going to try with rw nfs, currently the machine's locked up as it's confused about a ro root... Thanks, Charles > > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ2 > >> On Fri, Feb 12, 2010 at 7:27 AM, Charles Sprickman wrote: >>> Any hints on that one? >>> >>> I finally got around to getting dhcp/tftp/nfs setup on an internal >>> network >>> to perform normal installs (and with some pxelinux hackery, the ability >>> to >>> boot a DOS disk or memtest86 disk images). >>> >>> Sysinstall in general is kind of an unweildy beast over serial, but one >>> thing I was not able to accomplish was to get a shell (no extra virtual >>> consoles on serial) or attempt any mounting of fixit media.  From my >>> last >>> install that put ZFS on root, I had to do quite a bit of tapdancing >>> since I >>> had no DVD or bootable USB media - lots of switching from the install >>> disk >>> to fixit, which brought me to many chicken and egg moments.  I did it >>> though... >>> >>> But remotely, I'm not seeing a good way to do this.  If mfsroot were >>> larger >>> and had more tools, then I'd be in business.  This is probably the >>> direction >>> I need to get shoved in. >>> >>> I've looked at some other options with pxelinux and perhaps booting the >>> mini >>> ISO, but I'm not sure that gets me anywhere. >>> >>> Any tips?  This isn't a make or break situation, I live 15 minutes from >>> the >>> colo...  It's more of a quest. :) >>> >> >> I would installl a small UFS FBSD system of 1 or 2 Gig on say ad0s1. >> That gives you more then the equivalent of a fixit CD. You then use >> this mini system as base to install the "real one" on the other >> slice(s) >> >> After having finished the install, you use fdisk to change the active >> slice to the new install and reboot. >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > > -- > Peter C. Lai > ITS Systems Administrator > Bard College at Simon's Rock > 84 Alford Rd. > Great Barrington, MA 01230 > (413) 528-7428 > peter at simons-rock.edu > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --0-1173747300-1266276736=:78881-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 00:24:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C516C106568F for ; Tue, 16 Feb 2010 00:24:16 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 39EE48FC08 for ; Tue, 16 Feb 2010 00:24:15 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o1G0O7nV061426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Feb 2010 10:54:07 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 16 Feb 2010 10:53:55 +1030 User-Agent: KMail/1.9.10 References: <4B7980E0.1020907@langille.org> <4B79B6BB.1060809@comcast.net> In-Reply-To: <4B79B6BB.1060809@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2200761.ki4r8joN1f"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002161054.04696.doconnor@gsoft.com.au> X-Spam-Score: -3.639 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Dan Naumov , Steve Polyack , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 00:24:16 -0000 --nextPart2200761.ki4r8joN1f Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 16 Feb 2010, Steve Polyack wrote: > I'm not sure about that particular card, but we've never seen that > great of performance out of the LSI MegaRAID cards that ship with > Dell servers as the PERC. =A0The newest incarnations are better, but I > would try to get an Areca. =A0The ones we have tested have displayed > fantastic > performance. =A0They are fairly expensive in comparison, though. =A0If > you're using ZFS in place of the RAID on the LSI MegaRAID, I'd > instead recommend other simpler SAS cards which are known to have > good driver support. Why even bother with the LSI card at all? That board already has 6 SATA slots - depends how many disks you want to=20 use of course. (5 HDs + 1 DVD drive?) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2200761.ki4r8joN1f Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLeeWk5ZPcIHs/zowRAvzBAJsH9V9Akc2JguiPMkd4H1wUmeW+aQCgpm4f G2JplYbdC9cdFdJk4c6FKwI= =ZYTn -----END PGP SIGNATURE----- --nextPart2200761.ki4r8joN1f-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 00:25:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B5BB1065672 for ; Tue, 16 Feb 2010 00:25:37 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3C99B8FC17 for ; Tue, 16 Feb 2010 00:25:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id A5561508A8; Tue, 16 Feb 2010 00:25:36 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR9nGX7GsGLD; Tue, 16 Feb 2010 00:25:36 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id DDF5350842 ; Tue, 16 Feb 2010 00:25:35 +0000 (GMT) Message-ID: <4B79E5FE.7040200@langille.org> Date: Mon, 15 Feb 2010 19:25:34 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Daniel O'Connor References: <4B7980E0.1020907@langille.org> <4B79B6BB.1060809@comcast.net> <201002161054.04696.doconnor@gsoft.com.au> In-Reply-To: <201002161054.04696.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Naumov , freebsd-stable@freebsd.org, Steve Polyack Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 00:25:37 -0000 Daniel O'Connor wrote: > On Tue, 16 Feb 2010, Steve Polyack wrote: >> I'm not sure about that particular card, but we've never seen that >> great of performance out of the LSI MegaRAID cards that ship with >> Dell servers as the PERC. The newest incarnations are better, but I >> would try to get an Areca. The ones we have tested have displayed >> fantastic >> performance. They are fairly expensive in comparison, though. If >> you're using ZFS in place of the RAID on the LSI MegaRAID, I'd >> instead recommend other simpler SAS cards which are known to have >> good driver support. > > Why even bother with the LSI card at all? > That board already has 6 SATA slots - depends how many disks you want to > use of course. (5 HDs + 1 DVD drive?) Plus two SATA drives in a gmirror for the base OS, and one optical. I want a minimum of 8 slots. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 00:26:15 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3B00106566B; Tue, 16 Feb 2010 00:26:15 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D46F88FC13; Tue, 16 Feb 2010 00:26:15 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id D94A91A3D7C; Mon, 15 Feb 2010 16:08:50 -0800 (PST) Date: Mon, 15 Feb 2010 16:08:50 -0800 From: Alfred Perlstein To: Maxim Sobolev Message-ID: <20100216000850.GC96165@elvis.mu.org> References: <4B793D1D.1000108@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B793D1D.1000108@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Hackers Subject: Re: Sudden mbuf demand increase and shortage under the load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 00:26:16 -0000 * Maxim Sobolev [100215 04:49] wrote: > Hi, > > Our company have a FreeBSD based product that consists of the numerous > interconnected processes and it does some high-PPS UDP processing > (30-50K PPS is not uncommon). We are seeing some strange periodic > failures under the load in several such systems, which usually evidences > itself in IPC (even through unix domain sockets) suddenly either > breaking down or pausing and restoring only some time later (like 5-10 > minutes). The only sign of failure I managed to find was the increase of > the "requests for mbufs denied" in the netstat -m and number of total > mbuf clusters (nmbclusters) raising up to the limit. Hey Maxim Can you run a process to dump sysctl -a every second or so and mark the time when you did it? Other monitoring things would probably be helpful as well (netstat -m) in a timed log format. vmstat -i? (interrupts storm?) Perhaps ps output (showing interrupt threads, etc) would be good toknow perhaps some ithreads went off into the weeds... Any console messages of note? A few people have suggested that there may be too many packets on the outgoing interface, I think there should be a limit to the number of packets queued for outgoing and probably counters to show how many were dropped due to overflow of the outgoing queue. You should be able to check these counters to see what is going on. If the driver is broken and never drops outgoing packets when the card's queue is full, then those counters should be 0. I hope this helps. -Alfred From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 00:37:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 544F41065670 for ; Tue, 16 Feb 2010 00:37:59 +0000 (UTC) (envelope-from jeff.dowsley@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6138FC08 for ; Tue, 16 Feb 2010 00:37:59 +0000 (UTC) MIME-version: 1.0 Received: from [192.168.1.101] (110-175-193-74.static.tpgi.com.au [110.175.193.74]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXW002KPSF82X70@asmtp015.mac.com> for freebsd-stable@freebsd.org; Mon, 15 Feb 2010 16:37:58 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002150251 To: freebsd-stable@freebsd.org Message-id: <1AAFC89E-D1B3-49A7-805F-8DA753C4934E@mac.com> From: Jeff Dowsley Date: Tue, 16 Feb 2010 11:39:53 +1100 X-Mailer: Apple Mail (2.753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Broadcom USB wireless support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 00:37:59 -0000 Gentles I have an old HP Pavillion DV6000 laptop, which has a Broadcom USB wireless device. Worked under Windows Vista. I installed freeBSD 8- stable, and see as the last line in dmesg ugen2.2: at usbus2 Ferreting with google suggests that 8.0 might have usb support for the ndis wrapper, but I am unable to get any joy either using the HP bcmwl5 drivers for the DV6000, or in attempting to use the bwi driver. (I have an old Compaq N1020 with a LinkSys wireless PCMCIA card, which I have successfully generated the ndis wrapper and works happily under 8-stable) Any thoughts? JeffD _____________________________ M 0427565791 jeff.dowsley@mac.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 00:44:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5EC4106566C for ; Tue, 16 Feb 2010 00:44:11 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id AD4D28FC1C for ; Tue, 16 Feb 2010 00:44:11 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta04.emeryville.ca.mail.comcast.net with comcast id iQ8b1d00B1vN32cA4QkCnd; Tue, 16 Feb 2010 00:44:12 +0000 Received: from comcast.net ([98.203.142.76]) by omta22.emeryville.ca.mail.comcast.net with comcast id iQm21d0041f6R9u8iQm9nN; Tue, 16 Feb 2010 00:46:14 +0000 Received: by comcast.net (sSMTP sendmail emulation); Mon, 15 Feb 2010 16:43:57 -0800 Date: Mon, 15 Feb 2010 16:43:57 -0800 From: Charlie Kester To: freebsd-stable@freebsd.org Message-ID: <20100216004357.GD19201@comcast.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100215171858.GB13685@droso.net> <201002151711.47297.freebsd@insightbb.com> <20100215230508.GC19201@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20100215230508.GC19201@comcast.net> X-Mailer: Mutt 1.5.20 X-Composer: VIM 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [HEADSUP]: ports feature freeze now in effect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 00:44:11 -0000 On Mon 15 Feb 2010 at 15:05:09 PST Charlie Kester wrote: >On Mon 15 Feb 2010 at 14:11:47 PST Steven Friedrich wrote: >>> >>I suspect this means we won't get KDE 4.4 for quite some time... > >I don't think that it was ever in the plan to get it in before the >freeze. Here's what Martin Wilke said in the call for testing: > >>Before you ask we don't want to put KDE 4.4.0 in the ports tree before >>FreeBSD 7.3 was released. > >But there's no reason to think it will be "quite some time" before we >see it in the portstree. Given the past history of the KDE porting >team, I would expect to see it shortly after the 7.3 release. Sorry, this was supposed to go to ports@ instead. Looks like I need to debug my muttrc. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 01:50:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 745F2106566B for ; Tue, 16 Feb 2010 01:50:07 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19BFA8FC0A for ; Tue, 16 Feb 2010 01:50:06 +0000 (UTC) Received: by vws20 with SMTP id 20so109775vws.13 for ; Mon, 15 Feb 2010 17:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=q/aWcoWPQKfQ2U3aewXxR40Sx1l9fc2P0dyr3beKZVQ=; b=P7YEdIKcFiG6UDafQN2CuhZPECMaVFcrdl8Kra/mSZQR+UQ5j+pusLG1dnzfDk65YS jfpypsU+w2K58WjADs2PrWysNX4v9YtpYrOogiHW0mAMIbLVSQqeoZpONRiUyBlacXNZ AHPJG3X+12yqpQJA+zOg1K0ukSGt4YqH2TopU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=lcxuPkRFNQKhZVW6T+ET2k2N6N0G+XTTFIhUxr9EF2iSh2ai/d4JgKjq/HjE4q9e0F ejvb8r/9HYhBOIvl6XEyI2bxuGFVwRXiOH5Do8ftbSEL1Rn3IXaHAJ3jX/UEmO3PX4Zu 1zv5pJI1tphwbhIrNJjkXUpraYvULDgrwiE3c= Received: by 10.220.121.139 with SMTP id h11mr408035vcr.27.1266285005423; Mon, 15 Feb 2010 17:50:05 -0800 (PST) Received: from centel.dataix.local (ppp-22.34.dialinfree.com [209.172.22.34]) by mx.google.com with ESMTPS id 35sm2500325vws.0.2010.02.15.17.49.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Feb 2010 17:50:04 -0800 (PST) Sender: "J. Hellenthal" Date: Mon, 15 Feb 2010 20:49:38 -0500 From: jhell To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <4B79BA9C.3020402@quip.cz> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , FreeBSD Stable , Jeremy Chadwick Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 01:50:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 15 Feb 2010 16:20, 000.fbsd@ wrote: > Alexander Leidinger wrote: > > [...] > >>> kstat.zfs.misc.arcstats.c >>> kstat.zfs.misc.arcstats.c_min >>> kstat.zfs.misc.arcstats.c_max >> >> c_max is vfs.zfs.arc_max, c_min is vfs.zfs.arc_min. >> >>> kstat.zfs.misc.arcstats.evict_skip >>> kstat.zfs.misc.arcstats.memory_throttle_count >>> kstat.zfs.misc.arcstats.size >> >> I'm not very sure about size and c... both represent some kind of >> current size, but they are not the same. >> >> >> About the tuning I would recommend to depend upon a more human readable >> representation. I've seen someone posting something like this, but I do >> not know how it was generated (some kind of script, but I do not know >> where to get it). > > I think you are referring to this script: > http://cuddletech.com/arc_summary/ > and its FreeBSD version > http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ > > It gives output like this: > > # arc_summary.sh > > System Memory: > Physical RAM: 4978 MB > Free Memory : 755 MB > > ARC Size: > Current Size: 1028 MB (arcsize) > Target Size (Adaptive): 1028 MB (c) > Min Size (Hard Limit): 50 MB (zfs_arc_min) > Max Size (Hard Limit): 1205 MB (zfs_arc_max) > > ARC Size Breakdown: > Most Recently Used Cache Size: 93% 963 MB (p) > Most Frequently Used Cache Size: 6% 65 MB (c-p) > > ARC Efficency: > Cache Access Total: 358720716 > Cache Hit Ratio: 97% 350351031 [Defined State for > buffer] > Cache Miss Ratio: 2% 8369685 [Undefined State for > Buffer] > REAL Hit Ratio: 76% 272917080 [MRU/MFU Hits Only] > > Data Demand Efficiency: 96% > Data Prefetch Efficiency: 27% > > CACHE HITS BY CACHE LIST: > Anon: 22% 77179355 [ New Customer, > First Cache Hit ] > Most Recently Used: 45% 158252587 (mru) [ Return > Customer ] > Most Frequently Used: 32% 114664493 (mfu) [ Frequent > Customer ] > Most Recently Used Ghost: 0% 9777 (mru_ghost) [ Return > Customer Evicted, Now Back ] > Most Frequently Used Ghost: 0% 244819 (mfu_ghost) [ > Frequent Customer Evicted, Now Back ] > CACHE HITS BY DATA TYPE: > Demand Data: 1% 4375918 > Prefetch Data: 0% 150148 > Demand Metadata: 76% 267830502 > Prefetch Metadata: 22% 77994463 > CACHE MISSES BY DATA TYPE: > Demand Data: 1% 135956 > Prefetch Data: 4% 400434 > Demand Metadata: 73% 6177748 > Prefetch Metadata: 19% 1655547 > --------------------------------------------- > > > Another useful script is arcstat.pl from > http://blogs.sun.com/realneel/entry/zfs_arc_statistics > There are FreeBSD version floating around but I can't find a link to it, so I > am sending it as attachment. > > It would be nice to have some "standardized" scripts for monitoring & > debugging ZFS issues attached to FreeBSD Wiki page about ZFS tuning. Then > everebody will use the same scripts, same output format. It will be easier to > compare results in discussions etc. > > So if anybody of you have write permissions to Wiki, can you add those two > scripts? (or make some better ;]) > > Understanding to tuning of ZFS is really hard with lack of documentation ;( > > Miroslav Lachman > It is funny that you guys are all of a sudden talking about this, as I was just working on some modifications to the arc_summary.pl script for some better formatting and inclusion of kmem statistics. My intent on the modifications is to make the output more usable to the whole community by revealing the relevant system information that can be included in an email to the lists for diagnosis by others. Previously the output of the script was a little bit groggy, had long lines and did not include relevant "other" system information. Currently I am working on cleaning up the code a little and moving the ZFS Tunable section to the bottom of the output where it will actually contain the values of the sysctl's instead of just being a blank list. I would certainly appreciate any feedback I could get from this & other things you think might be relevant in its output. Thanks for bringing this subject up. As I make final modifications to the script I will keep the below URLs updated and welcome any bug reports or modification requests to me personally. Here is the URLs: http://jhell.googlecode.com/files/arc_summary.pl http://jhell.googlecode.com/files/arc_summary.pl.asc MD5 (arc_summary.pl) = bff13dcf119ff979d9aa52b3d8ae53b9 SHA256 (arc_summary.pl) = a29260946760a89614f888d53d0f188fb24bcd96acd5e0917604d494ed843ada SIZE (arc_summary.pl) = 9453 Example output: - --------------------------------------------------------------------- System Summary OS Revision: 199506 OS Release Date: 703100 Hardware Platform: i386 Processor Architecture: i386 Storage pool Version: 13 Filesystem Version: 3 Kernel Memory Usage TEXT: 8950208 KiB, 8 MiB DATA: 206347264 KiB, 196 MiB TOTAL: 215297472 KiB, 205 MiB FreeBSD 7.3-STABLE #0 r203819M Sun Feb 14 15:40:02 EST 2010 root - --------------------------------------------------------------------- ZFS ARC Summary Report System Memory: Physical RAM: 1009 MiB ZFS Tunable (sysctl): vfs.zfs vm.kmem_size vm.kmem_size_max ARC Size: Current Size: 180 MiB (arcsize) Target Size (Adaptive): 182 MiB (c) Min Size (Hard Limit): 80 MiB (arc_min) Max Size (Hard Limit): 480 MiB (arc_max) ARC Size Breakdown: Recently Used Cache Size: 99% 181 MiB (p) Frequently Used Cache Size: 0% 1 MiB (c-p) ARC Efficiency: Cache Access Total: 32355906 Cache Hit Ratio: 97% 31473948 Cache Miss Ratio: 2% 881958 Actual Hit Ratio: 89% 28801408 Data Demand Efficiency: 99% Data Prefetch Efficiency: 44% CACHE HITS BY CACHE LIST: Anonymous: 7% 2303558 Most Recently Used: 13% 4157073 (mru) Most Frequently Used: 78% 24644335 (mfu) Most Recently Used Ghost: 0% 151893 (mru_ghost) Most Frequently Used Ghost: 0% 217089 (mfu_ghost) CACHE HITS BY DATA TYPE: Demand Data: 73% 23206273 Prefetch Data: 0% 14877 Demand Metadata: 14% 4611670 Prefetch Metadata: 11% 3641128 CACHE MISSES BY DATA TYPE: Demand Data: 23% 206991 Prefetch Data: 2% 18760 Demand Metadata: 53% 471124 Prefetch Metadata: 20% 185083 - --------------------------------------------------------------------- - -- jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLefm5AAoJEJBXh4mJ2FR+2wYIAIpC6zPj4/ioak8TspN1blCV LSNG/JXbqat9/e6EAulBSDaF81AyxKrUNMZxQqgNZ+fobhT4AY3odrlhUNbNX9UX r8juktvG2kXhgpKmjYeP+HSM5KKbXZToBNx+sHwaTGKAybyTBNuhupmrbeGoOZVX tmH6C/ZoOANtxmcHVOGDi/fViC1tTf396iBietaCGtKNJ5S6ziqa3DgJgzrJkSQI 2lYNKqcdusUPyxl22ug24Ifsp3TFn2fFYB22durAaXL9ZPHWruWVD2wQ02EPxdND FmdheGS6OPKEG6Ph2ARTuJpJLZCPoN2EQJivkXI6N2WgsK+QRuZhuylVzDvu/3A= =SSRg -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 02:21:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EFAF1065670 for ; Tue, 16 Feb 2010 02:21:00 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id E68308FC12 for ; Tue, 16 Feb 2010 02:20:59 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-123.hsd1.ms.comcast.net [75.65.60.123]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id E188E37B5AF; Mon, 15 Feb 2010 20:20:58 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 33A5D61C41; Mon, 15 Feb 2010 20:20:58 -0600 (CST) Date: Mon, 15 Feb 2010 20:20:58 -0600 From: "Matthew D. Fuller" To: jhell Message-ID: <20100216022058.GM64395@over-yonder.net> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: FreeBSD Stable Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 02:21:00 -0000 On Mon, Feb 15, 2010 at 08:49:38PM -0500 I heard the voice of jhell, and lo! it spake thus: > > As I make final modifications to the script I will keep the below > URLs updated and welcome any bug reports or modification requests to > me personally. Well, here's one: > OS Revision: 199506 There's no reason to show this; it's just confusing because it'll be misinterpreted. kern.osrevision isn't what you probably think it is. It's just the BSD #define in param.h, which (aside from a blip which was instantly reverted) last changed in 1996 when the -Lite2 import was done. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 02:27:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD0111065670 for ; Tue, 16 Feb 2010 02:27:57 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 670D78FC08 for ; Tue, 16 Feb 2010 02:27:57 +0000 (UTC) Received: by ewy3 with SMTP id 3so5912287ewy.13 for ; Mon, 15 Feb 2010 18:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2nJkqoKQY3jyprBd3tMB7rWoyNr2H+aWqy7dsAZ426A=; b=QMiXIHcNuf+eOVXfARa5r7q2gN6uxaIG74+1YFNLrNx77WoVU2pJnNJKjyIyGSKTa+ KdCse9/iKTTWCIxV1wHVgA0QjgnBkXoEoOimxy/oPQb5IR6yknM+wMP6CJ29SaOuvYw3 3UGV8lqVUHxS8Hj7dR0FigV8AUc8tLG2gN/n4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ms0R2zVOSuI0oKap0+SPEl51WL7hBnWO1kSa4EjA4B8ivW7wyXHFWi650QghrpRJsg 6fmf5iQ0jt1mf8WanojghR10Q4iDNIv1fERRiWcJSB+HwLvf9+bfXq2WAv2HQEBEfr7+ 8mjYVkvmwiu9UEIfvI7oLaAORWKgWDYo0LoJ4= MIME-Version: 1.0 Received: by 10.213.97.28 with SMTP id j28mr54263ebn.44.1266285431441; Mon, 15 Feb 2010 17:57:11 -0800 (PST) In-Reply-To: <1AAFC89E-D1B3-49A7-805F-8DA753C4934E@mac.com> References: <1AAFC89E-D1B3-49A7-805F-8DA753C4934E@mac.com> Date: Tue, 16 Feb 2010 01:57:11 +0000 Message-ID: <3a142e751002151757u5916074fka9844a70295208dc@mail.gmail.com> From: Paul B Mahol To: Jeff Dowsley Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Broadcom USB wireless support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 02:27:57 -0000 On 2/16/10, Jeff Dowsley wrote: > Gentles > > I have an old HP Pavillion DV6000 laptop, which has a Broadcom USB > wireless device. Worked under Windows Vista. I installed freeBSD 8- > stable, and see as the last line in dmesg > > ugen2.2: at usbus2 > > Ferreting with google suggests that 8.0 might have usb support for > the ndis wrapper, but I am unable to get any joy either using the HP > bcmwl5 drivers for the DV6000, or in attempting to use the bwi driver. > > (I have an old Compaq N1020 with a LinkSys wireless PCMCIA card, > which I have successfully generated the ndis wrapper and works > happily under 8-stable) > > Any thoughts? Firts, make sure you are using right driver. Second make sure that driver is for XP, because NDISulator supports only 5.1 NDIS api. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 02:51:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698B2106566C for ; Tue, 16 Feb 2010 02:51:14 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 24FE18FC0A for ; Tue, 16 Feb 2010 02:51:13 +0000 (UTC) Received: by iwn5 with SMTP id 5so2372786iwn.9 for ; Mon, 15 Feb 2010 18:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=4NBiIq12pA8N+gVf33tk+JL6U0TK/7Pox9BInCXkP4o=; b=HWbTl7BbRdfK0wSWC7om840sjr+2E9UPa9/HNf6o66zaIYe3126j6dSfNxEJflCVwF YXde2WvbhciMmb4xUzXJByyDfm/yxT7EKMYWSzVu7LA6WtpRDTsrLBOHdZPr0460nQEv Hoj9H2y4AEyNahhGjyFh2bOXfUS4qAs1EqdJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=IkVVQvsO87a6CnziEaBE9qkRWiWibK7wnnOLOBE90igCfKZ0ZRsYbMSXb8kvtS0I3I +ZRF1qhtW8jrPvoNrFpbNN/J0jeXfLUzNGD8wNaL+PyJ5jWUohG//PwjJYhdir+A/Nno 8o7f7BZqWAuJQHf0tqaSlHnAdjhGYQJmQ/6as= Received: by 10.231.148.134 with SMTP id p6mr6218769ibv.96.1266288673306; Mon, 15 Feb 2010 18:51:13 -0800 (PST) Received: from centel.dataix.local (ppp-21.18.dialinfree.com [209.172.21.18]) by mx.google.com with ESMTPS id 23sm1241001iwn.3.2010.02.15.18.51.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Feb 2010 18:51:12 -0800 (PST) Sender: "J. Hellenthal" Date: Mon, 15 Feb 2010 21:51:06 -0500 From: jhell To: "Matthew D. Fuller" In-Reply-To: <20100216022058.GM64395@over-yonder.net> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <20100216022058.GM64395@over-yonder.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 02:51:14 -0000 On Mon, 15 Feb 2010 21:20, fullermd@ wrote: > On Mon, Feb 15, 2010 at 08:49:38PM -0500 I heard the voice of > jhell, and lo! it spake thus: >> >> As I make final modifications to the script I will keep the below >> URLs updated and welcome any bug reports or modification requests to >> me personally. > > Well, here's one: > >> OS Revision: 199506 > > There's no reason to show this; it's just confusing because it'll be > misinterpreted. kern.osrevision isn't what you probably think it is. > It's just the BSD #define in param.h, which (aside from a blip which > was instantly reverted) last changed in 1996 when the -Lite2 import > was done. > Thanks!, No I did not have any understanding of that till this moment but had included it just for completeness. In that case I will mark that for deletion. Regards, -- jhell From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 03:35:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CC4C1065693 for ; Tue, 16 Feb 2010 03:35:30 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 081A48FC1C for ; Tue, 16 Feb 2010 03:35:29 +0000 (UTC) Received: by iwn5 with SMTP id 5so2399226iwn.9 for ; Mon, 15 Feb 2010 19:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=ysG7Y6NtUecoXIttSYWCmzRBdjcLL3e0R4u3vdnn3Ok=; b=URwSXIW+7Ddpzxx75Z5LAKo8VKfDp9bj77ux66xHnfImdZNvVSlypvjNa6WnzPwSIM HeA5bWpboS7PPKPBRmCTDWN5olpqKqPj9Hc2t1JEUJdat9rsKXSVyII1BsvASJMUBk7P RLnzmOWxmoF9h6KSkk+9XRI163XshjjukxPyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=JoTIZCwMtYhKSydximVSxPRQ2D9umGAm9dVIkxbctpbYJEG/pMwU0Ac81vpm3C0FZv S7TnHAa1vHNjPq54rbx8f01b5MNbgXEoTSyQ0XXExB95BT1Wp0ijEH3kCZ5VpEAWaHBM t1nxHR70RxuaDst9h7+Z007iElPbJRVoob7NU= Received: by 10.231.147.148 with SMTP id l20mr1778266ibv.77.1266291329226; Mon, 15 Feb 2010 19:35:29 -0800 (PST) Received: from centel.dataix.local (ppp-21.18.dialinfree.com [209.172.21.18]) by mx.google.com with ESMTPS id 23sm1273700iwn.3.2010.02.15.19.35.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Feb 2010 19:35:28 -0800 (PST) Sender: "J. Hellenthal" Date: Mon, 15 Feb 2010 22:35:22 -0500 From: jhell To: "Matthew D. Fuller" In-Reply-To: <20100216022058.GM64395@over-yonder.net> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <20100216022058.GM64395@over-yonder.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 03:35:30 -0000 On Mon, 15 Feb 2010 21:20, fullermd@ wrote: > On Mon, Feb 15, 2010 at 08:49:38PM -0500 I heard the voice of > jhell, and lo! it spake thus: >> >> As I make final modifications to the script I will keep the below >> URLs updated and welcome any bug reports or modification requests to >> me personally. > > Well, here's one: > >> OS Revision: 199506 > > There's no reason to show this; it's just confusing because it'll be > misinterpreted. kern.osrevision isn't what you probably think it is. > It's just the BSD #define in param.h, which (aside from a blip which > was instantly reverted) last changed in 1996 when the -Lite2 import > was done. > Removed in revision 171, and added output for sysctl tunables to the bottom. Current branches or exact matches of sysctl's that are included are... kern.maxusers vfs.zfs vm.kmem_size vm.kmem_size_max If there is more sysctl's that you think should be added please let me know and I will add and update the script. The new revision(171) is in the same url as before. MD5 (arc_summary.pl) = 29b276a6e2f13eedf5d36370994b7f0e SHA256 (arc_summary.pl) = 15a27b9eb71eddd64ee07a515c136f8467783dfb1075d9707028a082387c5127 SIZE (arc_summary.pl) = 9449 Regards, -- jhell From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 03:44:58 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C797106566C for ; Tue, 16 Feb 2010 03:44:58 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id BBE978FC08 for ; Tue, 16 Feb 2010 03:44:57 +0000 (UTC) Received: from lock.simons-rock.edu (lock.simons-rock.edu [192.168.2.211]) by hedwig.simons-rock.edu (Postfix) with ESMTP id AB0D92BB343; Mon, 15 Feb 2010 22:44:56 -0500 (EST) Received: from lock.simons-rock.edu (lock.simons-rock.edu [127.0.0.1]) by lock.simons-rock.edu (8.13.1/8.13.1) with ESMTP id o1G3iuai002029; Mon, 15 Feb 2010 22:44:56 -0500 Received: (from apache@localhost) by lock.simons-rock.edu (8.13.1/8.13.1/Submit) id o1G3itGe002028; Mon, 15 Feb 2010 22:44:55 -0500 X-Authentication-Warning: lock.simons-rock.edu: apache set sender to peter@simons-rock.edu using -f Received: from 75.41.68.26 (SquirrelMail authenticated user peter) by lock.simons-rock.edu with HTTP; Mon, 15 Feb 2010 22:44:55 -0500 (EST) Message-ID: <50058.75.41.68.26.1266291895.squirrel@lock.simons-rock.edu> In-Reply-To: References: <74c3ddc41002121510w3d16168yca644f739bead74b@mail.gmail.com> <2539.69.37.94.221.1266272898.squirrel@lock.simons-rock.edu> Date: Mon, 15 Feb 2010 22:44:55 -0500 (EST) From: "Peter C. Lai" To: "Charles Sprickman" User-Agent: SquirrelMail/1.4.8-5.el4_8.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "Peter C. Lai" , stable@freebsd.org, Adriaan Subject: Re: ZFS on root, serial console install X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 03:44:58 -0000 > On Mon, 15 Feb 2010, Peter C. Lai wrote: > >> I did a pxeboot zfs-root install the other day. >> >> If you copy the dvd to an nfs export as the root mount, hack the >> requisite >> files to do serial console then you will drop to a login prompt when it >> boots over pxe-tftp. Had no problems setting up zfs root install by >> skipping sysinstall and fixit entirely: setup your ZFS root, then set >> DESTDIR and use install.sh in the individual package dirs. > > In short, did you do what I did somewhat accidentally? I did a netboot, > set loader.conf to mount mfsroot as my root fs. For reasons I'm still > unclear on, it did not grab mfsroot and proceeded to try and mount root > over nfs (which happened to be exported RO). It seems like if my nfs was > exported rw, I would have been running with all the tools I needed and the > drives would be available to me... > > I'm going to try with rw nfs, currently the machine's locked up as it's > confused about a ro root... > > Thanks, > > Charles I didn't muck with the loader at all (well except for ZFS tuning). TBH, my serial console is a hardware redirect that BIOS provides so I actually just mdconfig'ed the ISO and exported that via NFS. By booting NFS root RO, init will bail out before being able to run sysinstall and somehow it will spawn getty instead, asking me to login. Logged in as root and I dropped to /bin/tcsh. > >> >> http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ2 >> >>> On Fri, Feb 12, 2010 at 7:27 AM, Charles Sprickman >>> wrote: >>>> Any hints on that one? >>>> >>>> I finally got around to getting dhcp/tftp/nfs setup on an internal >>>> network >>>> to perform normal installs (and with some pxelinux hackery, the >>>> ability >>>> to >>>> boot a DOS disk or memtest86 disk images). >>>> >>>> Sysinstall in general is kind of an unweildy beast over serial, but >>>> one >>>> thing I was not able to accomplish was to get a shell (no extra >>>> virtual >>>> consoles on serial) or attempt any mounting of fixit media.  From my >>>> last >>>> install that put ZFS on root, I had to do quite a bit of tapdancing >>>> since I >>>> had no DVD or bootable USB media - lots of switching from the install >>>> disk >>>> to fixit, which brought me to many chicken and egg moments.  I did it >>>> though... >>>> >>>> But remotely, I'm not seeing a good way to do this.  If mfsroot were >>>> larger >>>> and had more tools, then I'd be in business.  This is probably the >>>> direction >>>> I need to get shoved in. >>>> >>>> I've looked at some other options with pxelinux and perhaps booting >>>> the >>>> mini >>>> ISO, but I'm not sure that gets me anywhere. >>>> >>>> Any tips?  This isn't a make or break situation, I live 15 minutes >>>> from >>>> the >>>> colo...  It's more of a quest. :) >>>> >>> >>> I would installl a small UFS FBSD system of 1 or 2 Gig on say ad0s1. >>> That gives you more then the equivalent of a fixit CD. You then use >>> this mini system as base to install the "real one" on the other >>> slice(s) >>> >>> After having finished the install, you use fdisk to change the active >>> slice to the new install and reboot. >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >>> >> >> >> -- >> Peter C. Lai >> ITS Systems Administrator >> Bard College at Simon's Rock >> 84 Alford Rd. >> Great Barrington, MA 01230 >> (413) 528-7428 >> peter at simons-rock.edu >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" >>_______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Peter C. Lai ITS Systems Administrator Bard College at Simon's Rock 84 Alford Rd. Great Barrington, MA 01230 (413) 528-7428 peter at simons-rock.edu From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 08:31:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 451441065670 for ; Tue, 16 Feb 2010 08:31:03 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id BE27A8FC19 for ; Tue, 16 Feb 2010 08:31:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o1G8V02E081858; Tue, 16 Feb 2010 11:31:00 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 16 Feb 2010 11:31:00 +0300 (MSK) From: Dmitry Morozovsky To: jfarmer@goldsword.com In-Reply-To: <20100215175022.tthc9qe3moks0so4@www.goldsword.com> Message-ID: References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> <33955.188.157.184.107.1266267470.squirrel@mail.deployis.eu> <35489.188.157.184.107.1266269362.squirrel@mail.deployis.eu> <20100215175022.tthc9qe3moks0so4@www.goldsword.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Tue, 16 Feb 2010 11:31:00 +0300 (MSK) Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 08:31:03 -0000 On Mon, 15 Feb 2010, jfarmer@goldsword.com wrote: > > Just out of curiousity, would not an older server like this: > http://www.geeks.com/details.asp?InvtId=DL145-5R (~$75 + shipping) or > http://www.geeks.com/details.asp?invtid=DL360-6R&cat=SYS (~$190 + shipping) > > be a reasonable option? Unless you're looking to suck every last bit of speed > or energy savings out the machine, I would think bumping the memory up on one > of these, adding one or more eSATA or SAS interfaces and an external drive > rack would result in an exceptional "home" server with several TB of storage, > decent speed, still costing less than $1K usd.... way too noisy, even for the basement :( -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 08:38:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC146106566B; Tue, 16 Feb 2010 08:38:16 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by mx1.freebsd.org (Postfix) with ESMTP id 795528FC0A; Tue, 16 Feb 2010 08:38:16 +0000 (UTC) Received: by ywh12 with SMTP id 12so2804703ywh.7 for ; Tue, 16 Feb 2010 00:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=+5J6+uxyAkotJ787VsFXAHaZcKRVKVZLPGW+XdTHmZc=; b=VOGbp4Z+qsVuZTbZBKtEYtxKmC4kx3YJqz+hS3MXpqYqcrN8KjCDWoySCmwuS8mXpj nNrFWcz1OTs5Ko1nVriWyvr/rnyJQI6XDiWYdqTbf2TygnuwP4CKQUo5KKIYwr+jM4pX FvVxtga4CoctfU4v0zWMcC5IjInuZJhEvrZR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tUp+iXDpgtSDlWls5jokLM+9J6xsgEUF1+We7xzRG5vAwlhIBvz0ES4PnfYFw0otLM r3FJLvTqeAOViIZ6Cfwd6R6dwsbUGLJuZ07Cq6USbJjwosxNt4yfTbFVu8M3rGk1qb0S rHJLnpE5Yymlhq3qexXVFxyGmoRdCW31uMrp0= MIME-Version: 1.0 Received: by 10.101.137.39 with SMTP id p39mr3916724ann.56.1266309495775; Tue, 16 Feb 2010 00:38:15 -0800 (PST) Date: Tue, 16 Feb 2010 10:38:15 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , mattjreimer@gmail.com, rnoland@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: RE: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 08:38:16 -0000 > I don't know, but I plan to test that scenario in a few days. > > Matt Please share the results when you're done, I am really curious :) > It *should* work... I made changes a while back that allow for multiple > vdevs to attach to the root. In this case you should have 3 mirror > vdevs attached to the root, so as long as the BIOS can enumerate all of > the drives, we should find all of the vdevs and build the tree > correctly. It should be simple enough to test in qemu, except that the > BIOS in qemu is a little broken and might not id all of the drives. > > robert. If booting of a stripe of 3 mirrors should work assuming no BIOS bugs, can you explain why is booting off simple stripes (of any number of disks) currently unsupported? I haven't tested that myself, but everywhere I look seems to indicate that booting off a simple stripe doesn't work or is that "everywhere" also out of date after your changes? :) - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 09:25:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCE091065670 for ; Tue, 16 Feb 2010 09:25:08 +0000 (UTC) (envelope-from nino80@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4F28FC0C for ; Tue, 16 Feb 2010 09:25:08 +0000 (UTC) Received: by fxm26 with SMTP id 26so5837497fxm.13 for ; Tue, 16 Feb 2010 01:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=9fsEl3DQdD7bMeMluQrqGfVw4Caa8LRd0wwJwgejG0I=; b=Mnm4Fsm+jyyyVP1Y3uQFllAFaDdk+wyRQkLBOX/2542TfRP2K5X4/yVgOW0MFBwhAz iouQP4L2RaGEiC8R99GMq+huHfEqzmU+IQRfG3OnyOUXCgZW7rh8dV+uhLuC0U/huHxo YtHSbfqPA7NNrM6NggDWYUp4/+qWQtUUecn5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=colsv/SWPwr8W6H38MQrEe82ifF3n82wF1nHFYAwEZXYe/QkWe2JsS0tlXrnT3fht0 cf/Ce9cQISvU7e1GgtRCnS+6fVa+M1JluwNHyTxZbcXqW/878gQWF97pFgPUSbnSFQfG HETG/rVaD4hrLREKkv+msjc6MHwXEyC2TR6Jc= MIME-Version: 1.0 Received: by 10.103.84.30 with SMTP id m30mr4676264mul.22.1266312306108; Tue, 16 Feb 2010 01:25:06 -0800 (PST) In-Reply-To: <20100215214201.GA71304@icarus.home.lan> References: <92bcbda51002150130i3a1baa4eha06b8ce4f90de486@mail.gmail.com> <20100215101148.GA56308@icarus.home.lan> <92bcbda51002151307x21f2ac2ax39f890566407bd74@mail.gmail.com> <20100215214201.GA71304@icarus.home.lan> From: n j Date: Tue, 16 Feb 2010 10:24:46 +0100 Message-ID: <92bcbda51002160124p51d5bd21pdfac4deafbbe67ba@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: ACK and RST packets sent after successfully terminating TCP connection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 09:25:08 -0000 > Packet #9: =A0client --> server: client requests TCP connection close (FI= N+ACK) > Packet #10: server --> client: server sends ACK > > Packet #11: server --> client: server announces TCP window size of 0, > =A0 =A0 =A0 =A0 =A0 =A0indicating TCP receive buffers are exhausted and t= hat the > =A0 =A0 =A0 =A0 =A0 =A0client should wait before doing anything more > Packet #12: server --> client: identical re-sent ACK of packet #10 That is exactly the point: why is server sending any packets when connection was FIN'ned successfully by both sides? To my understanding of networking protocols, packets #11 and #12 should have never been sent. > > Packet #5: server --> client: server announces TCP window size of 0, > =A0 =A0 =A0 =A0 =A0 indicating TCP receive buffers are exhausted and that= the > =A0 =A0 =A0 =A0 =A0 client should wait before doing anything more > Packet #6: server --> client: identical re-sent RST of packet #4 > Packet #7: client --> server: confirms reset (RST+ACK) Actually, it seems server confirm SYN-ACK packet and not the RST (packet #7 is "ack 2849043653" which is packet #2 - I'm running tcpdump with -S to see absolute sequence numbers). > Whatever this client/server protocol is, it isn't normal/standard. =A0It'= s > not something like, for example, HTTP, SSH, or FTP; It's a custom > protocol and one I haven't seen before. It is a custom protocol at the application layer, meaning that instead of HTTP payload it has a different (XML) payload, but everything below is (hopefully) standard. > Do you see the above awkward behaviour (zero-sized TCP window packets > followed by a retransmission of a prior packet) when using standardised > protocols or software, such as Apache (HTTP), OpenSSH (SSH), or FTP? I'll see what I can find out. > If not, then the client/server software is probably to blame. =A0It may b= e > operating on a raw socket level, populating IP and/or TCP portions of > the packet itself rather than relying on socket(2) entirely. Client software is Java on Windows, but according to the pcaps, the client is not misbehaving. On the other hand, server software is Perl IO::Socket::INET which is pretty much a standard library and shouldn't be the problem as well. > If it uses standard kernel socket(2) functionality with PF_INET and > SOCK_STREAM, then I'd ask if the source is available publicly to be > analysed to determine if this behaviour is intentional or not. If needed, posting the relevant code snippets shouldn't be a problem. > Is there VPN and/or NAT involved between the client and server > (re: NAT: particularly around the server)? No. > Finally, is it possible to get "ifconfig -a" and "netstat -m" output > from the server? Certainly. # ifconfig -a (inet addr anonymized) em0: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 00:0b:db:92:51:ec inet aaa.bbb.cc.dd netmask 0xffffff00 broadcast aaa.bbb.cc.255 media: Ethernet autoselect (1000baseTX ) status: active rl0: flags=3D8802 metric 0 mtu 1500 options=3D8 ether 00:c0:df:06:4e:8c media: Ethernet autoselect status: no carrier plip0: flags=3D108810 metric 0 mt= u 1500 lo0: flags=3D8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 # netstat -m 259/1526/1785 mbufs in use (current/cache/total) 256/1360/1616/25600 mbuf clusters in use (current/cache/total/max) 256/768 mbuf+clusters out of packet secondary zone in use (current/cache) 0/552/552/12800 4k (page size) jumbo clusters in use (current/cache/total/m= ax) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 576K/5309K/5886K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/22/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 209 requests for I/O initiated by sendfile 0 calls to protocol drain routines Your help is really appreciated. Regards, --=20 Nino From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 10:23:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D57106566C for ; Tue, 16 Feb 2010 10:23:04 +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 C3F5D8FC17 for ; Tue, 16 Feb 2010 10:23:03 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2C786.dip.t-dialin.net [217.226.199.134]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id AAF838446A3; Tue, 16 Feb 2010 11:22:57 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8D7A3D04CC; Tue, 16 Feb 2010 11:22:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1266315774; bh=bX6fgI2vmnoKard/uI2TjFgAQZBakkLuiE0MIrWmBzE=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qq8h2MAud7Rq4WNH8Xo+O28fXeV2/G/mpK2Hu1zJiRiZTJrY5AS4t2YUBLmyzGWmp 43fDLPdusXRt3XHUwCOzN+2TlZGXNEmIXaORJsnXHOM2lgnd+gSKGS54khOT3bE2bd 3x5ufnF3HF2aAsXxwGSzUI4F4Lvi8N+qlYsN0eB1QBpgP7mlVfTHQAtKcl5ACFpu1s BXaKL4f/iw7odefsh0r9POk/2pNvNsmyRVvJi4IYYfuemAnK/iYJU+Y5d0grgtlUsF lAnrTzmKM+UFaCgWyZ77JKQ4O1czojdWxEZVxJ/moflEDCDmjGts1ssx8hp9bANlVm rK33l1rIPjCvg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o1GAMru3024555; Tue, 16 Feb 2010 11:22:53 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 16 Feb 2010 11:22:53 +0100 Message-ID: <20100216112253.721251o8412cncco@webmail.leidinger.net> Date: Tue, 16 Feb 2010 11:22:53 +0100 From: Alexander Leidinger To: jhell References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: AAF838446A3.264BB X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1266920578.86671@2ykXPPKi64KTKtW5vZNODg X-EBL-Spam-Status: No Cc: FreeBSD Stable , Miroslav Lachman <000.fbsd@quip.cz>, Jeremy Chadwick Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 10:23:04 -0000 Quoting jhell (from Mon, 15 Feb 2010 20:49:38 -0500): > On Mon, 15 Feb 2010 16:20, 000.fbsd@ wrote: >> I think you are referring to this script: >> http://cuddletech.com/arc_summary/ >> and its FreeBSD version >> http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ >> Another useful script is arcstat.pl from >> http://blogs.sun.com/realneel/entry/zfs_arc_statistics >> There are FreeBSD version floating around but I can't find a link >> to it, so I am sending it as attachment. >> >> It would be nice to have some "standardized" scripts for monitoring >> & debugging ZFS issues attached to FreeBSD Wiki page about ZFS >> tuning. Then everebody will use the same scripts, same output >> format. It will be easier to compare results in discussions etc. >> >> So if anybody of you have write permissions to Wiki, can you add >> those two scripts? (or make some better ;]) > It is funny that you guys are all of a sudden talking about this, as > I was just working on some modifications to the arc_summary.pl > script for some better formatting and inclusion of kmem statistics. > Here is the URLs: > http://jhell.googlecode.com/files/arc_summary.pl > http://jhell.googlecode.com/files/arc_summary.pl.asc I added references to all those scripts to the wiki. I also improved (I hope) the some parts. Please have a look and feel free to submit improvements (or register with FirstnameLastname and tell me about it, this way I'm not the bottleneck for changes). Bye, Alexander. -- I'm not stupid, I'm not expendable, and I'M NOT GOING! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 10:29:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69022106566B for ; Tue, 16 Feb 2010 10:29:58 +0000 (UTC) (envelope-from niktychina@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id E1A988FC15 for ; Tue, 16 Feb 2010 10:29:57 +0000 (UTC) Received: by fxm26 with SMTP id 26so5890150fxm.13 for ; Tue, 16 Feb 2010 02:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=p/Gsjw7dcRkSFyqPKqXiu1eO732En5BydYDZzNb+kuk=; b=RX5BzNPs4B3swwIu5p908BaqPU+bUoK03JGAnYSgz03i0JYDrLtwbzUzKcsV3CHRcF EvqPS/KiAVExaIdND4GxrDryKTDaGS7mmbo7hGxZhHqlvYg2XlELLMnpn0mR2gVc+lWA qUmMGrXgJUtBdpKTxy/cphDikGNXB72vyf53Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dDw57o1gowoo2lrxBKRpx+gkCUOfqqB1FKIjCZGL84gxGtckFv8/DJz5ZSIDpIimQd VfvcXL6Ul0EUG614usNI9+d/Rhq1zNjKlWOCyJK13X1Jw+xr5IOgwsmeQW87l9JuKy7g WmHL+1z+uvZJt5R0ey74sIXz/1X0q/dvBt7SU= MIME-Version: 1.0 Received: by 10.86.233.18 with SMTP id f18mr1308391fgh.68.1266316196506; Tue, 16 Feb 2010 02:29:56 -0800 (PST) Date: Tue, 16 Feb 2010 13:29:56 +0300 Message-ID: From: Nikolay Tychina To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: kernel make error: scvidctl.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 10:29:58 -0000 Hi. I csupped RELENG_8, buildworld succeeded, but buildkernel fails. Any ideas what is going wrong here? MAKE=make sh /usr/home/nicholas/example/usr/src/sys/conf/newvers.sh LETTUCE cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/home/nicholas/example/usr/src/sys -I/usr/home/nicholas/example/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug scvidctl.o(.text+0x7d): In function `sc_render_match': /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:867: undefined reference to `__start_set_scrndr_set' scvidctl.o(.text+0x82):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: undefined reference to `__start_set_scrndr_set' scvidctl.o(.text+0x87):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: undefined reference to `__stop_set_scrndr_set' scvidctl.o(.text+0xfe):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: undefined reference to `__stop_set_scrndr_set' scvidctl.o(.text+0x145): In function `sc_set_graphics_mode': /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:261: undefined reference to `vidsw' scvidctl.o(.text+0x2df): In function `sc_set_text_mode': /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:145: undefined reference to `vidsw' scvidctl.o(.text+0xa44): In function `sc_vid_ioctl': /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:500: undefined reference to `vidsw' scvidctl.o(.text+0xa6e):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:504: undefined reference to `vidsw' scvidctl.o(.text+0xaa4):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:508: undefined reference to `vid_get_adapter' scvidctl.o(.text+0xb18):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:530: undefined reference to `vid_get_adapter' scvidctl.o(.text+0xb30):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:534: undefined reference to `vidsw' scvidctl.o(.text+0xb82):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:542: undefined reference to `vid_get_adapter' scvidctl.o(.text+0xb94):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:546: undefined reference to `vidsw' scvidctl.o(.text+0xbf9):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:558: undefined reference to `vidsw' scvidctl.o(.text+0xc9a):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:569: undefined reference to `vidsw' scvidctl.o(.text+0xce0):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:576: undefined reference to `vidsw' scvidctl.o(.text+0xd3a):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:581: undefined reference to `vidsw' scvidctl.o(.text+0xd80):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:588: more undefined references to `vidsw' follow syscons.o(.text+0xd63): In function `sc_cnterm': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2857: undefined reference to `vid_release' syscons.o(.text+0xe11): In function `set_mode': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:3458: undefined reference to `vidsw' syscons.o(.text+0xe58):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:3466: undefined reference to `vidsw' syscons.o(.text+0x10a5): In function `restore_scrn_saver_mode': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2052: undefined reference to `vidsw' syscons.o(.text+0x113a): In function `init_scp': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2984: undefined reference to `vidsw' syscons.o(.text+0x19ea): In function `exchange_scr': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2456: undefined reference to `vidsw' syscons.o(.text+0x1ea5): In function `scvidprobe': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:269: undefined reference to `vid_configure' syscons.o(.text+0x1eb5):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:271: undefined reference to `vid_find_adapter' syscons.o(.text+0x4d51): In function `scinit': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2656: undefined reference to `vid_release' syscons.o(.text+0x4d94):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2670: undefined reference to `vid_allocate' syscons.o(.text+0x4d9f):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2671: undefined reference to `vid_get_adapter' syscons.o(.text+0x4e71):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2701: undefined reference to `vidsw' syscons.o(.text+0x4e92):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2702: undefined reference to `vidsw' syscons.o(.text+0x5236):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2804: undefined reference to `vidsw' *** Error code 1 Stop in /usr/obj/usr/home/nicholas/example/usr/src/sys/LETTUCE. *** Error code 1 Stop in /usr/home/nicholas/example/usr/src. *** Error code 1 Stop in /usr/home/nicholas/example/usr/src. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 10:40:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B18E106566B for ; Tue, 16 Feb 2010 10:40:49 +0000 (UTC) (envelope-from niktychina@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id A3B638FC14 for ; Tue, 16 Feb 2010 10:40:48 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so30217fgb.13 for ; Tue, 16 Feb 2010 02:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=BZuwEPV/K+dmT21r+BLHIxB3SNzi3QkP6w49epXXWuA=; b=sawsE/xtSksALEAMNboHnyZXItNOBUaJuN8nTJ4zRd6mv2vurEpOfG6tlyaNdkqB9g y0/YzmEv3EtwkMH1P9HS2ie95vvQ/03KhAr+/SeE9CbyAmT/B4qWYNWx07gIESgQ3BXr 1s4yIt+Kq93eMUj1DlfzeUqKlm1bdiTGLoKOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=EADq+ezRWmokXsSjuKtuP2d6Wb/U2lO9rAHsr75u2rcYrP/KeriAaEAhiTbcSd8z2Y EEkIAm1IdohTf/9//q7bnsnj8EhJk5/srb7216yNpt0V/hTywiHNKx95FVvJgEQo70Hw CYZRUVRzXHkeB23gZUojj7u4fkn9gGkbyX7JA= MIME-Version: 1.0 Received: by 10.87.69.33 with SMTP id w33mr11197082fgk.29.1266316847279; Tue, 16 Feb 2010 02:40:47 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Feb 2010 13:40:47 +0300 Message-ID: From: Nikolay Tychina To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: kernel make error: scvidctl.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 10:40:49 -0000 Oh, I'm sorry for bothering you all, guys. I commented out vga instead of agp. :) 2010/2/16 Nikolay Tychina > Hi. > > I csupped RELENG_8, buildworld succeeded, but buildkernel fails. Any ideas > what is going wrong here? > > > MAKE=make sh /usr/home/nicholas/example/usr/src/sys/conf/newvers.sh LETTUCE > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I/usr/home/nicholas/example/usr/src/sys > -I/usr/home/nicholas/example/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c > linking kernel.debug > scvidctl.o(.text+0x7d): In function `sc_render_match': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:867: > undefined reference to `__start_set_scrndr_set' > scvidctl.o(.text+0x82):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: > undefined reference to `__start_set_scrndr_set' > scvidctl.o(.text+0x87):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: > undefined reference to `__stop_set_scrndr_set' > scvidctl.o(.text+0xfe):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: > undefined reference to `__stop_set_scrndr_set' > scvidctl.o(.text+0x145): In function `sc_set_graphics_mode': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:261: > undefined reference to `vidsw' > scvidctl.o(.text+0x2df): In function `sc_set_text_mode': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:145: > undefined reference to `vidsw' > scvidctl.o(.text+0xa44): In function `sc_vid_ioctl': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:500: > undefined reference to `vidsw' > scvidctl.o(.text+0xa6e):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:504: > undefined reference to `vidsw' > scvidctl.o(.text+0xaa4):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:508: > undefined reference to `vid_get_adapter' > scvidctl.o(.text+0xb18):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:530: > undefined reference to `vid_get_adapter' > scvidctl.o(.text+0xb30):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:534: > undefined reference to `vidsw' > scvidctl.o(.text+0xb82):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:542: > undefined reference to `vid_get_adapter' > scvidctl.o(.text+0xb94):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:546: > undefined reference to `vidsw' > scvidctl.o(.text+0xbf9):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:558: > undefined reference to `vidsw' > scvidctl.o(.text+0xc9a):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:569: > undefined reference to `vidsw' > scvidctl.o(.text+0xce0):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:576: > undefined reference to `vidsw' > scvidctl.o(.text+0xd3a):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:581: > undefined reference to `vidsw' > scvidctl.o(.text+0xd80):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:588: > more undefined references to `vidsw' follow > syscons.o(.text+0xd63): In function `sc_cnterm': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2857: > undefined reference to `vid_release' > syscons.o(.text+0xe11): In function `set_mode': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:3458: > undefined reference to `vidsw' > syscons.o(.text+0xe58):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:3466: > undefined reference to `vidsw' > syscons.o(.text+0x10a5): In function `restore_scrn_saver_mode': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2052: > undefined reference to `vidsw' > syscons.o(.text+0x113a): In function `init_scp': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2984: > undefined reference to `vidsw' > syscons.o(.text+0x19ea): In function `exchange_scr': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2456: > undefined reference to `vidsw' > syscons.o(.text+0x1ea5): In function `scvidprobe': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:269: undefined > reference to `vid_configure' > syscons.o(.text+0x1eb5):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:271: > undefined reference to `vid_find_adapter' > syscons.o(.text+0x4d51): In function `scinit': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2656: > undefined reference to `vid_release' > syscons.o(.text+0x4d94):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2670: > undefined reference to `vid_allocate' > syscons.o(.text+0x4d9f):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2671: > undefined reference to `vid_get_adapter' > syscons.o(.text+0x4e71):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2701: > undefined reference to `vidsw' > syscons.o(.text+0x4e92):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2702: > undefined reference to `vidsw' > syscons.o(.text+0x5236):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2804: > undefined reference to `vidsw' > *** Error code 1 > > Stop in /usr/obj/usr/home/nicholas/example/usr/src/sys/LETTUCE. > *** Error code 1 > > Stop in /usr/home/nicholas/example/usr/src. > *** Error code 1 > > Stop in /usr/home/nicholas/example/usr/src. > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 10:56:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAFA21065697 for ; Tue, 16 Feb 2010 10:56:32 +0000 (UTC) (envelope-from olivas@new.digiflux.org) Received: from new.digiflux.org (unknown [IPv6:2002:40bf:f55::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9881F8FC0C for ; Tue, 16 Feb 2010 10:56:32 +0000 (UTC) Received: from [127.0.0.1] (cm93.delta53.maxonline.com.sg [59.189.53.93]) by new.digiflux.org (Postfix) with ESMTP id B4237267ECC for ; Tue, 16 Feb 2010 05:56:31 -0500 (EST) Message-ID: <4B7A79D5.2000008@new.digiflux.org> Date: Tue, 16 Feb 2010 18:56:21 +0800 From: Stacy Olivas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Xircom X3201 10/100BaseTX still doesn't work with FreeBSD 7.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 10:56:32 -0000 Hello, I was wondering if there were any plans with regards to the bug mentioned in kern/115623 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/115623)? FreeBSD 7.3-PRERELEASE (haven't tried RC1 yet, pulling the sources down now via cvsup) doesn't work with the card until the patch included in the pr is used. (complete description on what it does before the patch is applied is included in the pr). I added a comment to the pr back in April saying that it didn't work with 7.2. In November, someone replied that it still doesn't work with 8. Any ideas? Thanks -Stacy From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 11:28:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BE4C106568F for ; Tue, 16 Feb 2010 11:28:31 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3468FC34 for ; Tue, 16 Feb 2010 11:28:30 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 2C20C19E019; Tue, 16 Feb 2010 12:28:30 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id F28B619E027; Tue, 16 Feb 2010 12:28:27 +0100 (CET) Message-ID: <4B7A815B.9020502@quip.cz> Date: Tue, 16 Feb 2010 12:28:27 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Dan Langille References: <4B7980E0.1020907@langille.org> <4B79B6BB.1060809@comcast.net> <201002161054.04696.doconnor@gsoft.com.au> <4B79E5FE.7040200@langille.org> In-Reply-To: <4B79E5FE.7040200@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 11:28:31 -0000 Dan Langille wrote: > Daniel O'Connor wrote: [...] >> Why even bother with the LSI card at all? >> That board already has 6 SATA slots - depends how many disks you want >> to use of course. (5 HDs + 1 DVD drive?) > > Plus two SATA drives in a gmirror for the base OS, and one optical. I > want a minimum of 8 slots. I think that 2 HDDs in gmirror just for base OS is an overkill if you want this machine as home storage. You will be fine with booting the base OS from CF card or USB stick. (and you can put two USB flash disks in gmirror if you want redundancy) This way you will save some money, SATA ports/cards and if you will use some kind of fast and big USB stick, you can use part of it as L2ARC for speeding up read performance of ZFS http://www.leidinger.net/blog/2010/02/10/making-zfs-faster/ I have my backup storage machine booted from USB stick (as read-only UFS) with 4x 1TB HDDs in RAIDZ. It is running one and half year without problem. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 11:54:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02BE6106566B for ; Tue, 16 Feb 2010 11:54:35 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6C71E8FC17 for ; Tue, 16 Feb 2010 11:54:33 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-157-119.lns6.adl6.internode.on.net [121.45.157.119]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o1GBsUBB079278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Feb 2010 22:24:31 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Miroslav Lachman <000.fbsd@quip.cz> Date: Tue, 16 Feb 2010 22:24:13 +1030 User-Agent: KMail/1.9.10 References: <4B79E5FE.7040200@langille.org> <4B7A815B.9020502@quip.cz> In-Reply-To: <4B7A815B.9020502@quip.cz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1454622.p4Q8vdztbO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002162224.24636.doconnor@gsoft.com.au> X-Spam-Score: -1.744 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 11:54:35 -0000 --nextPart1454622.p4Q8vdztbO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 16 Feb 2010, Miroslav Lachman wrote: > I have my backup storage machine booted from USB stick (as read-only > UFS) with 4x 1TB HDDs in RAIDZ. It is running one and half year > without problem. Yeah, I am booting off a 4Gb CF card with adapter (I didn't trust the=20 BIOS enough for USB :) I wouldn't use it for a remote system without redundancy but for a home=20 setup a very lightly used flash device seems like an obvious (and cost=20 effective) choice. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1454622.p4Q8vdztbO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLeodw5ZPcIHs/zowRAkpUAJoCX8cwt27/yRNNG2dpTL8DtaV2OACdF4Eg Sl5Z4k7UqBT7kUCizE3b9Ko= =Xjci -----END PGP SIGNATURE----- --nextPart1454622.p4Q8vdztbO-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 12:08:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 655251065672 for ; Tue, 16 Feb 2010 12:08:01 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 2E7B18FC0C for ; Tue, 16 Feb 2010 12:08:00 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-37.bna.bellsouth.net [74.241.172.37]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1GC7wsm054375 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 07:07:59 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Dan Naumov In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Date: Tue, 16 Feb 2010 06:07:53 -0600 Message-Id: <1266322073.11131.30.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: FreeBSD-STABLE Mailing List , mattjreimer@gmail.com Subject: RE: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 12:08:01 -0000 On Tue, 2010-02-16 at 10:38 +0200, Dan Naumov wrote: > > I don't know, but I plan to test that scenario in a few days. > > > > Matt > > Please share the results when you're done, I am really curious :) > > > > It *should* work... I made changes a while back that allow for multiple > > vdevs to attach to the root. In this case you should have 3 mirror > > vdevs attached to the root, so as long as the BIOS can enumerate all of > > the drives, we should find all of the vdevs and build the tree > > correctly. It should be simple enough to test in qemu, except that the > > BIOS in qemu is a little broken and might not id all of the drives. > > > > robert. > > If booting of a stripe of 3 mirrors should work assuming no BIOS bugs, > can you explain why is booting off simple stripes (of any number of > disks) currently unsupported? I haven't tested that myself, but > everywhere I look seems to indicate that booting off a simple stripe > doesn't work or is that "everywhere" also out of date after your > changes? :) I would need to setup a qemu test for it... But I can't think of a reason that it shouldn't work. I currently boot from two physical drives attached to the root. In the boot code we enumerate all the physical vdevs, so that we can correctly identify the correct disk and offset from the block pointer. The mirror driver is really pretty simple. robert. > > - Sincerely, > Dan Naumov -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 12:11:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 462E8106568F for ; Tue, 16 Feb 2010 12:11:46 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB3C8FC08 for ; Tue, 16 Feb 2010 12:11:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id A03A850830; Tue, 16 Feb 2010 12:11:45 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id og9-1qs6Mjgt; Tue, 16 Feb 2010 12:11:44 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 04F4150823 ; Tue, 16 Feb 2010 12:11:39 +0000 (GMT) Message-ID: <4B7A8B75.5050801@langille.org> Date: Tue, 16 Feb 2010 07:11:33 -0500 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable@freebsd.org References: <4B7980E0.1020907@langille.org> <4B79B6BB.1060809@comcast.net> <201002161054.04696.doconnor@gsoft.com.au> <4B79E5FE.7040200@langille.org> <4B7A815B.9020502@quip.cz> In-Reply-To: <4B7A815B.9020502@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 12:11:46 -0000 On 2/16/2010 6:28 AM, Miroslav Lachman wrote: > Dan Langille wrote: >> Daniel O'Connor wrote: > > [...] > >>> Why even bother with the LSI card at all? >>> That board already has 6 SATA slots - depends how many disks you want >>> to use of course. (5 HDs + 1 DVD drive?) >> >> Plus two SATA drives in a gmirror for the base OS, and one optical. I >> want a minimum of 8 slots. > > I think that 2 HDDs in gmirror just for base OS is an overkill if you > want this machine as home storage. You will be fine with booting the > base OS from CF card or USB stick. (and you can put two USB flash disks > in gmirror if you want redundancy) > This way you will save some money, SATA ports/cards and if you will use > some kind of fast and big USB stick, you can use part of it as L2ARC for > speeding up read performance of ZFS > http://www.leidinger.net/blog/2010/02/10/making-zfs-faster/ > > I have my backup storage machine booted from USB stick (as read-only > UFS) with 4x 1TB HDDs in RAIDZ. It is running one and half year without > problem. I agree. However, the machine will be primarily storage, but it will also be running PostgreSQL and Bacula. I already have smaller unused SATA drives laying around here. Thank you -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 12:53:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 236261065679 for ; Tue, 16 Feb 2010 12:53:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA518FC0C for ; Tue, 16 Feb 2010 12:53:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA18651; Tue, 16 Feb 2010 14:53:07 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B7A9532.8070005@icyb.net.ua> Date: Tue, 16 Feb 2010 14:53:06 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Peter Jeremy References: <20100201085131.GA34006@server.vk2pj.dyndns.org> <4B66A0DD.2070109@icyb.net.ua> <20100202063635.GA64643@server.vk2pj.dyndns.org> <4B67C8A6.5050102@icyb.net.ua> <20100202230511.GA19744@pjdesk.au.alcatel-lucent.com> <4B6B4CD8.8060208@icyb.net.ua> <20100214222426.GB67580@server.vk2pj.dyndns.org> In-Reply-To: <20100214222426.GB67580@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel probe order issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 12:53:12 -0000 on 15/02/2010 00:24 Peter Jeremy said the following: > On 2010-Feb-05 00:40:24 +0200, Andriy Gapon wrote: >> I came up with some things with which you can try to experiment: >> >> 1. Boot with hw.pci.usb_early_takeover="0" in loader.conf. >> >> 2. Comment out the following line in sys/dev/usb/controller/uhci_pci.c: >> pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); > > Sorry for the delay in responding. Neither of these made any difference. > > I have also tried asking in FreeBSD-usb and hps@ suggested > trying ukbd.c Rev 43 from p4 - which also didn't help. I am out of ideas, sorry. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 15:56:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BC091065676 for ; Tue, 16 Feb 2010 15:56:54 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0B68FC1F for ; Tue, 16 Feb 2010 15:56:54 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id F35582BB343; Tue, 16 Feb 2010 10:56:52 -0500 (EST) Date: Tue, 16 Feb 2010 10:56:51 -0500 From: "Peter C. Lai" To: Artem Belevich Message-ID: <20100216155651.GI4648@cesium.hyperfine.info> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <1140.69.37.94.221.1266256820.squirrel@lock.simons-rock.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Alexander Leidinger , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 15:56:54 -0000 On 2010-02-15 02:25:57PM -0800, Artem Belevich wrote: > > How much ram are you running with? > > 8GB on amd64. kmem_size=16G, zfs.arc_max=6G > > > In a latest test with 8.0-R on i386 with 2GB of ram, an install to a ZFS > > root *will* panic the kernel with kmem_size too small with default > > settings. Even dropping down to Cy Schubert's uber-small config will panic > > the kernel (vm.kmem_size_max = 330M, vfs.zfs.arc_size = 40M, > > vfs.zfs.vdev.cache_size = 5M); the system is currently stable using DIST > > kernel, vm.kmem_size/max = 512M, arc_size = 40M and vdev.cache_size = 5M. > > On i386 you don't really have much wiggle room. Your address space is > 32-bit and, to make things more interesting, it's split between > user-land and kernel. You can keep bumping KVA_PAGES only so far and > that's what limits your vm.kmem_size_max which is the upper limit for > vm.kmem_size. > > The bottom line -- if you're planning to use ZFS, do switch to amd64. > Even with only 2GB of physical RAM available, your box will behave > better. At the very least it will be possible to avoid the panics > caused by kmem exhaustion. > > --Artem Well this ZFS box (which admittedly is mostly a testbed) is only a lowly NetBurst Gallatin Xeon, pre-amd64 :( -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 16:08:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADFC31065670 for ; Tue, 16 Feb 2010 16:08:13 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6E42A8FC19 for ; Tue, 16 Feb 2010 16:08:13 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id 6609D2BB343; Tue, 16 Feb 2010 11:08:12 -0500 (EST) Date: Tue, 16 Feb 2010 11:08:10 -0500 From: "Peter C. Lai" To: =?iso-8859-1?Q?G=F3t_Andr=E1s?= Message-ID: <20100216160810.GJ4648@cesium.hyperfine.info> References: <4B786D3A.3000408@langille.org> <4B7980E0.1020907@langille.org> <33955.188.157.184.107.1266267470.squirrel@mail.deployis.eu> <35489.188.157.184.107.1266269362.squirrel@mail.deployis.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <35489.188.157.184.107.1266269362.squirrel@mail.deployis.eu> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD-STABLE Mailing List , Dan Naumov Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 16:08:13 -0000 On 2010-02-15 10:29:22PM +0100, Gót András wrote: > On Hét, Február 15, 2010 10:15 pm, Dan Naumov wrote: > >>> A C2Q CPU makes little sense right now from a performance POV. For > >>> the price of that C2Q CPU + LGA775 board you can get an i5 750 CPU and > >>> a 1156 socket motherboard that will run circles around that C2Q. You > >>> would lose the ECC though, since that requires the more expensive 1366 > >>> socket CPUs and boards. > >>> > >>> - Sincerely, > >>> Dan Naumov > >>> > >> > >> Hi, > >> > >> > >> Do have test about this? I'm not really impressed with the i5 series. > >> > >> > >> Regards, > >> Andras > >> > > > > There: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3634&p=10 > > > > > > The i5 750, which is a 180 euro CPU, beats Q9650 C2Q, which is a 300 euro > > CPU. > > > > > > > > - Sincerely, > > Dan Naumov > > > > > > Oh, I was not up to date on price performance ratio. However I'd compare > the i5 750 to the Q8400 which is also a 2,66GHz one. > Perhaps there is some confusion between the i5 and i3? A C2Q will probably beat an i3 at the same clock speed but i5 750 has 8mb of unified cache and the turboboost feature. IMO a lot of the benchmark differences between an i5 and C2Q can be attributed to DDR3 and the onboard ram controller on the i5 reducing latency (which if one is to believe Herb Sutter, is the bane of all modern CPUs). -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 17:06:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0A971065672 for ; Tue, 16 Feb 2010 17:06:46 +0000 (UTC) (envelope-from bp@barryp.org) Received: from itasca.hexavalent.net (itasca.hexavalent.net [67.207.138.180]) by mx1.freebsd.org (Postfix) with ESMTP id 81E568FC0A for ; Tue, 16 Feb 2010 17:06:46 +0000 (UTC) Received: from barryp.org (host-145-114-107-208.midco.net [208.107.114.145]) by itasca.hexavalent.net (Postfix) with ESMTPS id 8DAAF23C2BA for ; Tue, 16 Feb 2010 11:06:45 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=barryp.org; s=itasca; t=1266340005; bh=Q7oSWOwlGnHJXiWfkJoz9UkfU5t9CFgp9kemfr/MI5Y=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qkC4GUPMeglY Ney793nviH9w6rVE7pR6K8hC1IAboMsb94T940RnJkXt5TN/s9fxE8vMHs/rrly/kMN qaiAsjhMJquyjYb50/3XOszxGHGMRgq6L+vnks3dpQlaCikAkelLcglDhY8Ua0AYs0+ bQmi43dEA2KurKpv4ndPuo6I4= Received: from [10.66.0.230] (helo=barry-pedersons-macbook.local) by barryp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1NhQsl-000AW0-8C; Tue, 16 Feb 2010 11:06:43 -0600 Message-ID: <4B7AD0A3.9080701@barryp.org> Date: Tue, 16 Feb 2010 11:06:43 -0600 From: Barry Pederson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: jhell References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:06:46 -0000 On 2/15/10 7:49 PM, jhell wrote: > As I make final modifications to the script I will keep the below URLs > updated and welcome any bug reports or modification requests to me > personally. > > Here is the URLs: > http://jhell.googlecode.com/files/arc_summary.pl > http://jhell.googlecode.com/files/arc_summary.pl.asc Nice. How about including relevant lines from /boot/loader.conf, maybe something like this tacked on the end of the script (excuse my Perl, I'm a Python guy). ---- #### Loader Settings ############# open(LOADER, '/boot/loader.conf'); print "\n/boot/loader.conf settings:\n"; while (){ chomp; if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){ print "\t$_\n"; } } ---- Yes, it should more or less duplicate the sysctl values, but it may make it more obvious where the settings are coming from, or if the user has bad or ignored settings Barry From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 17:58:04 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAC75106566B for ; Tue, 16 Feb 2010 17:58:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2668FC0C for ; Tue, 16 Feb 2010 17:58:04 +0000 (UTC) Received: by qyk29 with SMTP id 29so3849330qyk.13 for ; Tue, 16 Feb 2010 09:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=l3YGn1FdoyzBnBs7oSmW761zOLcpUHM5fubACFgnCqg=; b=QTomRm/22VNtoEDGttgOnx2Laq6Hmb7fPKirIypiyoR8K3Lump0j6BwL+elWlhy0IA TEwCKaI2BZ0FwW7P+5LVBr+R9mmL+gcMfe3vf5nNjXvU9A1RXFs/1D+mHh/Hy+QWEYuU wXG+NVdHtRSbZejdlucidmagX/TUWRnZfIAO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=u/33t7DLwPGpbKgBlcnM6rTaK5iFkSe3R82Sf06YYIJCFvYPaY0axnCQh9ZNF6ShpQ +uHId+MCu2BD6MgZYVbB0aZcasmOg6VKlvljdDt3kx9NhbZOstYYd7aIPa+OsfgvD8Z5 zuSS9TUTQePxbqpg9bwrqmoN+EIgQf30b5eNI= Received: by 10.224.59.224 with SMTP id m32mr3786639qah.76.1266343083561; Tue, 16 Feb 2010 09:58:03 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm19123594qwe.13.2010.02.16.09.58.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 09:58:02 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 16 Feb 2010 09:57:19 -0800 From: Pyun YongHyeon Date: Tue, 16 Feb 2010 09:57:19 -0800 To: Nick Rogers Message-ID: <20100216175719.GB1394@michelle.cdnetworks.com> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:58:05 -0000 On Sun, Feb 14, 2010 at 10:04:58AM -0800, Nick Rogers wrote: > I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone > shed light on the below error? I unfortunately cannot provide a proper crash > dump. The pointer addresses are always the same. The only other thing I've > noticed that may be related is a watchdog timeout on bge0 error before the > panic. Thanks. > Any chance to get backtrace from the crash? > Jan 27 15:25:01 wifi kernel: > Jan 27 15:25:01 wifi kernel: > Jan 27 15:25:01 wifi kernel: Fatal trap 12: page fault while in kernel mode > Jan 27 15:25:01 wifi kernel: cpuid = 4; apic id = 04 > Jan 27 15:25:02 wifi kernel: > Jan 27 15:25:02 wifi kernel: fault virtual address = 0x28 > Jan 27 15:25:02 wifi kernel: fault code = supervisor write data, > page not present > Jan 27 15:25:02 wifi kernel: instruction pointer = > 0x20:0xffffffff803263b7 > Jan 27 15:25:02 wifi kernel: stack pointer = > 0x28:0xffffff8073acdb40 > Jan 27 15:25:02 wifi kernel: frame pointer = > 0x28:0xffffff8073acdba0 > Jan 27 15:25:02 wifi kernel: code segment = base 0x0, limit > 0xfffff, type 0x1b > Jan 27 15:25:02 wifi kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > Jan 27 15:25:02 wifi kernel: processor eflags = > Jan 27 15:25:02 wifi kernel: interrupt enabled, > Jan 27 15:25:02 wifi kernel: resume, > Jan 27 15:25:02 wifi kernel: IOPL = 0 > Jan 27 15:25:02 wifi kernel: > Jan 27 15:25:02 wifi kernel: current process > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 17:59:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09B7C1065698 for ; Tue, 16 Feb 2010 17:59:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id DFCF48FC0A for ; Tue, 16 Feb 2010 17:59:48 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta12.emeryville.ca.mail.comcast.net with comcast id ieW41d0020cQ2SLAChzo4M; Tue, 16 Feb 2010 17:59:49 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta10.emeryville.ca.mail.comcast.net with comcast id ihzn1d00N3S48mS8WhzoWW; Tue, 16 Feb 2010 17:59:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D672D1E301A; Tue, 16 Feb 2010 09:59:46 -0800 (PST) Date: Tue, 16 Feb 2010 09:59:46 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100216175946.GA98082@icarus.home.lan> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B7AD0A3.9080701@barryp.org> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:59:49 -0000 On Tue, Feb 16, 2010 at 11:06:43AM -0600, Barry Pederson wrote: > On 2/15/10 7:49 PM, jhell wrote: > > >As I make final modifications to the script I will keep the below URLs > >updated and welcome any bug reports or modification requests to me > >personally. > > > >Here is the URLs: > >http://jhell.googlecode.com/files/arc_summary.pl > >http://jhell.googlecode.com/files/arc_summary.pl.asc > > Nice. How about including relevant lines from /boot/loader.conf, > maybe something like this tacked on the end of the script (excuse my > Perl, I'm a Python guy). > > ---- > #### Loader Settings ############# > open(LOADER, '/boot/loader.conf'); > print "\n/boot/loader.conf settings:\n"; > while (){ > chomp; > if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){ > print "\t$_\n"; > } > } > ---- > > Yes, it should more or less duplicate the sysctl values, but it may > make it more obvious where the settings are coming from, or if the > user has bad or ignored settings Major problems with the above code: 1) Opens /boot/loader.conf for rw access; should be read-only 2) Makes the assumption /boot/loader.conf exists 3) Does not close the fd 4) Excessively quotes variables for no justified reason 5) Makes some bad assumptions about the contents of the file (ex. comments with the word "zfs" in them would match) The code should really be something like what's below. This should be much more manageable as well (@tunables that is), although I always worry when using grep()... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | #!/usr/local/bin/perl my @tunables = qw( vfs\.zfs\..+ vm\.kmem_size.* ); my $loaderconf = "/boot/loader.conf"; if (-e $loaderconf) { open(FH, "<", $loaderconf) or die; while () { # Get rid of trailing newlines and preceding spaces. chomp; s/^\s+//g; # Match against any key=value pair, and then see if the # key portion matches against any regex string in @tunables. if (/^([\w\.]+)=.+/) { if (grep $1 =~ /$_/, @tunables) { print "\t", $_ , "\n"; } } } close(FH); } From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 18:30:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BA0D106566B for ; Tue, 16 Feb 2010 18:30:38 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by mx1.freebsd.org (Postfix) with ESMTP id D20458FC0A for ; Tue, 16 Feb 2010 18:30:37 +0000 (UTC) Received: by ywh12 with SMTP id 12so3281150ywh.7 for ; Tue, 16 Feb 2010 10:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sQo+HHrzVqeq8sjVgxQ3yH/mf2HTYtXDeNHIrEcRVAA=; b=jhN3Gy++d2mmc2kX3lcfv2xSnnz8YDFEVeVFPHg4pUIwyh33WFfW+D8Q49aEfTDpVv g69Rol/RY4QvGrPfbxucM/i+h1ZdWJCJgsp3/FZyWiWZAhko/+VWwTRhXKV9tfdmchYR qLLG1ChclJ2Y0FX3O1pJciC9BIH56EU3MFahU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BzlvFu5entiXjxQMGlw32pT0/GahMW2BO2F/jSy+bYr8caD9ohU8M7lXSlTELNQzQ+ fRT8vtVPJ8+28EoBEb8RMyazxNHAh3VxkOPcwJo3JYjId+85biB9ZS7vBXAh9VFA2oev rdTp2toqG0lJ2W/gHOoxAMKtgbnkh6WFj8okQ= MIME-Version: 1.0 Received: by 10.151.88.26 with SMTP id q26mr12781699ybl.69.1266345036844; Tue, 16 Feb 2010 10:30:36 -0800 (PST) In-Reply-To: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> Date: Tue, 16 Feb 2010 10:30:36 -0800 Message-ID: From: Matt Reimer To: jhell Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Leidinger , FreeBSD Stable , Miroslav Lachman <000.fbsd@quip.cz>, Jeremy Chadwick Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 18:30:38 -0000 On Mon, Feb 15, 2010 at 5:49 PM, jhell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It is funny that you guys are all of a sudden talking about this, as I was > just working on some modifications to the arc_summary.pl script for some > better formatting and inclusion of kmem statistics. > > My intent on the modifications is to make the output more usable to the > whole community by revealing the relevant system information that can be > included in an email to the lists for diagnosis by others. > ... > Example output: > - --------------------------------------------------------------------- > System Summary > OS Revision: 199506 > OS Release Date: 703100 > Hardware Platform: i386 > Processor Architecture: i386 > Storage pool Version: 13 > Filesystem Version: 3 > > Kernel Memory Usage > TEXT: 8950208 KiB, 8 MiB > DATA: 206347264 KiB, 196 MiB > TOTAL: 215297472 KiB, 205 MiB > Above did you really mean "8950208 B" not KiB, etc.? Matt From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 19:05:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2B38106568F for ; Tue, 16 Feb 2010 19:05:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 386888FC14 for ; Tue, 16 Feb 2010 19:05:19 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so465947fgg.13 for ; Tue, 16 Feb 2010 11:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/kwCWJw3/YaWwZp5cWeUmQBF5+YhPL0VfWCKSfmap/M=; b=Y2G3+LGN3nN0RUsNJNSbP1uRL5OYUGrkN+CYJt2S/HVBWaFbN3QhEtoHwOTFs8nwsW K7DqFfLqxm/fMME7G03UBuG03bKOM4FnmMXfq4pjig5N2grsraONqgOiTgwEKby25I74 uNkZZR2gRdG8OnKyIr6Rh2TPYsjHugLTCOuoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=D+ogHtX3CiMDlf3rzRKF1vfAmDii7/mH8wggmie2SM8pJQDbeU1cZ6+qHQmZkTpZho QtF/EhFkOPdCftrQvHdT6YFRQOTPahcuC+MRvqnPnNECx7oUx3PlDF3CaC9zKrj75CVw LEeHCwaEAt+Mgi/U8e4FtrQfTmXgZyWkbykiw= Received: by 10.87.5.15 with SMTP id h15mr12322354fgi.43.1266347119130; Tue, 16 Feb 2010 11:05:19 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm3684641fxm.6.2010.02.16.11.05.15 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 11:05:18 -0800 (PST) Sender: Alexander Motin Message-ID: <4B7AEC68.10901@FreeBSD.org> Date: Tue, 16 Feb 2010 21:05:12 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Langille References: <1265617382.00216602.1265605802@10.7.7.3> <1265707385.00217197.1265696404@10.7.7.3> <1265728980.00217271.1265715603@10.7.7.3> <1265750583.00217397.1265739002@10.7.7.3> <1265754184.00217418.1265743204@10.7.7.3> <1265756530.00217435.1265745602@10.7.7.3> <1265790181.00217606.1265778601@10.7.7.3> <1265842691.00217889.1265831404@10.7.7.3> <1265869381.00218054.1265857802@10.7.7.3> <1266013382.00218784.1266000003@10.7.7.3> In-Reply-To: <1266013382.00218784.1266000003@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bruce Simpson , freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:05:20 -0000 Dan Langille wrote: > On Wed, February 10, 2010 10:00 pm, Bruce Simpson wrote: >> On 02/10/10 19:40, Steve Polyack wrote: >>> I haven't had such bad experience as the above, but it is certainly a >>> concern. Using ZFS we simply 'offline' the device, pull, replace with >>> a new one, glabel, and zfs replace. It seems to work fine as long as >>> nothing is accessing the device you are replacing (otherwise you will >>> get a kernel panic a few minutes down the line). mav@FreeBSD.org has >>> also committed a large patch set to 9-CURRENT which implements >>> "proper" SATA/AHCI hot-plug support and error-recovery through CAM. >> I've been running with this patch in 8-STABLE for well over a week now >> on my desktop w/o issues; I am using main disk for dev, and eSATA disk >> pack for light multimedia use. > > MFC to 8.x? Merged. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 19:23:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5594C1065676; Tue, 16 Feb 2010 19:23:22 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 229A08FC18; Tue, 16 Feb 2010 19:23:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 6A8FB50830; Tue, 16 Feb 2010 19:23:21 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox8uK5Xh-ZXu; Tue, 16 Feb 2010 19:23:20 +0000 (GMT) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 299E550823; Tue, 16 Feb 2010 19:23:20 +0000 (GMT) Received: from 68.64.144.211 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Tue, 16 Feb 2010 14:23:20 -0500 Message-ID: <708394686f099826c05cbbf80dccb430.squirrel@nyi.unixathome.org> In-Reply-To: <4B7AEC68.10901@FreeBSD.org> References: <1265617382.00216602.1265605802@10.7.7.3> <1265707385.00217197.1265696404@10.7.7.3> <1265728980.00217271.1265715603@10.7.7.3> <1265750583.00217397.1265739002@10.7.7.3> <1265754184.00217418.1265743204@10.7.7.3> <1265756530.00217435.1265745602@10.7.7.3> <1265790181.00217606.1265778601@10.7.7.3> <1265842691.00217889.1265831404@10.7.7.3> <1265869381.00218054.1265857802@10.7.7.3> <1266013382.00218784.1266000003@10.7.7.3> <4B7AEC68.10901@FreeBSD.org> Date: Tue, 16 Feb 2010 14:23:20 -0500 From: "Dan Langille" To: "Alexander Motin" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Bruce Simpson , freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:23:22 -0000 On Tue, February 16, 2010 2:05 pm, Alexander Motin wrote: > Dan Langille wrote: >> On Wed, February 10, 2010 10:00 pm, Bruce Simpson wrote: >>> On 02/10/10 19:40, Steve Polyack wrote: >>>> I haven't had such bad experience as the above, but it is certainly a >>>> concern. Using ZFS we simply 'offline' the device, pull, replace with >>>> a new one, glabel, and zfs replace. It seems to work fine as long as >>>> nothing is accessing the device you are replacing (otherwise you will >>>> get a kernel panic a few minutes down the line). mav@FreeBSD.org has >>>> also committed a large patch set to 9-CURRENT which implements >>>> "proper" SATA/AHCI hot-plug support and error-recovery through CAM. >>> I've been running with this patch in 8-STABLE for well over a week now >>> on my desktop w/o issues; I am using main disk for dev, and eSATA disk >>> pack for light multimedia use. >> >> MFC to 8.x? > > Merged. Thank you. :) -- Dan Langille -- http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 19:47:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37E3F1065781 for ; Tue, 16 Feb 2010 19:47:11 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1393A8FC12 for ; Tue, 16 Feb 2010 19:47:10 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id E189A2BB341 for ; Tue, 16 Feb 2010 14:47:09 -0500 (EST) Date: Tue, 16 Feb 2010 14:47:08 -0500 From: "Peter C. Lai" To: freebsd-stable@freebsd.org Message-ID: <20100216194707.GQ4648@cesium.hyperfine.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: raidz/2 stripe widths X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:47:11 -0000 Which one might be "better" on pool that will consist of 6 disks: 6x raidz2 or 2 stripes of 3 disks in raidz? It should provide slightly less reliability (still allows for 2 disks to be off the array at a time) but the latter should improve reads since a given read only has to touch 3 spindles at a time instead of 5? -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 19:54:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9385106566B for ; Tue, 16 Feb 2010 19:54:01 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 58AA48FC0A for ; Tue, 16 Feb 2010 19:54:01 +0000 (UTC) Received: by mail-fx0-f226.google.com with SMTP id 26so6473808fxm.13 for ; Tue, 16 Feb 2010 11:54:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.187.209 with SMTP id m17mr744834hbh.148.1266350040487; Tue, 16 Feb 2010 11:54:00 -0800 (PST) In-Reply-To: <20100216194707.GQ4648@cesium.hyperfine.info> References: <20100216194707.GQ4648@cesium.hyperfine.info> From: Joshua Boyd Date: Tue, 16 Feb 2010 14:53:40 -0500 Message-ID: <33c6b0bc1002161153u7b341868o573e6c0080a6e316@mail.gmail.com> To: "Peter C. Lai" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: raidz/2 stripe widths X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:54:01 -0000 http://blogs.sun.com/ahl/entry/double_parity_raid_z Looks like raidz2 is recommended for better protection against failures than 2 stripes. On Tue, Feb 16, 2010 at 2:47 PM, Peter C. Lai wrote: > Which one might be "better" on pool that will consist of 6 disks: > > 6x raidz2 > > or > > 2 stripes of 3 disks in raidz? > > It should provide slightly less reliability (still allows for 2 disks to be > off the array at a time) but the latter should improve reads since a given > read only has to touch 3 spindles at a time instead of 5? > -- > =========================================================== > Peter C. Lai | Bard College at Simon's Rock > Systems Administrator | 84 Alford Rd. > Information Technology Svcs. | Gt. Barrington, MA 01230 USA > peter AT simons-rock.edu | (413) 528-7428 > =========================================================== > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 20:05:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1E91065672 for ; Tue, 16 Feb 2010 20:05:18 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id 890FB8FC08 for ; Tue, 16 Feb 2010 20:05:17 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1GK5D8c021797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Feb 2010 07:05:15 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1GK5Buc096238; Wed, 17 Feb 2010 07:05:12 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1GK5BN0096237; Wed, 17 Feb 2010 07:05:11 +1100 (EST) (envelope-from peter) Date: Wed, 17 Feb 2010 07:05:11 +1100 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20100216200511.GA95812@server.vk2pj.dyndns.org> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <20100216175946.GA98082@icarus.home.lan> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:05:18 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-16 09:59:46 -0800, Jeremy Chadwick w= rote: >On Tue, Feb 16, 2010 at 11:06:43AM -0600, Barry Pederson wrote: >> maybe something like this tacked on the end of the script (excuse my >> Perl, I'm a Python guy). >>=20 >> ---- >> #### Loader Settings ############# >> open(LOADER, '/boot/loader.conf'); >> print "\n/boot/loader.conf settings:\n"; >> while (){ >> chomp; >> if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){ >> print "\t$_\n"; >> } >> } >> ---- > >Major problems with the above code: > >1) Opens /boot/loader.conf for rw access; should be read-only Wrong. It opens /boot/loader.conf read-only, as it should. >2) Makes the assumption /boot/loader.conf exists Accepted but it was offered as a proof-of-concept. >3) Does not close the fd This is hardly a "major problem" in a short once-through script. >4) Excessively quotes variables for no justified reason If you mean including the $_ inside "", this is a standard perl idiom. >5) Makes some bad assumptions about the contents of the file (ex. > comments with the word "zfs" in them would match) Wrong. It only matches "zfs" as the first non-blank text on a line - which means it can't be a comment. So that's one real deficiency in a proof-of-concept script written by someone who does not claim to be comfortable with perl. >The code should really be something like what's below. This should >be much more manageable as well (@tunables that is), although I always >worry when using grep()... Whilst we are picking nits, your script has the following issues: - unnecessary trailing wildcard matches in the regexps - "grep" misused as "map" - "die" is probably not appropriate for embedding into another script - No useful error message if /boot/loader.conf can't be opened. - Doesn't correctly handle optional whitespace around "=3D" - No heading to explain what is being reported. - Doesn't allow for "zfs" as a top-level identifier Overall, Barry's script makes an excellent proof-of-concept - which is what he was offering. --=20 Peter Jeremy --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt6+ncACgkQ/opHv/APuIe16gCfWqYstXAOODj2df8aMU3Zjxar qrQAoIu2f6tpKPIuXzcH845+L1iUnJSF =uJH4 -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 20:24:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AF64106566B for ; Tue, 16 Feb 2010 20:24:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 56E848FC1D for ; Tue, 16 Feb 2010 20:24:22 +0000 (UTC) Received: by yxe2 with SMTP id 2so6633814yxe.7 for ; Tue, 16 Feb 2010 12:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=DJ5K2vdB9KmHREb913F1bcNf2gUfcS1N4hW8nGmiLzc=; b=yHVR8pHVlHNMhidCFUEb8RF4/iytiuXU1sj+AVCmBcXVyJEoOl/b7FWqI19a8B4iqF X2UnjcIcf9fJq6vJQvMYAm5tR/595ZaiFbLeJZeFjF24CROqKbkVD5ioHrkrx/JRYHEd jVVRlfwgK5vyvb4lk4kDHGneD7M57motyR37c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=P+lp7Wb7EkVga21J0qgG4mwRrRNEb9t162AE9loSqTF70jaLskoT+XIep4agq41X6V 0MVVdZ/Xb6U6BMM0fu2GT3ThksOzJlsfxLcM7rTQdTVItwWsMk3GSmsuwpQweE5NYd8H yPwpyf1evTgXNwmoJnKOPOkmNES4KDn1f+mx8= MIME-Version: 1.0 Received: by 10.231.144.66 with SMTP id y2mr2041078ibu.67.1266351861459; Tue, 16 Feb 2010 12:24:21 -0800 (PST) In-Reply-To: <20100216194707.GQ4648@cesium.hyperfine.info> References: <20100216194707.GQ4648@cesium.hyperfine.info> Date: Tue, 16 Feb 2010 12:24:21 -0800 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: raidz/2 stripe widths X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:24:22 -0000 On Tue, Feb 16, 2010 at 11:47 AM, Peter C. Lai wrote: > Which one might be "better" on pool that will consist of 6 disks: > > 6x raidz2 > or > 2 stripes of 3 disks in raidz? > > It should provide slightly less reliability (still allows for 2 disks to be > off the array at a time) but the latter should improve reads since a given > read only has to touch 3 spindles at a time instead of 5? > Depends. Do you want better reliability/redundancy (raidz2) or more throughput/IOPS (2x raidz1)? The max IOPS of a raidz vdev will be that of 1 disk. Thus, to get better IOPS, you have to have multiple raidz vdevs. The overly-simplistic way to look at is to think of the entire raidz vdev as a "single disk". Then it's an easy comparison: 1 disk is slower than 2 disks striped together. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 21:56:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63C351065672 for ; Tue, 16 Feb 2010 21:56:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 46AB58FC14 for ; Tue, 16 Feb 2010 21:56:38 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta13.emeryville.ca.mail.comcast.net with comcast id iibX1d0061Y3wxoADlwfed; Tue, 16 Feb 2010 21:56:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id ilwe1d00M3S48mS8blwe5J; Tue, 16 Feb 2010 21:56:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8087A1E301A; Tue, 16 Feb 2010 13:56:37 -0800 (PST) Date: Tue, 16 Feb 2010 13:56:37 -0800 From: Jeremy Chadwick To: Peter Jeremy Message-ID: <20100216215637.GA4299@icarus.home.lan> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> <20100216200511.GA95812@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100216200511.GA95812@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 21:56:39 -0000 On Wed, Feb 17, 2010 at 07:05:11AM +1100, Peter Jeremy wrote: > Overall, Barry's script makes an excellent proof-of-concept - which is > what he was offering. You know, I had a verbose in-line response typed up, agreeing with some points of yours and disagreeing with others (with perlfaq and other reference material), but decided... fuck it! :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 16 22:34:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7228F1065676 for ; Tue, 16 Feb 2010 22:34:38 +0000 (UTC) (envelope-from christian.schramm@parative.org) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id DB19D8FC14 for ; Tue, 16 Feb 2010 22:34:36 +0000 (UTC) Received: from p5ddabd8c.dip.t-dialin.net ([93.218.189.140] helo=[127.0.0.1]) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NhTfn-0007N4-BG for freebsd-stable@freebsd.org; Tue, 16 Feb 2010 21:05:36 +0100 Message-ID: <4B7AFA79.6060508@parative.org> Date: Tue, 16 Feb 2010 21:05:13 +0100 From: Christian Schramm User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> <201002131137.34812.npapke@acm.org> <1266096425.89452.30.camel@balrog.2hip.net> <20100215142305.3f0d7e65@miknet.dk> <1266249418.11131.7.camel@balrog.2hip.net> In-Reply-To: <1266249418.11131.7.camel@balrog.2hip.net> Content-Type: multipart/mixed; boundary="------------080008080901030604030004" X-Con-Id: 28398 X-Originating-IP: 93.218.189.140 Subject: blank X screen with differnt cards X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 22:34:38 -0000 This is a multi-part message in MIME format. --------------080008080901030604030004 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi at first this is my first message to a mailing list. Second sorry for my bad english. On Saturday i have installed 8-0-Release, after I build 8-stable include world an d kernel. After the build of stable I build some ports also xorg-minimal I press Xorg -configure and X -config /root/xorg.conf.new but my CRT Screen is blank. I can switch in tty0 an kill Xorg with CTRL-C. I have an GIGABYTE GA-MA78G-DSH3 with onboard Radeon 3200. I try a lot of drivers: vesa, radeon, ati, radeonhd but all the same: a blank screen. I have also an 7.2 release --> all works good Next I think it was a problem with the Radeon card i use a Nvidia 7600GT with Vesa but the same: a blank screen. Also i try with hal and dbus enable but no differences. What can i do? Christian I send you all information in attachment. --------------080008080901030604030004 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #0: Sun Feb 14 13:21:47 UTC 2010 root@:/usr/obj/usr/src/sys/GIANT-KERNEL amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3572543488 (3407 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, afde0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff irq 18 at device 5.0 on pci1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 pci1: at device 5.1 (no driver attached) pcib2: irq 18 at device 10.0 on pci0 pci2: on pcib2 re0: port 0xde00-0xdeff mem 0xfdaff000-0xfdafffff,0xfdae0000-0xfdaeffff irq 18 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:9d:62:e8 re0: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: port is not ready (timeout 0ms) tfd = 000001d0 ata3: software reset clear timeout ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] ehci0: AMD SB600/700 quirk applied usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: [ITHREAD] ehci1: AMD SB600/700 quirk applied usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: [ITHREAD] usbus6: on ohci4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 atrtc0: port 0x70-0x73 on acpi0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ad0: 152627MB at ata0-master UDMA100 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ad4: 953868MB at ata2-master UDMA100 SATA 3Gb/s ad6: 953868MB at ata3-master UDMA100 SATA 3Gb/s SMP: AP CPU #1 Launched! uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered Root mount waiting for: usbus5 usbus2 Root mount waiting for: usbus5 usbus2 Root mount waiting for: usbus5 usbus2 uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered Trying to mount root from zfs:giant re0: link state changed to UP --------------080008080901030604030004 Content-Type: text/plain; name="make.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="make.conf" # added by use.perl 2010-02-14 14:42:58 PERL_VERSION=5.10.1 WITHOUT_NOUVEAU=yes WITH_KDE_PHONON=yes --------------080008080901030604030004 Content-Type: text/plain; name="portlist.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="portlist.txt" ===>>> Root ports (No dependencies, not depended on) ===>>> bigreqsproto-1.0.2 ===>>> boost-jam-1.41.0 ===>>> cmake-2.8.0_2 ===>>> cvsup-without-gui-16.1h_4 ===>>> evieext-1.0.2 ===>>> ezm3-1.1_2 ===>>> glproto-1.4.10 ===>>> iw-hspell-1.0 ===>>> libssh-0.4.1 ===>>> libtool-2.2.6b ===>>> nasm-2.07,1 ===>>> openslp-1.2.1_3 ===>>> portmaster-2.19 ===>>> qt4-qmake-4.6.1 ===>>> qt4-rcc-4.6.1 ===>>> qt4-uic-4.6.1 ===>>> resourceproto-1.0.2 ===>>> unzip-6.0 ===>>> v4l_compat-1.0.20100113 ===>>> xcmiscproto-1.1.2 ===>>> xf86bigfontproto-1.1.2 ===>>> xf86driproto-2.0.4 ===>>> xorg-macros-1.2.1 ===>>> 23 root ports ===>>> Trunk ports (No dependencies, are depended on) ===>>> autoconf-wrapper-20071109 ===>>> automake-wrapper-20071109 ===>>> ca_root_nss-3.12.4 ===>>> cdparanoia-3.9.8_8 ===>>> clucene-0.9.21 ===>>> compositeproto-0.4 ===>>> cyrus-sasl-2.1.23 ===>>> damageproto-1.1.0_2 ===>>> db42-4.2.52_5 ===>>> dmidecode-2.10 ===>>> dmxproto-2.2.2 ===>>> dri2proto-2.1 ===>>> expat-2.0.1_1 ===>>> fixesproto-4.0 ===>>> font-util-1.0.1 ===>>> fontcacheproto-0.1.2 ===>>> fontsproto-2.0.2 ===>>> gdbm-1.8.3_3 ===>>> gnome_subr-1.0 ===>>> hicolor-icon-theme-0.12 ===>>> icu-3.8.1_2 ===>>> inputproto-1.5.0 ===>>> jbigkit-1.6 ===>>> jpeg-8 ===>>> kbproto-1.0.3 ===>>> kdehier4-1.0.4 ===>>> lcms-1.19_1,1 ===>>> libcheck-0.9.8 ===>>> libdaemon-0.12 ===>>> libdvdcss-1.2.10_1 ===>>> libexecinfo-1.1_3 ===>>> libfame-0.9.1_2 ===>>> libgmp-4.3.2 ===>>> libiconv-1.13.1_1 ===>>> libltdl-2.2.6b ===>>> libogg-1.1.4,4 ===>>> libsigsegv-2.5 ===>>> libutempter-1.1.5_1 ===>>> mDNSResponder-214 ===>>> mysql-client-5.0.89 ===>>> openldap-client-2.4.21 ===>>> pciids-20091229 ===>>> pcre-8.00 ===>>> perl-threaded-5.10.1 ===>>> pkg-config-0.23_1 ===>>> png-1.2.42 ===>>> printproto-1.0.4 ===>>> pth-2.0.7 ===>>> python26-2.6.4 ===>>> qt4-doc-4.6.1 ===>>> qt4-moc-4.6.1 ===>>> randrproto-1.3.0 ===>>> recordproto-1.13.2 ===>>> renderproto-0.9.3 ===>>> scrnsaverproto-1.1.0 ===>>> sqlite3-3.6.19 ===>>> talloc-2.0.1 ===>>> tcl-modules-8.5.8 ===>>> videoproto-2.2.2 ===>>> xdg-utils-1.0.2_4 ===>>> xextproto-7.0.5 ===>>> xf86dgaproto-2.0.3 ===>>> xf86miscproto-0.9.2 ===>>> xf86vidmodeproto-2.2.2 ===>>> xineramaproto-1.1.2 ===>>> xmlcatmgr-2.2 ===>>> xz-4.999.9_1 ===>>> 67 trunk ports ===>>> Branch ports (Have dependencies, are depended on) ===>>> OpenEXR-1.6.1_2 ===>>> aalib-1.4.r5_4 ===>>> akonadi-1.3.1 ===>>> apr-ipv6-gdbm-db42-1.3.9.1.3.9_1 ===>>> aspell-0.60.6_2 ===>>> attica-0.1.2 ===>>> autoconf-2.62 ===>>> avahi-app-0.6.25_2 ===>>> bison-2.4.1,1 ===>>> boost-libs-1.41.0 ===>>> boost-python-libs-1.41.0 ===>>> consolekit-0.4.1_2 ===>>> curl-7.19.7_1 ===>>> dbus-1.2.16_1 ===>>> dbus-glib-0.84 ===>>> docbook-1.4 ===>>> docbook-4.1_4 ===>>> docbook-4.2 ===>>> docbook-4.3 ===>>> docbook-4.4_2 ===>>> docbook-4.5_2 ===>>> docbook-5.0_1 ===>>> docbook-sk-4.1.2_4 ===>>> docbook-xml-4.2_1 ===>>> docbook-xml-4.3 ===>>> docbook-xml-4.4_1 ===>>> docbook-xml-4.5 ===>>> dri-7.6.1,2 ===>>> eggdbus-0.6 ===>>> enchant-1.4.2 ===>>> exiv2-0.18_1,1 ===>>> flac-1.2.1_1 ===>>> font-alias-1.0.1 ===>>> font-cursor-misc-1.0.0 ===>>> font-misc-misc-1.0.0 ===>>> fontconfig-2.8.0,1 ===>>> freetype2-2.3.11 ===>>> gamin-0.1.10_3 ===>>> gettext-0.17_1 ===>>> gio-fam-backend-2.22.4 ===>>> glib-1.2.10_13 ===>>> glib-2.22.4 ===>>> gnupg-2.0.14 ===>>> gobject-introspection-0.6.7 ===>>> gpgme-1.2.0_2 ===>>> gstreamer-0.10.26 ===>>> gstreamer-plugins-0.10.25_1,3 ===>>> gtk-1.2.10_21 ===>>> hal-0.5.13_14 ===>>> iceauth-1.0.2 ===>>> ilmbase-1.0.1_1 ===>>> iso8879-1986_2 ===>>> jasper-1.900.1_9 ===>>> kde4-icons-oxygen-4.4.0 ===>>> kde4-shared-mime-info-1.0 ===>>> kdelibs-4.4.0 ===>>> libFS-1.0.1 ===>>> libGL-7.6.1 ===>>> libGLU-7.6.1 ===>>> libICE-1.0.4_1,1 ===>>> libSM-1.1.0_1,1 ===>>> libX11-1.2.1_1,1 ===>>> libXScrnSaver-1.1.3 ===>>> libXTrap-1.0.0 ===>>> libXau-1.0.4 ===>>> libXaw-1.0.5_1,1 ===>>> libXcomposite-0.4.0,1 ===>>> libXcursor-1.1.9_1 ===>>> libXdamage-1.1.1 ===>>> libXdmcp-1.0.2_1 ===>>> libXevie-1.0.2 ===>>> libXext-1.0.5,1 ===>>> libXfixes-4.0.3_1 ===>>> libXfont-1.3.4,1 ===>>> libXfontcache-1.0.4 ===>>> libXft-2.1.14 ===>>> libXi-1.2.1,1 ===>>> libXinerama-1.0.3,1 ===>>> libXmu-1.0.4,1 ===>>> libXp-1.0.0,1 ===>>> libXpm-3.5.7 ===>>> libXrandr-1.3.0 ===>>> libXrender-0.9.4_1 ===>>> libXres-1.0.3_3 ===>>> libXt-1.0.5_1 ===>>> libXtst-1.0.3_1 ===>>> libXv-1.0.4,1 ===>>> libXvMC-1.0.4_1 ===>>> libXxf86dga-1.0.2 ===>>> libXxf86misc-1.0.1 ===>>> libXxf86vm-1.0.2 ===>>> libcddb-1.3.1 ===>>> libcdio-0.82_1 ===>>> libdca-0.0.5 ===>>> libdmx-1.0.2_1 ===>>> libdrm-2.4.17 ===>>> libdvdread-4.1.3_2 ===>>> libffi-3.0.9 ===>>> libfontenc-1.0.4 ===>>> libgcrypt-1.4.4 ===>>> libgpg-error-1.7 ===>>> libical-0.43_1 ===>>> libidn-1.15 ===>>> libiodbc-3.52.7 ===>>> libksba-1.0.7 ===>>> libmad-0.15.1b_2 ===>>> libmng-1.0.10_2 ===>>> libmodplug-0.8.7 ===>>> liboil-0.3.16 ===>>> liboldX-1.0.1 ===>>> libpciaccess-0.10.6_1 ===>>> libpthread-stubs-0.3_3 ===>>> libtheora-1.1.1_1 ===>>> libungif-4.1.4_5 ===>>> libvolume_id-0.81.1 ===>>> libvorbis-1.2.3_1,3 ===>>> libxcb-1.5 ===>>> libxkbfile-1.0.5 ===>>> libxkbui-1.0.2_1 ===>>> libxml2-2.7.6_1 ===>>> libxslt-1.1.26 ===>>> m4-1.4.13,1 ===>>> mkfontdir-1.0.4 ===>>> mkfontscale-1.0.6 ===>>> mpfr-2.4.2 ===>>> mysql-server-5.0.89 ===>>> neon29-0.29.3 ===>>> p5-XML-Parser-2.36_1 ===>>> p5-gettext-1.05_2 ===>>> pixman-0.16.6 ===>>> policykit-0.9_6 ===>>> policykit-qt-0.9.3 ===>>> polkit-0.96_1 ===>>> popt-1.14 ===>>> py26-elementtree-1.2.6_1 ===>>> qca-2.0.2 ===>>> qimageblitz-0.0.4_3 ===>>> qt4-assistant-4.6.1 ===>>> qt4-clucene-4.6.1 ===>>> qt4-corelib-4.6.1 ===>>> qt4-dbus-4.6.1 ===>>> qt4-designer-4.6.1 ===>>> qt4-gui-4.6.1 ===>>> qt4-help-4.6.1 ===>>> qt4-imageformats-4.6.1_1 ===>>> qt4-makeqpf-4.6.1 ===>>> qt4-mysql-plugin-4.6.1 ===>>> qt4-network-4.6.1 ===>>> qt4-opengl-4.6.1 ===>>> qt4-phonon-4.6.1 ===>>> This port is marked IGNORE ===>>> conflicts with multimedia/phonon. You have defined WITH_KDE_PHONON to override Qt4 phonon ===>>> qt4-phonon-gst-4.6.1 ===>>> This port is marked IGNORE ===>>> conflicts with multimedia/phonon-gstreamer. You have defined WITH_KDE_PHONON to override Qt4 phonon ===>>> qt4-qdbusviewer-4.6.1 ===>>> qt4-qt3support-4.6.1 ===>>> qt4-qtestlib-4.6.1 ===>>> qt4-script-4.6.1 ===>>> qt4-scripttools-4.6.1 ===>>> qt4-sql-4.6.1 ===>>> qt4-sqlite-plugin-4.6.1 ===>>> qt4-svg-4.6.1 ===>>> qt4-webkit-4.6.1 ===>>> qt4-xml-4.6.1 ===>>> qt4-xmlpatterns-4.6.1 ===>>> raptor-1.4.21 ===>>> rasqal-0.9.17 ===>>> redland-1.0.10 ===>>> rgb-1.0.1 ===>>> samba34-libsmbclient-3.4.5 ===>>> sdl-1.2.14_1,2 ===>>> shared-desktop-ontologies-0.2 ===>>> shared-mime-info-0.71 ===>>> soprano-2.4.0.1 ===>>> speex-1.2.r1_2,1 ===>>> strigi-0.7.2 ===>>> tiff-3.9.2_1 ===>>> trapproto-3.4.3 ===>>> vcdimager-0.7.23_6 ===>>> wavpack-4.50.1 ===>>> xauth-1.0.3 ===>>> xf86-input-keyboard-1.3.2_3 ===>>> xf86-input-mouse-1.4.0_7 ===>>> xf86-video-vesa-2.1.0_3 ===>>> xinit-1.1.1_1 ===>>> xkeyboard-config-1.6_1 ===>>> xmlcharent-0.3_2 ===>>> xorg-libraries-7.4 ===>>> xorg-server-1.6.5_1,1 ===>>> xproto-7.0.15 ===>>> xtrans-1.2.3 ===>>> 188 branch ports ===>>> Leaf ports (Have dependencies, not depended on) ===>>> automake-1.10.1 ===>>> automake-1.9.6_3 ===>>> automoc4-0.9.88_1 ===>>> bash-4.0.35 ===>>> bdftopcf-1.0.1 ===>>> docbook-xsl-1.75.2 ===>>> flex-2.5.35_3 ===>>> gmake-3.81_3 ===>>> help2man-1.37.1 ===>>> intltool-0.40.6 ===>>> kdebase-4.4.0 ===>>> kdepimlibs-4.4.0 ===>>> libassuan-1.0.5 ===>>> libxine-1.1.16.3_3 ===>>> makedepend-1.0.1,1 ===>>> subversion-1.6.9 ===>>> tcl-8.5.8 ===>>> vim6-6.4.9_1 ===>>> xcb-proto-1.6 ===>>> xf86-video-ati-6.12.4_1 ===>>> xf86-video-radeonhd-1.3.0_1 ===>>> xkbcomp-1.0.5 ===>>> xorg-minimal-7.4_4 ===>>> 23 leaf ports ===>>> 301 total installed ports ===>>> There are no new versions available --------------080008080901030604030004 Content-Type: text/plain; name="src.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="src.conf" LOADER_ZFS_SUPPORT="YES" WITHOUT_ATM="YES" WITHOUT_BLUETHOOTH="YES" WITHOUT_DICT="YES" WITHOUT_GAMES="YES" WITHOUT_IPX="YES" --------------080008080901030604030004 Content-Type: text/plain; name="uname.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="uname.txt" FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #0: Sun Feb 14 13:21:47 UTC 2010 root@:/usr/obj/usr/src/sys/GIANT-KERNEL amd64 --------------080008080901030604030004 Content-Type: text/plain; name="Xorg.aticard.radeondriver.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Xorg.aticard.radeondriver.txt" ClguT3JnIFggU2VydmVyIDEuNi41ClJlbGVhc2UgRGF0ZTogMjAwOS0xMC0xMQpYIFByb3Rv Y29sIFZlcnNpb24gMTEsIFJldmlzaW9uIDAKQnVpbGQgT3BlcmF0aW5nIFN5c3RlbTogRnJl ZUJTRCA4LjAtU1RBQkxFIGFtZDY0IApDdXJyZW50IE9wZXJhdGluZyBTeXN0ZW06IEZyZWVC U0QgIDguMC1TVEFCTEUgRnJlZUJTRCA4LjAtU1RBQkxFICMwOiBUdWUgRmViIDE2IDE5OjI4 OjQ4IFVUQyAyMDEwICAgICByb290QDovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDIGFt ZDY0CkJ1aWxkIERhdGU6IDE0IEZlYnJ1YXJ5IDIwMTAgIDAzOjM1OjQ0UE0KIAoJQmVmb3Jl IHJlcG9ydGluZyBwcm9ibGVtcywgY2hlY2sgaHR0cDovL3dpa2kueC5vcmcKCXRvIG1ha2Ug c3VyZSB0aGF0IHlvdSBoYXZlIHRoZSBsYXRlc3QgdmVyc2lvbi4KTWFya2VyczogKC0tKSBw cm9iZWQsICgqKikgZnJvbSBjb25maWcgZmlsZSwgKD09KSBkZWZhdWx0IHNldHRpbmcsCgko KyspIGZyb20gY29tbWFuZCBsaW5lLCAoISEpIG5vdGljZSwgKElJKSBpbmZvcm1hdGlvbmFs LAoJKFdXKSB3YXJuaW5nLCAoRUUpIGVycm9yLCAoTkkpIG5vdCBpbXBsZW1lbnRlZCwgKD8/ KSB1bmtub3duLgooPT0pIExvZyBmaWxlOiAiL3Zhci9sb2cvWG9yZy4wLmxvZyIsIFRpbWU6 IFR1ZSBGZWIgMTYgMTk6NTc6MjUgMjAxMAooKyspIFVzaW5nIGNvbmZpZyBmaWxlOiAiL3Jv b3QveG9yZy5jb25mLm5ldyIKKD09KSBTZXJ2ZXJMYXlvdXQgIlgub3JnIENvbmZpZ3VyZWQi CigqKikgfC0tPlNjcmVlbiAiU2NyZWVuMCIgKDApCigqKikgfCAgIHwtLT5Nb25pdG9yICJN b25pdG9yMCIKKCoqKSB8ICAgfC0tPkRldmljZSAiQ2FyZDAiCigqKikgfC0tPklucHV0IERl dmljZSAiTW91c2UwIgooKiopIHwtLT5JbnB1dCBEZXZpY2UgIktleWJvYXJkMCIKKD09KSBB dXRvbWF0aWNhbGx5IGFkZGluZyBkZXZpY2VzCig9PSkgQXV0b21hdGljYWxseSBlbmFibGlu ZyBkZXZpY2VzCihXVykgVGhlIGRpcmVjdG9yeSAiL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRz L1R5cGUxLyIgZG9lcyBub3QgZXhpc3QuCglFbnRyeSBkZWxldGVkIGZyb20gZm9udCBwYXRo LgooV1cpIGBmb250cy5kaXInIG5vdCBmb3VuZCAob3Igbm90IHZhbGlkKSBpbiAiL3Vzci9s b2NhbC9saWIvWDExL2ZvbnRzLzEwMGRwaS8iLgoJRW50cnkgZGVsZXRlZCBmcm9tIGZvbnQg cGF0aC4KCShSdW4gJ21rZm9udGRpcicgb24gIi91c3IvbG9jYWwvbGliL1gxMS9mb250cy8x MDBkcGkvIikuCihXVykgYGZvbnRzLmRpcicgbm90IGZvdW5kIChvciBub3QgdmFsaWQpIGlu ICIvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvIi4KCUVudHJ5IGRlbGV0ZWQgZnJv bSBmb250IHBhdGguCgkoUnVuICdta2ZvbnRkaXInIG9uICIvdXNyL2xvY2FsL2xpYi9YMTEv Zm9udHMvNzVkcGkvIikuCihXVykgVGhlIGRpcmVjdG9yeSAiL3Vzci9sb2NhbC9saWIvWDEx L2ZvbnRzL1R5cGUxLyIgZG9lcyBub3QgZXhpc3QuCglFbnRyeSBkZWxldGVkIGZyb20gZm9u dCBwYXRoLgooV1cpIGBmb250cy5kaXInIG5vdCBmb3VuZCAob3Igbm90IHZhbGlkKSBpbiAi L3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzLzEwMGRwaS8iLgoJRW50cnkgZGVsZXRlZCBmcm9t IGZvbnQgcGF0aC4KCShSdW4gJ21rZm9udGRpcicgb24gIi91c3IvbG9jYWwvbGliL1gxMS9m b250cy8xMDBkcGkvIikuCihXVykgYGZvbnRzLmRpcicgbm90IGZvdW5kIChvciBub3QgdmFs aWQpIGluICIvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvIi4KCUVudHJ5IGRlbGV0 ZWQgZnJvbSBmb250IHBhdGguCgkoUnVuICdta2ZvbnRkaXInIG9uICIvdXNyL2xvY2FsL2xp Yi9YMTEvZm9udHMvNzVkcGkvIikuCigqKikgRm9udFBhdGggc2V0IHRvOgoJL3Vzci9sb2Nh bC9saWIvWDExL2ZvbnRzL21pc2MvLAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL1RURi8s CgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvT1RGLAoJL3Vzci9sb2NhbC9saWIvWDExL2Zv bnRzL21pc2MvLAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL1RURi8sCgkvdXNyL2xvY2Fs L2xpYi9YMTEvZm9udHMvT1RGCigqKikgTW9kdWxlUGF0aCBzZXQgdG8gIi91c3IvbG9jYWwv bGliL3hvcmcvbW9kdWxlcyIKKFdXKSBBbGxvd0VtcHR5SW5wdXQgaXMgb24sIGRldmljZXMg dXNpbmcgZHJpdmVycyAna2JkJywgJ21vdXNlJyBvciAndm1tb3VzZScgd2lsbCBiZSBkaXNh YmxlZC4KKFdXKSBEaXNhYmxpbmcgTW91c2UwCihXVykgRGlzYWJsaW5nIEtleWJvYXJkMAoo SUkpIExvYWRlciBtYWdpYzogMHgzNTYwCihJSSkgTW9kdWxlIEFCSSB2ZXJzaW9uczoKCVgu T3JnIEFOU0kgQyBFbXVsYXRpb246IDAuNAoJWC5PcmcgVmlkZW8gRHJpdmVyOiA1LjAKCVgu T3JnIFhJbnB1dCBkcml2ZXIgOiA0LjAKCVguT3JnIFNlcnZlciBFeHRlbnNpb24gOiAyLjAK KElJKSBMb2FkZXIgcnVubmluZyBvbiBmcmVlYnNkCigtLSkgVXNpbmcgc3lzY29ucyBkcml2 ZXIgd2l0aCBYIHN1cHBvcnQgKHZlcnNpb24gMi4wKQooLS0pIHVzaW5nIFZUIG51bWJlciA5 CgooLS0pIFBDSToqKDA6MTo1OjApIDEwMDI6OTYxMDoxNDU4OmQwMDAgQVRJIFRlY2hub2xv Z2llcyBJbmMgUmFkZW9uIEhEIDMyMDAgR3JhcGhpY3MgcmV2IDAsIE1lbSBAIDB4ZDAwMDAw MDAvMjY4NDM1NDU2LCAweGZkZmUwMDAwLzY1NTM2LCAweGZkZTAwMDAwLzEwNDg1NzYsIEkv TyBAIDB4MDAwMGVlMDAvMjU2LCBCSU9TIEAgMHg/Pz8/Pz8/Py82NTUzNgooSUkpIFN5c3Rl bSByZXNvdXJjZSByYW5nZXM6CglbMF0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBmZmZmZiAo MHgxMDAwMCkgTVhbQl0KCVsxXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMw MDAwKSBNWFtCXQoJWzJdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDAp IE1YW0JdCglbM10gLTEJMAkweDAwMDBmZmZmIC0gMHgwMDAwZmZmZiAoMHgxKSBJWFtCXQoJ WzRdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwZmYgKDB4MTAwKSBJWFtCXQooSUkpICJl eHRtb2QiIHdpbGwgYmUgbG9hZGVkLiBUaGlzIHdhcyBlbmFibGVkIGJ5IGRlZmF1bHQgYW5k IGFsc28gc3BlY2lmaWVkIGluIHRoZSBjb25maWcgZmlsZS4KKElJKSAiZGJlIiB3aWxsIGJl IGxvYWRlZC4gVGhpcyB3YXMgZW5hYmxlZCBieSBkZWZhdWx0IGFuZCBhbHNvIHNwZWNpZmll ZCBpbiB0aGUgY29uZmlnIGZpbGUuCihJSSkgImdseCIgd2lsbCBiZSBsb2FkZWQuIFRoaXMg d2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBhbmQgYWxzbyBzcGVjaWZpZWQgaW4gdGhlIGNvbmZp ZyBmaWxlLgooSUkpICJyZWNvcmQiIHdpbGwgYmUgbG9hZGVkLiBUaGlzIHdhcyBlbmFibGVk IGJ5IGRlZmF1bHQgYW5kIGFsc28gc3BlY2lmaWVkIGluIHRoZSBjb25maWcgZmlsZS4KKElJ KSAiZHJpIiB3aWxsIGJlIGxvYWRlZC4gVGhpcyB3YXMgZW5hYmxlZCBieSBkZWZhdWx0IGFu ZCBhbHNvIHNwZWNpZmllZCBpbiB0aGUgY29uZmlnIGZpbGUuCihJSSkgImRyaTIiIHdpbGwg YmUgbG9hZGVkLiBUaGlzIHdhcyBlbmFibGVkIGJ5IGRlZmF1bHQgYW5kIGFsc28gc3BlY2lm aWVkIGluIHRoZSBjb25maWcgZmlsZS4KKElJKSBMb2FkTW9kdWxlOiAiZXh0bW9kIgooSUkp IExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2V4dGVuc2lvbnMvL2xpYmV4 dG1vZC5zbwooSUkpIE1vZHVsZSBleHRtb2Q6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIK CWNvbXBpbGVkIGZvciAxLjYuNSwgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJTW9kdWxlIGNs YXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uCglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBF eHRlbnNpb24sIHZlcnNpb24gMi4wCihJSSkgTG9hZGluZyBleHRlbnNpb24gTUlULVNDUkVF Ti1TQVZFUgooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhGcmVlODYtVmlkTW9kZUV4dGVuc2lv bgooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhGcmVlODYtREdBCihJSSkgTG9hZGluZyBleHRl bnNpb24gRFBNUwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhWaWRlbwooSUkpIExvYWRpbmcg ZXh0ZW5zaW9uIFhWaWRlby1Nb3Rpb25Db21wZW5zYXRpb24KKElJKSBMb2FkaW5nIGV4dGVu c2lvbiBYLVJlc291cmNlCihJSSkgTG9hZE1vZHVsZTogImRyaTIiCihJSSkgTG9hZGluZyAv dXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8vbGliZHJpMi5zbwooSUkp IE1vZHVsZSBkcmkyOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3Ig MS42LjUsIG1vZHVsZSB2ZXJzaW9uID0gMS4xLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVy IEV4dGVuc2lvbiwgdmVyc2lvbiAyLjAKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBEUkkyCihJ SSkgTG9hZE1vZHVsZTogImdseCIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcv bW9kdWxlcy9leHRlbnNpb25zLy9saWJnbHguc28KKElJKSBNb2R1bGUgZ2x4OiB2ZW5kb3I9 IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS42LjUsIG1vZHVsZSB2ZXJzaW9u ID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVyc2lvbiAy LjAKKD09KSBBSUdMWCBkaXNhYmxlZAooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIEdMWAooSUkp IExvYWRNb2R1bGU6ICJkYmUiCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21v ZHVsZXMvZXh0ZW5zaW9ucy8vbGliZGJlLnNvCihJSSkgTW9kdWxlIGRiZTogdmVuZG9yPSJY Lk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNi41LCBtb2R1bGUgdmVyc2lvbiA9 IDEuMC4wCglNb2R1bGUgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFz czogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVyc2lvbiAyLjAKKElJKSBMb2FkaW5nIGV4 dGVuc2lvbiBET1VCTEUtQlVGRkVSCihJSSkgTG9hZE1vZHVsZTogImRyaSIKKElJKSBMb2Fk aW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9saWJkcmkuc28K KElJKSBNb2R1bGUgZHJpOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBm b3IgMS42LjUsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2Vy dmVyIEV4dGVuc2lvbiwgdmVyc2lvbiAyLjAKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYRnJl ZTg2LURSSQooSUkpIExvYWRNb2R1bGU6ICJyZWNvcmQiCihJSSkgTG9hZGluZyAvdXNyL2xv Y2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8vbGlicmVjb3JkLnNvCihJSSkgTW9k dWxlIHJlY29yZDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEu Ni41LCBtb2R1bGUgdmVyc2lvbiA9IDEuMTMuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2 ZXIgRXh0ZW5zaW9uCglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNp b24gMi4wCihJSSkgTG9hZGluZyBleHRlbnNpb24gUkVDT1JECihJSSkgTG9hZE1vZHVsZTog InJhZGVvbiIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9kcml2 ZXJzLy9yYWRlb25fZHJ2LnNvCihJSSkgTW9kdWxlIHJhZGVvbjogdmVuZG9yPSJYLk9yZyBG b3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNi41LCBtb2R1bGUgdmVyc2lvbiA9IDYuMTIu NAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIKCUFCSSBjbGFzczogWC5Pcmcg VmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDUuMAooSUkpIFJBREVPTjogRHJpdmVyIGZvciBBVEkg UmFkZW9uIGNoaXBzZXRzOgoJQVRJIFJhZGVvbiBNb2JpbGl0eSBYNjAwIChNMjQpIDMxNTAg KFBDSUUpLCBBVEkgRmlyZU1WIDI0MDAgKFBDSSksCglBVEkgUmFkZW9uIE1vYmlsaXR5IFgz MDAgKE0yNCkgMzE1MiAoUENJRSksCglBVEkgRmlyZUdMIE0yNCBHTCAzMTU0IChQQ0lFKSwg QVRJIFJhZGVvbiBYNjAwIChSVjM4MCkgM0U1MCAoUENJRSksCglBVEkgRmlyZUdMIFYzMjAw IChSVjM4MCkgM0U1NCAoUENJRSksIEFUSSBSYWRlb24gSUdQMzIwIChBMykgNDEzNiwKCUFU SSBSYWRlb24gSUdQMzMwLzM0MC8zNTAgKEE0KSA0MTM3LCBBVEkgUmFkZW9uIDk1MDAgQUQg KEFHUCksCglBVEkgUmFkZW9uIDk1MDAgQUUgKEFHUCksIEFUSSBSYWRlb24gOTYwMFRYIEFG IChBR1ApLAoJQVRJIEZpcmVHTCBaMSBBRyAoQUdQKSwgQVRJIFJhZGVvbiA5ODAwU0UgQUgg KEFHUCksCglBVEkgUmFkZW9uIDk4MDAgQUkgKEFHUCksIEFUSSBSYWRlb24gOTgwMCBBSiAo QUdQKSwKCUFUSSBGaXJlR0wgWDIgQUsgKEFHUCksIEFUSSBSYWRlb24gOTYwMCBBUCAoQUdQ KSwKCUFUSSBSYWRlb24gOTYwMFNFIEFRIChBR1ApLCBBVEkgUmFkZW9uIDk2MDBYVCBBUiAo QUdQKSwKCUFUSSBSYWRlb24gOTYwMCBBUyAoQUdQKSwgQVRJIEZpcmVHTCBUMiBBVCAoQUdQ KSwgQVRJIFJhZGVvbiA5NjUwLAoJQVRJIEZpcmVHTCBSVjM2MCBBViAoQUdQKSwgQVRJIFJh ZGVvbiA3MDAwIElHUCAoQTQrKSA0MjM3LAoJQVRJIFJhZGVvbiA4NTAwIEFJVyBCQiAoQUdQ KSwgQVRJIFJhZGVvbiA4NTAwIEFJVyBCQyAoQUdQKSwKCUFUSSBSYWRlb24gSUdQMzIwTSAo VTEpIDQzMzYsIEFUSSBSYWRlb24gSUdQMzMwTS8zNDBNLzM1ME0gKFUyKSA0MzM3LAoJQVRJ IFJhZGVvbiBNb2JpbGl0eSA3MDAwIElHUCA0NDM3LCBBVEkgUmFkZW9uIDkwMDAvUFJPIElm IChBR1AvUENJKSwKCUFUSSBSYWRlb24gOTAwMCBJZyAoQUdQL1BDSSksIEFUSSBSYWRlb24g WDgwMCAoUjQyMCkgSkggKEFHUCksCglBVEkgUmFkZW9uIFg4MDBQUk8gKFI0MjApIEpJIChB R1ApLAoJQVRJIFJhZGVvbiBYODAwU0UgKFI0MjApIEpKIChBR1ApLCBBVEkgUmFkZW9uIFg4 MDAgKFI0MjApIEpLIChBR1ApLAoJQVRJIFJhZGVvbiBYODAwIChSNDIwKSBKTCAoQUdQKSwg QVRJIEZpcmVHTCBYMyAoUjQyMCkgSk0gKEFHUCksCglBVEkgUmFkZW9uIE1vYmlsaXR5IDk4 MDAgKE0xOCkgSk4gKEFHUCksCglBVEkgUmFkZW9uIFg4MDAgU0UgKFI0MjApIChBR1ApLCBB VEkgUmFkZW9uIFg4MDBYVCAoUjQyMCkgSlAgKEFHUCksCglBVEkgUmFkZW9uIFg4MDAgVkUg KFI0MjApIEpUIChBR1ApLCBBVEkgUmFkZW9uIFg4NTAgKFI0ODApIChBR1ApLAoJQVRJIFJh ZGVvbiBYODUwIFhUIChSNDgwKSAoQUdQKSwgQVRJIFJhZGVvbiBYODUwIFNFIChSNDgwKSAo QUdQKSwKCUFUSSBSYWRlb24gWDg1MCBQUk8gKFI0ODApIChBR1ApLCBBVEkgUmFkZW9uIFg4 NTAgWFQgUEUgKFI0ODApIChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSBNNyBMVyAoQUdQ KSwKCUFUSSBNb2JpbGl0eSBGaXJlR0wgNzgwMCBNNyBMWCAoQUdQKSwKCUFUSSBSYWRlb24g TW9iaWxpdHkgTTYgTFkgKEFHUCksIEFUSSBSYWRlb24gTW9iaWxpdHkgTTYgTFogKEFHUCks CglBVEkgRmlyZUdMIE1vYmlsaXR5IDkwMDAgKE05KSBMZCAoQUdQKSwKCUFUSSBSYWRlb24g TW9iaWxpdHkgOTAwMCAoTTkpIExmIChBR1ApLAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5MDAw IChNOSkgTGcgKEFHUCksIEFUSSBSYWRlb24gOTcwMCBQcm8gTkQgKEFHUCksCglBVEkgUmFk ZW9uIDk3MDAvOTUwMFBybyBORSAoQUdQKSwgQVRJIFJhZGVvbiA5NjAwVFggTkYgKEFHUCks CglBVEkgRmlyZUdMIFgxIE5HIChBR1ApLCBBVEkgUmFkZW9uIDk4MDBQUk8gTkggKEFHUCks CglBVEkgUmFkZW9uIDk4MDAgTkkgKEFHUCksIEFUSSBGaXJlR0wgWDIgTksgKEFHUCksCglB VEkgUmFkZW9uIDk4MDBYVCBOSiAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTYwMC85 NzAwIChNMTAvTTExKSBOUCAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTYwMCAoTTEw KSBOUSAoQUdQKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTYwMCAoTTExKSBOUiAoQUdQKSwK CUFUSSBSYWRlb24gTW9iaWxpdHkgOTYwMCAoTTEwKSBOUyAoQUdQKSwKCUFUSSBGaXJlR0wg TW9iaWxpdHkgVDIgKE0xMCkgTlQgKEFHUCksCglBVEkgRmlyZUdMIE1vYmlsaXR5IFQyZSAo TTExKSBOViAoQUdQKSwgQVRJIFJhZGVvbiBRRCAoQUdQKSwKCUFUSSBSYWRlb24gUUUgKEFH UCksIEFUSSBSYWRlb24gUUYgKEFHUCksIEFUSSBSYWRlb24gUUcgKEFHUCksCglBVEkgRmly ZUdMIDg3MDAvODgwMCBRSCAoQUdQKSwgQVRJIFJhZGVvbiA4NTAwIFFMIChBR1ApLAoJQVRJ IFJhZGVvbiA5MTAwIFFNIChBR1ApLCBBVEkgUmFkZW9uIDc1MDAgUVcgKEFHUC9QQ0kpLAoJ QVRJIFJhZGVvbiA3NTAwIFFYIChBR1AvUENJKSwgQVRJIFJhZGVvbiBWRS83MDAwIFFZIChB R1AvUENJKSwKCUFUSSBSYWRlb24gVkUvNzAwMCBRWiAoQUdQL1BDSSksIEFUSSBFUzEwMDAg NTE1RSAoUENJKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgWDMwMCAoTTIyKSA1NDYwIChQQ0lF KSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgWDYwMCBTRSAoTTI0QykgNTQ2MiAoUENJRSksCglB VEkgRmlyZUdMIE0yMiBHTCA1NDY0IChQQ0lFKSwgQVRJIFJhZGVvbiBYODAwIChSNDIzKSBV SCAoUENJRSksCglBVEkgUmFkZW9uIFg4MDBQUk8gKFI0MjMpIFVJIChQQ0lFKSwKCUFUSSBS YWRlb24gWDgwMExFIChSNDIzKSBVSiAoUENJRSksCglBVEkgUmFkZW9uIFg4MDBTRSAoUjQy MykgVUsgKFBDSUUpLAoJQVRJIFJhZGVvbiBYODAwIFhUUCAoUjQzMCkgKFBDSUUpLCBBVEkg UmFkZW9uIFg4MDAgWEwgKFI0MzApIChQQ0lFKSwKCUFUSSBSYWRlb24gWDgwMCBTRSAoUjQz MCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg4MDAgKFI0MzApIChQQ0lFKSwKCUFUSSBGaXJlR0wg VjcxMDAgKFI0MjMpIChQQ0lFKSwgQVRJIEZpcmVHTCBWNTEwMCAoUjQyMykgVVEgKFBDSUUp LAoJQVRJIEZpcmVHTCB1bmtub3duIChSNDIzKSBVUiAoUENJRSksCglBVEkgRmlyZUdMIHVu a25vd24gKFI0MjMpIFVUIChQQ0lFKSwKCUFUSSBNb2JpbGl0eSBGaXJlR0wgVjUwMDAgKE0y NikgKFBDSUUpLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBWNTAwMCAoTTI2KSAoUENJRSksCglB VEkgTW9iaWxpdHkgUmFkZW9uIFg3MDAgWEwgKE0yNikgKFBDSUUpLAoJQVRJIE1vYmlsaXR5 IFJhZGVvbiBYNzAwIChNMjYpIChQQ0lFKSwKCUFUSSBNb2JpbGl0eSBSYWRlb24gWDcwMCAo TTI2KSAoUENJRSksCglBVEkgUmFkZW9uIFg1NTBYVFggNTY1NyAoUENJRSksIEFUSSBSYWRl b24gOTEwMCBJR1AgKEE1KSA1ODM0LAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5MTAwIElHUCAo VTMpIDU4MzUsCglBVEkgUmFkZW9uIFhQUkVTUyAyMDAgNTk1NCAoUENJRSksCglBVEkgUmFk ZW9uIFhQUkVTUyAyMDBNIDU5NTUgKFBDSUUpLCBBVEkgUmFkZW9uIDkyNTAgNTk2MCAoQUdQ KSwKCUFUSSBSYWRlb24gOTIwMCA1OTYxIChBR1ApLCBBVEkgUmFkZW9uIDkyMDAgNTk2MiAo QUdQKSwKCUFUSSBSYWRlb24gOTIwMFNFIDU5NjQgKEFHUCksIEFUSSBGaXJlTVYgMjIwMCAo UENJKSwKCUFUSSBFUzEwMDAgNTk2OSAoUENJKSwgQVRJIFJhZGVvbiBYUFJFU1MgMjAwIDU5 NzQgKFBDSUUpLAoJQVRJIFJhZGVvbiBYUFJFU1MgMjAwTSA1OTc1IChQQ0lFKSwKCUFUSSBS YWRlb24gWFBSRVNTIDIwMCA1QTQxIChQQ0lFKSwKCUFUSSBSYWRlb24gWFBSRVNTIDIwME0g NUE0MiAoUENJRSksCglBVEkgUmFkZW9uIFhQUkVTUyAyMDAgNUE2MSAoUENJRSksCglBVEkg UmFkZW9uIFhQUkVTUyAyMDBNIDVBNjIgKFBDSUUpLAoJQVRJIFJhZGVvbiBYMzAwIChSVjM3 MCkgNUI2MCAoUENJRSksCglBVEkgUmFkZW9uIFg2MDAgKFJWMzcwKSA1QjYyIChQQ0lFKSwK CUFUSSBSYWRlb24gWDU1MCAoUlYzNzApIDVCNjMgKFBDSUUpLAoJQVRJIEZpcmVHTCBWMzEw MCAoUlYzNzApIDVCNjQgKFBDSUUpLAoJQVRJIEZpcmVNViAyMjAwIFBDSUUgKFJWMzcwKSA1 QjY1IChQQ0lFKSwKCUFUSSBSYWRlb24gTW9iaWxpdHkgOTIwMCAoTTkrKSA1QzYxIChBR1Ap LAoJQVRJIFJhZGVvbiBNb2JpbGl0eSA5MjAwIChNOSspIDVDNjMgKEFHUCksCglBVEkgTW9i aWxpdHkgUmFkZW9uIFg4MDAgWFQgKE0yOCkgKFBDSUUpLAoJQVRJIE1vYmlsaXR5IEZpcmVH TCBWNTEwMCAoTTI4KSAoUENJRSksCglBVEkgTW9iaWxpdHkgUmFkZW9uIFg4MDAgKE0yOCkg KFBDSUUpLCBBVEkgUmFkZW9uIFg4NTAgNUQ0QyAoUENJRSksCglBVEkgUmFkZW9uIFg4NTAg WFQgUEUgKFI0ODApIChQQ0lFKSwKCUFUSSBSYWRlb24gWDg1MCBTRSAoUjQ4MCkgKFBDSUUp LCBBVEkgUmFkZW9uIFg4NTAgUFJPIChSNDgwKSAoUENJRSksCglBVEkgdW5rbm93biBSYWRl b24gLyBGaXJlR0wgKFI0ODApIDVENTAgKFBDSUUpLAoJQVRJIFJhZGVvbiBYODUwIFhUIChS NDgwKSAoUENJRSksCglBVEkgUmFkZW9uIFg4MDBYVCAoUjQyMykgNUQ1NyAoUENJRSksCglB VEkgRmlyZUdMIFY1MDAwIChSVjQxMCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg3MDAgWFQgKFJW NDEwKSAoUENJRSksCglBVEkgUmFkZW9uIFg3MDAgUFJPIChSVjQxMCkgKFBDSUUpLAoJQVRJ IFJhZGVvbiBYNzAwIFNFIChSVjQxMCkgKFBDSUUpLCBBVEkgUmFkZW9uIFg3MDAgKFJWNDEw KSAoUENJRSksCglBVEkgUmFkZW9uIFg3MDAgU0UgKFJWNDEwKSAoUENJRSksIEFUSSBSYWRl b24gWDE4MDAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIFgxODAwIFhULCBBVEkgTW9iaWxpdHkg UmFkZW9uIFgxODAwLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBWNzIwMCwgQVRJIEZpcmVHTCBW NzIwMCwgQVRJIEZpcmVHTCBWNTMwMCwKCUFUSSBNb2JpbGl0eSBGaXJlR0wgVjcxMDAsIEFU SSBSYWRlb24gWDE4MDAsIEFUSSBSYWRlb24gWDE4MDAsCglBVEkgUmFkZW9uIFgxODAwLCBB VEkgUmFkZW9uIFgxODAwLCBBVEkgUmFkZW9uIFgxODAwLAoJQVRJIEZpcmVHTCBWNzMwMCwg QVRJIEZpcmVHTCBWNzM1MCwgQVRJIFJhZGVvbiBYMTYwMCwgQVRJIFJWNTA1LAoJQVRJIFJh ZGVvbiBYMTMwMC9YMTU1MCwgQVRJIFJhZGVvbiBYMTU1MCwgQVRJIE01NC1HTCwKCUFUSSBN b2JpbGl0eSBSYWRlb24gWDE0MDAsIEFUSSBSYWRlb24gWDEzMDAvWDE1NTAsCglBVEkgUmFk ZW9uIFgxNTUwIDY0LWJpdCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTMwMCwKCUFUSSBNb2Jp bGl0eSBSYWRlb24gWDEzMDAsIEFUSSBNb2JpbGl0eSBSYWRlb24gWDEzMDAsCglBVEkgTW9i aWxpdHkgUmFkZW9uIFgxMzAwLCBBVEkgUmFkZW9uIFgxMzAwLCBBVEkgUmFkZW9uIFgxMzAw LAoJQVRJIFJWNTA1LCBBVEkgUlY1MDUsIEFUSSBGaXJlR0wgVjMzMDAsIEFUSSBGaXJlR0wg VjMzNTAsCglBVEkgUmFkZW9uIFgxMzAwLCBBVEkgUmFkZW9uIFgxNTUwIDY0LWJpdCwgQVRJ IFJhZGVvbiBYMTMwMC9YMTU1MCwKCUFUSSBSYWRlb24gWDE2MDAsIEFUSSBSYWRlb24gWDEz MDAvWDE1NTAsIEFUSSBNb2JpbGl0eSBSYWRlb24gWDE0NTAsCglBVEkgUmFkZW9uIFgxMzAw L1gxNTUwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgyMzAwLAoJQVRJIE1vYmlsaXR5IFJhZGVv biBYMjMwMCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTM1MCwKCUFUSSBNb2JpbGl0eSBSYWRl b24gWDEzNTAsIEFUSSBNb2JpbGl0eSBSYWRlb24gWDE0NTAsCglBVEkgUmFkZW9uIFgxMzAw LCBBVEkgUmFkZW9uIFgxNTUwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgxMzUwLAoJQVRJIEZp cmVNViAyMjUwLCBBVEkgUmFkZW9uIFgxNTUwIDY0LWJpdCwgQVRJIFJhZGVvbiBYMTYwMCwK CUFUSSBSYWRlb24gWDE2NTAsIEFUSSBSYWRlb24gWDE2MDAsIEFUSSBSYWRlb24gWDE2MDAs CglBVEkgTW9iaWxpdHkgRmlyZUdMIFY1MjAwLCBBVEkgTW9iaWxpdHkgUmFkZW9uIFgxNjAw LAoJQVRJIFJhZGVvbiBYMTY1MCwgQVRJIFJhZGVvbiBYMTY1MCwgQVRJIFJhZGVvbiBYMTYw MCwKCUFUSSBSYWRlb24gWDEzMDAgWFQvWDE2MDAgUHJvLCBBVEkgRmlyZUdMIFYzNDAwLAoJ QVRJIE1vYmlsaXR5IEZpcmVHTCBWNTI1MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTcwMCwK CUFUSSBNb2JpbGl0eSBSYWRlb24gWDE3MDAgWFQsIEFUSSBGaXJlR0wgVjUyMDAsCglBVEkg TW9iaWxpdHkgUmFkZW9uIFgxNzAwLCBBVEkgUmFkZW9uIFgyMzAwSEQsCglBVEkgTW9iaWxp dHkgUmFkZW9uIEhEIDIzMDAsIEFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMjMwMCwKCUFUSSBS YWRlb24gWDE5NTAsIEFUSSBSYWRlb24gWDE5MDAsIEFUSSBSYWRlb24gWDE5NTAsCglBVEkg UmFkZW9uIFgxOTAwLCBBVEkgUmFkZW9uIFgxOTAwLCBBVEkgUmFkZW9uIFgxOTAwLAoJQVRJ IFJhZGVvbiBYMTkwMCwgQVRJIFJhZGVvbiBYMTkwMCwgQVRJIFJhZGVvbiBYMTkwMCwKCUFU SSBSYWRlb24gWDE5MDAsIEFUSSBSYWRlb24gWDE5MDAsIEFUSSBSYWRlb24gWDE5MDAsCglB VEkgQU1EIFN0cmVhbSBQcm9jZXNzb3IsIEFUSSBSYWRlb24gWDE5MDAsIEFUSSBSYWRlb24g WDE5NTAsCglBVEkgUlY1NjAsIEFUSSBSVjU2MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBYMTkw MCwgQVRJIFJWNTYwLAoJQVRJIFJhZGVvbiBYMTk1MCBHVCwgQVRJIFJWNTcwLCBBVEkgUlY1 NzAsIEFUSSBGaXJlR0wgVjc0MDAsCglBVEkgUlY1NjAsIEFUSSBSYWRlb24gWDE2NTAsIEFU SSBSYWRlb24gWDE2NTAsIEFUSSBSVjU2MCwKCUFUSSBSYWRlb24gOTEwMCBQUk8gSUdQIDc4 MzQsIEFUSSBSYWRlb24gTW9iaWxpdHkgOTIwMCBJR1AgNzgzNSwKCUFUSSBSYWRlb24gWDEy MDAsIEFUSSBSYWRlb24gWDEyMDAsIEFUSSBSYWRlb24gWDEyMDAsCglBVEkgUmFkZW9uIFgx MjAwLCBBVEkgUmFkZW9uIFgxMjAwLCBBVEkgUlM3NDAsIEFUSSBSUzc0ME0sIEFUSSBSUzc0 MCwKCUFUSSBSUzc0ME0sIEFUSSBSYWRlb24gSEQgMjkwMCBYVCwgQVRJIFJhZGVvbiBIRCAy OTAwIFhULAoJQVRJIFJhZGVvbiBIRCAyOTAwIFhULCBBVEkgUmFkZW9uIEhEIDI5MDAgUHJv LCBBVEkgUmFkZW9uIEhEIDI5MDAgR1QsCglBVEkgRmlyZUdMIFY4NjUwLCBBVEkgRmlyZUdM IFY4NjAwLCBBVEkgRmlyZUdMIFY3NjAwLAoJQVRJIFJhZGVvbiA0ODAwIFNlcmllcywgQVRJ IFJhZGVvbiBIRCA0ODcwIHgyLAoJQVRJIFJhZGVvbiA0ODAwIFNlcmllcywgQVRJIFJhZGVv biBIRCA0ODUwIHgyLAoJQVRJIEZpcmVQcm8gVjg3NTAgKEZpcmVHTCksIEFUSSBGaXJlUHJv IFY3NzYwIChGaXJlR0wpLAoJQVRJIE1vYmlsaXR5IFJBREVPTiBIRCA0ODUwLCBBVEkgTW9i aWxpdHkgUkFERU9OIEhEIDQ4NTAgWDIsCglBVEkgUmFkZW9uIDQ4MDAgU2VyaWVzLCBBVEkg RmlyZVBybyBSVjc3MCwgQU1EIEZpcmVTdHJlYW0gOTI3MCwKCUFNRCBGaXJlU3RyZWFtIDky NTAsIEFUSSBGaXJlUHJvIFY4NzAwIChGaXJlR0wpLAoJQVRJIE1vYmlsaXR5IFJBREVPTiBI RCA0ODcwLCBBVEkgTW9iaWxpdHkgUkFERU9OIE05OCwKCUFUSSBSYWRlb24gNDgwMCBTZXJp ZXMsIEFUSSBSYWRlb24gNDgwMCBTZXJpZXMsIEFUSSBGaXJlUHJvIE03NzUwLAoJQVRJIE05 OCwgQVRJIE05OCwgQVRJIE05OCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA0NjUwLAoJQVRJ IFJhZGVvbiBSVjczMCAoQUdQKSwgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCA0NjcwLAoJQVRJ IEZpcmVQcm8gTTU3NTAsIEFUSSBSYWRlb24gUlY3MzAgKEFHUCksCglBVEkgUlY3MzBYVCBb UmFkZW9uIEhEIDQ2NzBdLCBBVEkgUkFERU9OIEU0NjAwLAoJQVRJIFJhZGVvbiBIRCA0NjAw IFNlcmllcywgQVRJIFJWNzMwIFBSTyBbUmFkZW9uIEhEIDQ2NTBdLAoJQVRJIEZpcmVQcm8g Vjc3NTAgKEZpcmVHTCksIEFUSSBGaXJlUHJvIFY1NzAwIChGaXJlR0wpLAoJQVRJIEZpcmVQ cm8gVjM3NTAgKEZpcmVHTCksIEFUSSBNb2JpbGl0eSBSYWRlb24gSEQgNDgzMCwKCUFUSSBN b2JpbGl0eSBSYWRlb24gSEQgNDg1MCwgQVRJIEZpcmVQcm8gTTc3NDAsIEFUSSBSVjc0MCwK CUFUSSBSYWRlb24gSEQgNDc3MCwgQVRJIFJhZGVvbiBIRCA0NzAwIFNlcmllcywgQVRJIFJh ZGVvbiBIRCA0NzcwLAoJQVRJIEZpcmVQcm8gTTU3NTAsIEFUSSBSVjYxMCwgQVRJIFJhZGVv biBIRCAyNDAwIFhULAoJQVRJIFJhZGVvbiBIRCAyNDAwIFBybywgQVRJIFJhZGVvbiBIRCAy NDAwIFBSTyBBR1AsIEFUSSBGaXJlR0wgVjQwMDAsCglBVEkgUlY2MTAsIEFUSSBSYWRlb24g SEQgMjM1MCwgQVRJIE1vYmlsaXR5IFJhZGVvbiBIRCAyNDAwIFhULAoJQVRJIE1vYmlsaXR5 IFJhZGVvbiBIRCAyNDAwLCBBVEkgUkFERU9OIEUyNDAwLCBBVEkgUlY2MTAsCglBVEkgRmly ZU1WIDIyNjAsIEFUSSBSVjY3MCwgQVRJIFJhZGVvbiBIRDM4NzAsCglBVEkgTW9iaWxpdHkg UmFkZW9uIEhEIDM4NTAsIEFUSSBSYWRlb24gSEQzODUwLAoJQVRJIE1vYmlsaXR5IFJhZGVv biBIRCAzODUwIFgyLCBBVEkgUlY2NzAsCglBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDM4NzAs IEFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMzg3MCBYMiwKCUFUSSBSYWRlb24gSEQzODcwIFgy LCBBVEkgRmlyZUdMIFY3NzAwLCBBVEkgUmFkZW9uIEhEMzg1MCwKCUFUSSBSYWRlb24gSEQz NjkwLCBBTUQgRmlyZXN0cmVhbSA5MTcwLCBBVEkgUmFkZW9uIEhEIDQ1NTAsCglBVEkgUmFk ZW9uIFJWNzEwLCBBVEkgUmFkZW9uIFJWNzEwLCBBVEkgUmFkZW9uIEhEIDQzNTAsCglBVEkg TW9iaWxpdHkgUmFkZW9uIDQzMDAgU2VyaWVzLCBBVEkgTW9iaWxpdHkgUmFkZW9uIDQ1MDAg U2VyaWVzLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiA0NTAwIFNlcmllcywgQVRJIEZpcmVQcm8g UkcyMjAsIEFUSSBSVjYzMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMjYwMCwgQVRJIE1v YmlsaXR5IFJhZGVvbiBIRCAyNjAwIFhULAoJQVRJIFJhZGVvbiBIRCAyNjAwIFhUIEFHUCwg QVRJIFJhZGVvbiBIRCAyNjAwIFBybyBBR1AsCglBVEkgUmFkZW9uIEhEIDI2MDAgWFQsIEFU SSBSYWRlb24gSEQgMjYwMCBQcm8sIEFUSSBHZW1pbmkgUlY2MzAsCglBVEkgR2VtaW5pIE1v YmlsaXR5IFJhZGVvbiBIRCAyNjAwIFhULCBBVEkgRmlyZUdMIFY1NjAwLAoJQVRJIEZpcmVH TCBWMzYwMCwgQVRJIFJhZGVvbiBIRCAyNjAwIExFLAoJQVRJIE1vYmlsaXR5IEZpcmVHTCBH cmFwaGljcyBQcm9jZXNzb3IsIEFUSSBSYWRlb24gUlY3MTAsCglBVEkgUmFkZW9uIEhEIDM0 NzAsIEFUSSBNb2JpbGl0eSBSYWRlb24gSEQgMzQzMCwKCUFUSSBNb2JpbGl0eSBSYWRlb24g SEQgMzQwMCBTZXJpZXMsIEFUSSBSYWRlb24gSEQgMzQ1MCwKCUFUSSBSYWRlb24gSEQgMzQ1 MCwgQVRJIFJhZGVvbiBIRCAzNDMwLCBBVEkgUmFkZW9uIEhEIDM0NTAsCglBVEkgRmlyZVBy byBWMzcwMCwgQVRJIEZpcmVNViAyNDUwLCBBVEkgRmlyZU1WIDIyNjAsIEFUSSBGaXJlTVYg MjI2MCwKCUFUSSBSYWRlb24gSEQgMzYwMCBTZXJpZXMsIEFUSSBSYWRlb24gSEQgMzY1MCBB R1AsCglBVEkgUmFkZW9uIEhEIDM2MDAgUFJPLCBBVEkgUmFkZW9uIEhEIDM2MDAgWFQsCglB VEkgUmFkZW9uIEhEIDM2MDAgUFJPLCBBVEkgTW9iaWxpdHkgUmFkZW9uIEhEIDM2NTAsCglB VEkgTW9iaWxpdHkgUmFkZW9uIEhEIDM2NzAsIEFUSSBNb2JpbGl0eSBGaXJlR0wgVjU3MDAs CglBVEkgTW9iaWxpdHkgRmlyZUdMIFY1NzI1LCBBVEkgUmFkZW9uIEhEIDMyMDAgR3JhcGhp Y3MsCglBVEkgUmFkZW9uIDMxMDAgR3JhcGhpY3MsIEFUSSBSYWRlb24gSEQgMzIwMCBHcmFw aGljcywKCUFUSSBSYWRlb24gMzEwMCBHcmFwaGljcywgQVRJIFJhZGVvbiBIRCAzMzAwIEdy YXBoaWNzLAoJQVRJIFJhZGVvbiBIRCAzMjAwIEdyYXBoaWNzLCBBVEkgUmFkZW9uIDMwMDAg R3JhcGhpY3MsCglBVEkgUmFkZW9uIEhEIDQyMDAsIEFUSSBSYWRlb24gNDEwMCwgQVRJIE1v YmlsaXR5IFJhZGVvbiBIRCA0MjAwLAoJQVRJIE1vYmlsaXR5IFJhZGVvbiA0MTAwLCBBVEkg UlM4ODAKKElJKSBQcmltYXJ5IERldmljZSBpczogUENJIDAxQDAwOjA1OjAKKElJKSByZXNv dXJjZSByYW5nZXMgYWZ0ZXIgeGY4NkNsYWltRml4ZWRSZXNvdXJjZXMoKSBjYWxsOgoJWzBd IC0xCTAJMHgwMDBmMDAwMCAtIDB4MDAwZmZmZmYgKDB4MTAwMDApIE1YW0JdCglbMV0gLTEJ MAkweDAwMGMwMDAwIC0gMHgwMDBlZmZmZiAoMHgzMDAwMCkgTVhbQl0KCVsyXSAtMQkwCTB4 MDAwMDAwMDAgLSAweDAwMDlmZmZmICgweGEwMDAwKSBNWFtCXQoJWzNdIC0xCTAJMHgwMDAw ZmZmZiAtIDB4MDAwMGZmZmYgKDB4MSkgSVhbQl0KCVs0XSAtMQkwCTB4MDAwMDAwMDAgLSAw eDAwMDAwMGZmICgweDEwMCkgSVhbQl0KKElJKSByZXNvdXJjZSByYW5nZXMgYWZ0ZXIgcHJv YmluZzoKCVswXSAtMQkwCTB4MDAwZjAwMDAgLSAweDAwMGZmZmZmICgweDEwMDAwKSBNWFtC XQoJWzFdIC0xCTAJMHgwMDBjMDAwMCAtIDB4MDAwZWZmZmYgKDB4MzAwMDApIE1YW0JdCglb Ml0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDA5ZmZmZiAoMHhhMDAwMCkgTVhbQl0KCVszXSAw CTAJMHgwMDBhMDAwMCAtIDB4MDAwYWZmZmYgKDB4MTAwMDApIE1TW0JdCglbNF0gMAkwCTB4 MDAwYjAwMDAgLSAweDAwMGI3ZmZmICgweDgwMDApIE1TW0JdCglbNV0gMAkwCTB4MDAwYjgw MDAgLSAweDAwMGJmZmZmICgweDgwMDApIE1TW0JdCglbNl0gLTEJMAkweDAwMDBmZmZmIC0g MHgwMDAwZmZmZiAoMHgxKSBJWFtCXQoJWzddIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAw ZmYgKDB4MTAwKSBJWFtCXQoJWzhdIDAJMAkweDAwMDAwM2IwIC0gMHgwMDAwMDNiYiAoMHhj KSBJU1tCXQoJWzldIDAJMAkweDAwMDAwM2MwIC0gMHgwMDAwMDNkZiAoMHgyMCkgSVNbQl0K KElJKSBTZXR0aW5nIHZnYSBmb3Igc2NyZWVuIDAuCihJSSkgUkFERU9OKDApOiBUT1RPIFNB WVMgMDAwMDAwMDBmZGZlMDAwMAooSUkpIFJBREVPTigwKTogTU1JTyByZWdpc3RlcnMgYXQg MHgwMDAwMDAwMGZkZmUwMDAwOiBzaXplIDY0S0IKKElJKSBSQURFT04oMCk6IFBDSSBidXMg MSBjYXJkIDUgZnVuYyAwCig9PSkgUkFERU9OKDApOiBEZXB0aCAyNCwgKC0tKSBmcmFtZWJ1 ZmZlciBicHAgMzIKKElJKSBSQURFT04oMCk6IFBpeGVsIGRlcHRoID0gMjQgYml0cyBzdG9y ZWQgaW4gNCBieXRlcyAoMzIgYnBwIHBpeG1hcHMpCig9PSkgUkFERU9OKDApOiBEZWZhdWx0 IHZpc3VhbCBpcyBUcnVlQ29sb3IKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgInZnYWh3Igoo SUkpIExvYWRNb2R1bGU6ICJ2Z2FodyIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hv cmcvbW9kdWxlcy8vbGlidmdhaHcuc28KKElJKSBNb2R1bGUgdmdhaHc6IHZlbmRvcj0iWC5P cmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjYuNSwgbW9kdWxlIHZlcnNpb24gPSAw LjEuMAoJQUJJIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIsIHZlcnNpb24gNS4wCihJSSkg UkFERU9OKDApOiB2Z2FIV0dldElPQmFzZTogaHdwLT5JT0Jhc2UgaXMgMHgwM2QwLCBod3At PlBJT09mZnNldCBpcyAweDAwMDAKKD09KSBSQURFT04oMCk6IFJHQiB3ZWlnaHQgODg4CihJ SSkgUkFERU9OKDApOiBVc2luZyA4IGJpdHMgcGVyIFJHQiAoOCBiaXQgREFDKQooLS0pIFJB REVPTigwKTogQ2hpcHNldDogIkFUSSBSYWRlb24gSEQgMzIwMCBHcmFwaGljcyIgKENoaXBJ RCA9IDB4OTYxMCkKKC0tKSBSQURFT04oMCk6IExpbmVhciBmcmFtZWJ1ZmZlciBhdCAweDAw MDAwMDAwZDAwMDAwMDAKKElJKSBSQURFT04oMCk6IFBDSSBjYXJkIGRldGVjdGVkCihJSSkg TG9hZGluZyBzdWIgbW9kdWxlICJpbnQxMCIKKElJKSBMb2FkTW9kdWxlOiAiaW50MTAiCihJ SSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvL2xpYmludDEwLnNvCihJ SSkgTW9kdWxlIGludDEwOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBm b3IgMS42LjUsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgVmlk ZW8gRHJpdmVyLCB2ZXJzaW9uIDUuMAooSUkpIFJBREVPTigwKTogaW5pdGlhbGl6aW5nIGlu dDEwCig9PSkgUkFERU9OKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4YTAwMDAsMHgy MDAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBSQURFT04oMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHhjMDAwMCwweDQwMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooSUkpIFJBREVP TigwKTogUHJpbWFyeSBWX0JJT1Mgc2VnbWVudCBpczogMHhjMDAwCig9PSkgUkFERU9OKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFy CihJSSkgUkFERU9OKDApOiBBVE9NIEJJT1MgZGV0ZWN0ZWQKKElJKSBSQURFT04oMCk6IEFU T00gQklPUyBSb206IAoJU3Vic3lzdGVtVmVuZG9ySUQ6IDB4MTAwMiBTdWJzeXN0ZW1JRDog MHgxMDAyCglJT0Jhc2VBZGRyZXNzOiAweGVlMDAKCUZpbGVuYW1lOiBNQTc4TV9TMkhfRFYK CUJJT1MgQm9vdHVwIE1lc3NhZ2U6IA0KQjI3NzIyIFJTNzgwIEREUjIgMjAwZS81MDBtICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KCihJSSkg UkFERU9OKDApOiBGcmFtZWJ1ZmZlciBzcGFjZSB1c2VkIGJ5IEZpcm13YXJlIChrYik6IDE2 CihJSSkgUkFERU9OKDApOiBTdGFydCBvZiBWUkFNIGFyZWEgdXNlZCBieSBGaXJtd2FyZTog MHgxZmZmYzAwMAooSUkpIFJBREVPTigwKTogQXRvbUJJT1MgcmVxdWVzdHMgMTZrQiBvZiBW UkFNIHNjcmF0Y2ggc3BhY2UKKElJKSBSQURFT04oMCk6IEF0b21CSU9TIFZSQU0gc2NyYXRj aCBiYXNlOiAweDFmZmZjMDAwCihJSSkgUkFERU9OKDApOiBDYW5ub3QgZ2V0IFZSQU0gc2Ny YXRjaCBzcGFjZS4gQWxsb2NhdGluZyBpbiBtYWluIG1lbW9yeSBpbnN0ZWFkCihJSSkgUkFE RU9OKDApOiBEZWZhdWx0IEVuZ2luZSBDbG9jazogNTAwMDAwCihJSSkgUkFERU9OKDApOiBE ZWZhdWx0IE1lbW9yeSBDbG9jazogNDAwMDAwCihJSSkgUkFERU9OKDApOiBNYXhpbXVtIFBp eGVsIENsb2NrUExMIEZyZXF1ZW5jeSBPdXRwdXQ6IDEyMDAwMDAKKElJKSBSQURFT04oMCk6 IE1pbmltdW0gUGl4ZWwgQ2xvY2tQTEwgRnJlcXVlbmN5IE91dHB1dDogMAooSUkpIFJBREVP TigwKTogTWF4aW11bSBQaXhlbCBDbG9ja1BMTCBGcmVxdWVuY3kgSW5wdXQ6IDEzNTAwCihJ SSkgUkFERU9OKDApOiBNaW5pbXVtIFBpeGVsIENsb2NrUExMIEZyZXF1ZW5jeSBJbnB1dDog MTAwMAooSUkpIFJBREVPTigwKTogTWF4aW11bSBQaXhlbCBDbG9jazogNDAwMDAwCihJSSkg UkFERU9OKDApOiBSZWZlcmVuY2UgQ2xvY2s6IDE0MzIwCmRybU9wZW5EZXZpY2U6IG5vZGUg bmFtZSBpcyAvZGV2L2RyaS9jYXJkMApGYWlsZWQgdG8gY2hhbmdlIG93bmVyIG9yIGdyb3Vw IGZvciBmaWxlIC9kZXYvZHJpISAyOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5CkZhaWxl ZCB0byBjaGFuZ2Ugb3duZXIgb3IgZ3JvdXAgZm9yIGZpbGUgL2Rldi9kcmkvY2FyZDAhIDI6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKZHJtT3BlbkRldmljZTogb3BlbiByZXN1bHQg aXMgLTEsIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpGYWlsZWQgdG8gY2hhbmdlIG93 bmVyIG9yIGdyb3VwIGZvciBmaWxlIC9kZXYvZHJpL2NhcmQwISAyOiBObyBzdWNoIGZpbGUg b3IgZGlyZWN0b3J5CmRybU9wZW5EZXZpY2U6IG9wZW4gcmVzdWx0IGlzIC0xLCAoTm8gc3Vj aCBmaWxlIG9yIGRpcmVjdG9yeSkKZHJtT3BlbkRldmljZTogT3BlbiBmYWlsZWQKZHJtT3Bl bkJ5QnVzaWQ6IFNlYXJjaGluZyBmb3IgQnVzSUQgcGNpOjAwMDA6MDE6MDUuMApkcm1PcGVu RGV2aWNlOiBub2RlIG5hbWUgaXMgL2Rldi9kcmkvY2FyZDAKZHJtT3BlbkRldmljZTogb3Bl biByZXN1bHQgaXMgMTAsIChPSykKZHJtT3BlbkJ5QnVzaWQ6IGRybU9wZW5NaW5vciByZXR1 cm5zIDEwCmRybU9wZW5CeUJ1c2lkOiBkcm1HZXRCdXNpZCByZXBvcnRzIHBjaTowMDAwOjAx OjA1LjAKKElJKSBSQURFT04oMCk6IFtkcmldIEZvdW5kIERSSSBsaWJyYXJ5IHZlcnNpb24g MS4zLjAgYW5kIGtlcm5lbCBtb2R1bGUgdmVyc2lvbiAxLjMxLjAKKD09KSBSQURFT04oMCk6 IFBhZ2UgRmxpcHBpbmcgZGlzYWJsZWQgb24gcjV4eCBhbmQgbmV3ZXIgY2hpcHMuCgooSUkp IFJBREVPTigwKTogV2lsbCB0cnkgdG8gdXNlIERNQSBmb3IgWHYgaW1hZ2UgdHJhbnNmZXJz CihJSSkgUkFERU9OKDApOiBEZXRlY3RlZCB0b3RhbCB2aWRlbyBSQU09NTI0Mjg4SywgYWNj ZXNzaWJsZT0yNjIxNDRLIChQQ0kgQkFSPTI2MjE0NEspCigtLSkgUkFERU9OKDApOiBNYXBw ZWQgVmlkZW9SQU06IDI2MjE0NCBrQnl0ZSAoMTI4IGJpdCBERFIgU0RSQU0pCihJSSkgUkFE RU9OKDApOiBDb2xvciB0aWxpbmcgZGlzYWJsZWQKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUg ImRkYyIKKElJKSBMb2FkTW9kdWxlOiAiZGRjIgooSUkpIE1vZHVsZSAiZGRjIiBhbHJlYWR5 IGJ1aWx0LWluCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJpMmMiCihJSSkgTG9hZE1vZHVs ZTogImkyYyIKKElJKSBNb2R1bGUgImkyYyIgYWxyZWFkeSBidWlsdC1pbgooSUkpIFJBREVP TigwKTogcmVmX2ZyZXE6IDE0MzIsIG1pbl9vdXRfcGxsOiA2NDgwMCwgbWF4X291dF9wbGw6 IDEyMDAwMCwgbWluX2luX3BsbDogMTAwLCBtYXhfaW5fcGxsOiAxMzUwLCB4Y2xrOiA0MDAw MCwgc2NsazogNTAwLjAwMDAwMCwgbWNsazogNDAwLjAwMDAwMAooSUkpIFJBREVPTigwKTog UExMIHBhcmFtZXRlcnM6IHJmPTE0MzIgcmQ9MTIgbWluPTY0ODAwIG1heD0xMjAwMDA7IHhj bGs9NDAwMDAKKElJKSBSQURFT04oMCk6IE91dHB1dCBWR0EtMCB1c2luZyBtb25pdG9yIHNl Y3Rpb24gTW9uaXRvcjAKKElJKSBSQURFT04oMCk6IEkyQyBidXMgIlZHQS0wIiBpbml0aWFs aXplZC4KKElJKSBSQURFT04oMCk6IE91dHB1dCBEVkktMCBoYXMgbm8gbW9uaXRvciBzZWN0 aW9uCihJSSkgUkFERU9OKDApOiBJMkMgYnVzICJEVkktMCIgaW5pdGlhbGl6ZWQuCihJSSkg UkFERU9OKDApOiBQb3J0MDoKICBYUkFORFIgbmFtZTogVkdBLTAKICBDb25uZWN0b3I6IFZH QQogIENSVDE6IElOVEVSTkFMX0tMRFNDUF9EQUMxCiAgRERDIHJlZzogMHg3ZTQwCihJSSkg UkFERU9OKDApOiBQb3J0MToKICBYUkFORFIgbmFtZTogRFZJLTAKICBDb25uZWN0b3I6IERW SS1ECiAgREZQMTogSU5URVJOQUxfS0xEU0NQX0xWVE1BCiAgRERDIHJlZzogMHg3ZTUwCihJ SSkgUkFERU9OKDApOiBJMkMgZGV2aWNlICJWR0EtMDpFLUVESUQgc2VnbWVudCByZWdpc3Rl ciIgcmVnaXN0ZXJlZCBhdCBhZGRyZXNzIDB4NjAuCihJSSkgUkFERU9OKDApOiBJMkMgZGV2 aWNlICJWR0EtMDpkZGMyIiByZWdpc3RlcmVkIGF0IGFkZHJlc3MgMHhBMC4KKElJKSBSQURF T04oMCk6IEVESUQgdmVuZG9yICJIU0wiLCBwcm9kIGlkIDE3MTYKKElJKSBSQURFT04oMCk6 IFVzaW5nIGhzeW5jIHJhbmdlcyBmcm9tIGNvbmZpZyBmaWxlCihJSSkgUkFERU9OKDApOiBV c2luZyB2cmVmcmVzaCByYW5nZXMgZnJvbSBjb25maWcgZmlsZQooSUkpIFJBREVPTigwKTog UHJpbnRpbmcgRERDIGdhdGhlcmVkIE1vZGVsaW5lczoKKElJKSBSQURFT04oMCk6IE1vZGVs aW5lICIxMDI0eDc2OCJ4MC4wICAgOTQuNTAgIDEwMjQgMTA3MiAxMTY4IDEzNzYgIDc2OCA3 NjkgNzcyIDgwOCAraHN5bmMgK3ZzeW5jICg2OC43IGtIeikKKElJKSBSQURFT04oMCk6IE1v ZGVsaW5lICI2NDB4NDgwIngwLjAgICAzMS41MCAgNjQwIDY1NiA3MjAgODQwICA0ODAgNDgx IDQ4NCA1MDAgLWhzeW5jIC12c3luYyAoMzcuNSBrSHopCihJSSkgUkFERU9OKDApOiBNb2Rl bGluZSAiNjQweDQ4MCJ4MC4wICAgMjUuMTggIDY0MCA2NTYgNzUyIDgwMCAgNDgwIDQ5MCA0 OTIgNTI1IC1oc3luYyAtdnN5bmMgKDMxLjUga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxp bmUgIjcyMHg0MDAieDAuMCAgIDI4LjMyICA3MjAgNzM4IDg0NiA5MDAgIDQwMCA0MTIgNDE0 IDQ0OSAtaHN5bmMgK3ZzeW5jICgzMS41IGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5l ICIxMDI0eDc2OCJ4MC4wICAgNzguNzUgIDEwMjQgMTA0MCAxMTM2IDEzMTIgIDc2OCA3Njkg NzcyIDgwMCAraHN5bmMgK3ZzeW5jICg2MC4wIGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVs aW5lICI4MDB4NjAwIngwLjAgICA0OS41MCAgODAwIDgxNiA4OTYgMTA1NiAgNjAwIDYwMSA2 MDQgNjI1ICtoc3luYyArdnN5bmMgKDQ2Ljkga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxp bmUgIjY0MHg0ODAieDAuMCAgIDM2LjAwICA2NDAgNjk2IDc1MiA4MzIgIDQ4MCA0ODEgNDg0 IDUwOSAtaHN5bmMgLXZzeW5jICg0My4zIGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5l ICI4MDB4NjAwIngwLjAgICA1Ni4yNSAgODAwIDgzMiA4OTYgMTA0OCAgNjAwIDYwMSA2MDQg NjMxICtoc3luYyArdnN5bmMgKDUzLjcga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxpbmUg IjEwMjR4NzY4IngwLjAgICA5NC41MCAgMTAyNCAxMDcyIDExNjggMTM3NiAgNzY4IDc2OSA3 NzIgODA4ICtoc3luYyArdnN5bmMgKDY4Ljcga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxp bmUgIjEyODB4MTAyNCJ4MC4wICAxMDguMDAgIDEyODAgMTMyOCAxNDQwIDE2ODggIDEwMjQg MTAyNSAxMDI4IDEwNjYgK2hzeW5jICt2c3luYyAoNjQuMCBrSHopCihJSSkgUkFERU9OKDAp OiBPdXRwdXQ6IFZHQS0wLCBEZXRlY3RlZCBNb25pdG9yIFR5cGU6IDEKKElJKSBSQURFT04o MCk6IEVESUQgZGF0YSBmcm9tIHRoZSBkaXNwbGF5IG9uIG91dHB1dDogVkdBLTAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQooSUkpIFJBREVPTigwKTogTWFudWZhY3R1cmVyOiBIU0wgIE1v ZGVsOiA2YjQgIFNlcmlhbCM6IDEwNzE1MAooSUkpIFJBREVPTigwKTogWWVhcjogMjAwMSAg V2VlazogNTIKKElJKSBSQURFT04oMCk6IEVESUQgVmVyc2lvbjogMS4yCihJSSkgUkFERU9O KDApOiBBbmFsb2cgRGlzcGxheSBJbnB1dCwgIElucHV0IFZvbHRhZ2UgTGV2ZWw6IDAuNzAw LzAuMzAwIFYKKElJKSBSQURFT04oMCk6IFN5bmM6ICBTZXBhcmF0ZQooSUkpIFJBREVPTigw KTogTWF4IEltYWdlIFNpemUgW2NtXTogaG9yaXouOiAzMiAgdmVydC46IDI0CihJSSkgUkFE RU9OKDApOiBHYW1tYTogMi4yNgooSUkpIFJBREVPTigwKTogRFBNUyBjYXBhYmlsaXRpZXM6 IFN0YW5kQnkgU3VzcGVuZCBPZmY7IFJHQi9Db2xvciBEaXNwbGF5CihJSSkgUkFERU9OKDAp OiBGaXJzdCBkZXRhaWxlZCB0aW1pbmcgaXMgcHJlZmVycmVkIG1vZGUKKElJKSBSQURFT04o MCk6IHJlZFg6IDAuNjQ1IHJlZFk6IDAuMzIxICAgZ3JlZW5YOiAwLjI4NSBncmVlblk6IDAu NjAwCihJSSkgUkFERU9OKDApOiBibHVlWDogMC4xNDIgYmx1ZVk6IDAuMDU3ICAgd2hpdGVY OiAwLjI4MyB3aGl0ZVk6IDAuMjk4CihJSSkgUkFERU9OKDApOiBTdXBwb3J0ZWQgZXN0YWJs aXNoZWQgdGltaW5nczoKKElJKSBSQURFT04oMCk6IDcyMHg0MDBANzBIegooSUkpIFJBREVP TigwKTogNjQweDQ4MEA2MEh6CihJSSkgUkFERU9OKDApOiA2NDB4NDgwQDc1SHoKKElJKSBS QURFT04oMCk6IDgwMHg2MDBANzVIegooSUkpIFJBREVPTigwKTogMTAyNHg3NjhANzVIegoo SUkpIFJBREVPTigwKTogTWFudWZhY3R1cmVyJ3MgbWFzazogMAooSUkpIFJBREVPTigwKTog U3VwcG9ydGVkIHN0YW5kYXJkIHRpbWluZ3M6CihJSSkgUkFERU9OKDApOiAjMDogaHNpemU6 IDY0MCAgdnNpemUgNDgwICByZWZyZXNoOiA4NSAgdmlkOiAyMjgzMwooSUkpIFJBREVPTigw KTogIzE6IGhzaXplOiA4MDAgIHZzaXplIDYwMCAgcmVmcmVzaDogODUgIHZpZDogMjI4NTMK KElJKSBSQURFT04oMCk6ICMyOiBoc2l6ZTogMTAyNCAgdnNpemUgNzY4ICByZWZyZXNoOiA4 NSAgdmlkOiAyMjg4MQooSUkpIFJBREVPTigwKTogIzM6IGhzaXplOiAxMjgwICB2c2l6ZSAx MDI0ICByZWZyZXNoOiA2MCAgdmlkOiAzMjg5NwooSUkpIFJBREVPTigwKTogU3VwcG9ydGVk IGRldGFpbGVkIHRpbWluZzoKKElJKSBSQURFT04oMCk6IGNsb2NrOiA5NC41IE1IeiAgIElt YWdlIFNpemU6ICAzMDYgeCAyMzAgbW0KKElJKSBSQURFT04oMCk6IGhfYWN0aXZlOiAxMDI0 ICBoX3N5bmM6IDEwNzIgIGhfc3luY19lbmQgMTE2OCBoX2JsYW5rX2VuZCAxMzc2IGhfYm9y ZGVyOiAwCihJSSkgUkFERU9OKDApOiB2X2FjdGl2ZTogNzY4ICB2X3N5bmM6IDc2OSAgdl9z eW5jX2VuZCA3NzIgdl9ibGFua2luZzogODA4IHZfYm9yZGVyOiAwCihJSSkgUkFERU9OKDAp OiBTZXJpYWwgTm86IDAwMDAwMDAwMDAKKElJKSBSQURFT04oMCk6IFJhbmdlczogViBtaW46 IDUwIFYgbWF4OiAxNjAgSHosIEggbWluOiAzMCBIIG1heDogNzIga0h6LCBQaXhDbG9jayBt YXggMTEwIE1IegooSUkpIFJBREVPTigwKTogTW9uaXRvciBuYW1lOiA3MjBFCihJSSkgUkFE RU9OKDApOiBFRElEIChpbiBoZXgpOgooSUkpIFJBREVPTigwKTogCTAwZmZmZmZmZmZmZmZm MDAyMjZjYjQwNjhlYTIwMTAwCihJSSkgUkFERU9OKDApOiAJMzQwYjAxMDIwODIwMTg3ZWVh MTI2OWE1NTI0OTk5MjQKKElJKSBSQURFT04oMCk6IAkwZTQ4NGNhNDQyMDAzMTU5NDU1OTYx NTk4MTgwMDEwMQooSUkpIFJBREVPTigwKTogCTAxMDEwMTAxMDEwMWVhMjQwMDYwNDEwMDI4 MzAzMDYwCihJSSkgUkFERU9OKDApOiAJMTMwMDMyZTYxMDAwMDAxZTAwMDAwMGZmMDAzMDMw MzAKKElJKSBSQURFT04oMCk6IAkzMDMwMzAzMDMwMzAzMDBhMjAyMDAwMDAwMGZkMDAzMgoo SUkpIFJBREVPTigwKTogCWEwMWU0ODBiMDAwYTIwMjAyMDIwMjAyMDAwMDAwMGZjCihJSSkg UkFERU9OKDApOiAJMDAzNzMyMzA0NTBhMjAyMDIwMjAyMDIwMjAyMDAwYjEKZmluaXNoZWQg b3V0cHV0IGRldGVjdDogMAooSUkpIFJBREVPTigwKTogSTJDIGRldmljZSAiRFZJLTA6RS1F RElEIHNlZ21lbnQgcmVnaXN0ZXIiIHJlZ2lzdGVyZWQgYXQgYWRkcmVzcyAweDYwLgooSUkp IFJBREVPTigwKTogSTJDIGRldmljZSAiRFZJLTA6ZGRjMiIgcmVnaXN0ZXJlZCBhdCBhZGRy ZXNzIDB4QTAuCihJSSkgUkFERU9OKDApOiBPdXRwdXQ6IERWSS0wLCBEZXRlY3RlZCBNb25p dG9yIFR5cGU6IDAKZmluaXNoZWQgb3V0cHV0IGRldGVjdDogMQpmaW5pc2hlZCBhbGwgZGV0 ZWN0CmJlZm9yZSB4Zjg2SW5pdGlhbENvbmZpZ3VyYXRpb24KKElJKSBSQURFT04oMCk6IEVE SUQgdmVuZG9yICJIU0wiLCBwcm9kIGlkIDE3MTYKKElJKSBSQURFT04oMCk6IFVzaW5nIGhz eW5jIHJhbmdlcyBmcm9tIGNvbmZpZyBmaWxlCihJSSkgUkFERU9OKDApOiBVc2luZyB2cmVm cmVzaCByYW5nZXMgZnJvbSBjb25maWcgZmlsZQooSUkpIFJBREVPTigwKTogUHJpbnRpbmcg RERDIGdhdGhlcmVkIE1vZGVsaW5lczoKKElJKSBSQURFT04oMCk6IE1vZGVsaW5lICIxMDI0 eDc2OCJ4MC4wICAgOTQuNTAgIDEwMjQgMTA3MiAxMTY4IDEzNzYgIDc2OCA3NjkgNzcyIDgw OCAraHN5bmMgK3ZzeW5jICg2OC43IGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5lICI2 NDB4NDgwIngwLjAgICAzMS41MCAgNjQwIDY1NiA3MjAgODQwICA0ODAgNDgxIDQ4NCA1MDAg LWhzeW5jIC12c3luYyAoMzcuNSBrSHopCihJSSkgUkFERU9OKDApOiBNb2RlbGluZSAiNjQw eDQ4MCJ4MC4wICAgMjUuMTggIDY0MCA2NTYgNzUyIDgwMCAgNDgwIDQ5MCA0OTIgNTI1IC1o c3luYyAtdnN5bmMgKDMxLjUga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxpbmUgIjcyMHg0 MDAieDAuMCAgIDI4LjMyICA3MjAgNzM4IDg0NiA5MDAgIDQwMCA0MTIgNDE0IDQ0OSAtaHN5 bmMgK3ZzeW5jICgzMS41IGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5lICIxMDI0eDc2 OCJ4MC4wICAgNzguNzUgIDEwMjQgMTA0MCAxMTM2IDEzMTIgIDc2OCA3NjkgNzcyIDgwMCAr aHN5bmMgK3ZzeW5jICg2MC4wIGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5lICI4MDB4 NjAwIngwLjAgICA0OS41MCAgODAwIDgxNiA4OTYgMTA1NiAgNjAwIDYwMSA2MDQgNjI1ICto c3luYyArdnN5bmMgKDQ2Ljkga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxpbmUgIjY0MHg0 ODAieDAuMCAgIDM2LjAwICA2NDAgNjk2IDc1MiA4MzIgIDQ4MCA0ODEgNDg0IDUwOSAtaHN5 bmMgLXZzeW5jICg0My4zIGtIeikKKElJKSBSQURFT04oMCk6IE1vZGVsaW5lICI4MDB4NjAw IngwLjAgICA1Ni4yNSAgODAwIDgzMiA4OTYgMTA0OCAgNjAwIDYwMSA2MDQgNjMxICtoc3lu YyArdnN5bmMgKDUzLjcga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxpbmUgIjEwMjR4NzY4 IngwLjAgICA5NC41MCAgMTAyNCAxMDcyIDExNjggMTM3NiAgNzY4IDc2OSA3NzIgODA4ICto c3luYyArdnN5bmMgKDY4Ljcga0h6KQooSUkpIFJBREVPTigwKTogTW9kZWxpbmUgIjEyODB4 MTAyNCJ4MC4wICAxMDguMDAgIDEyODAgMTMyOCAxNDQwIDE2ODggIDEwMjQgMTAyNSAxMDI4 IDEwNjYgK2hzeW5jICt2c3luYyAoNjQuMCBrSHopCihJSSkgUkFERU9OKDApOiBPdXRwdXQ6 IFZHQS0wLCBEZXRlY3RlZCBNb25pdG9yIFR5cGU6IDEKKElJKSBSQURFT04oMCk6IEVESUQg ZGF0YSBmcm9tIHRoZSBkaXNwbGF5IG9uIG91dHB1dDogVkdBLTAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQooSUkpIFJBREVPTigwKTogTWFudWZhY3R1cmVyOiBIU0wgIE1vZGVsOiA2YjQg IFNlcmlhbCM6IDEwNzE1MAooSUkpIFJBREVPTigwKTogWWVhcjogMjAwMSAgV2VlazogNTIK KElJKSBSQURFT04oMCk6IEVESUQgVmVyc2lvbjogMS4yCihJSSkgUkFERU9OKDApOiBBbmFs b2cgRGlzcGxheSBJbnB1dCwgIElucHV0IFZvbHRhZ2UgTGV2ZWw6IDAuNzAwLzAuMzAwIFYK KElJKSBSQURFT04oMCk6IFN5bmM6ICBTZXBhcmF0ZQooSUkpIFJBREVPTigwKTogTWF4IElt YWdlIFNpemUgW2NtXTogaG9yaXouOiAzMiAgdmVydC46IDI0CihJSSkgUkFERU9OKDApOiBH YW1tYTogMi4yNgooSUkpIFJBREVPTigwKTogRFBNUyBjYXBhYmlsaXRpZXM6IFN0YW5kQnkg U3VzcGVuZCBPZmY7IFJHQi9Db2xvciBEaXNwbGF5CihJSSkgUkFERU9OKDApOiBGaXJzdCBk ZXRhaWxlZCB0aW1pbmcgaXMgcHJlZmVycmVkIG1vZGUKKElJKSBSQURFT04oMCk6IHJlZFg6 IDAuNjQ1IHJlZFk6IDAuMzIxICAgZ3JlZW5YOiAwLjI4NSBncmVlblk6IDAuNjAwCihJSSkg UkFERU9OKDApOiBibHVlWDogMC4xNDIgYmx1ZVk6IDAuMDU3ICAgd2hpdGVYOiAwLjI4MyB3 aGl0ZVk6IDAuMjk4CihJSSkgUkFERU9OKDApOiBTdXBwb3J0ZWQgZXN0YWJsaXNoZWQgdGlt aW5nczoKKElJKSBSQURFT04oMCk6IDcyMHg0MDBANzBIegooSUkpIFJBREVPTigwKTogNjQw eDQ4MEA2MEh6CihJSSkgUkFERU9OKDApOiA2NDB4NDgwQDc1SHoKKElJKSBSQURFT04oMCk6 IDgwMHg2MDBANzVIegooSUkpIFJBREVPTigwKTogMTAyNHg3NjhANzVIegooSUkpIFJBREVP TigwKTogTWFudWZhY3R1cmVyJ3MgbWFzazogMAooSUkpIFJBREVPTigwKTogU3VwcG9ydGVk IHN0YW5kYXJkIHRpbWluZ3M6CihJSSkgUkFERU9OKDApOiAjMDogaHNpemU6IDY0MCAgdnNp emUgNDgwICByZWZyZXNoOiA4NSAgdmlkOiAyMjgzMwooSUkpIFJBREVPTigwKTogIzE6IGhz aXplOiA4MDAgIHZzaXplIDYwMCAgcmVmcmVzaDogODUgIHZpZDogMjI4NTMKKElJKSBSQURF T04oMCk6ICMyOiBoc2l6ZTogMTAyNCAgdnNpemUgNzY4ICByZWZyZXNoOiA4NSAgdmlkOiAy Mjg4MQooSUkpIFJBREVPTigwKTogIzM6IGhzaXplOiAxMjgwICB2c2l6ZSAxMDI0ICByZWZy ZXNoOiA2MCAgdmlkOiAzMjg5NwooSUkpIFJBREVPTigwKTogU3VwcG9ydGVkIGRldGFpbGVk IHRpbWluZzoKKElJKSBSQURFT04oMCk6IGNsb2NrOiA5NC41IE1IeiAgIEltYWdlIFNpemU6 ICAzMDYgeCAyMzAgbW0KKElJKSBSQURFT04oMCk6IGhfYWN0aXZlOiAxMDI0ICBoX3N5bmM6 IDEwNzIgIGhfc3luY19lbmQgMTE2OCBoX2JsYW5rX2VuZCAxMzc2IGhfYm9yZGVyOiAwCihJ SSkgUkFERU9OKDApOiB2X2FjdGl2ZTogNzY4ICB2X3N5bmM6IDc2OSAgdl9zeW5jX2VuZCA3 NzIgdl9ibGFua2luZzogODA4IHZfYm9yZGVyOiAwCihJSSkgUkFERU9OKDApOiBTZXJpYWwg Tm86IDAwMDAwMDAwMDAKKElJKSBSQURFT04oMCk6IFJhbmdlczogViBtaW46IDUwIFYgbWF4 OiAxNjAgSHosIEggbWluOiAzMCBIIG1heDogNzIga0h6LCBQaXhDbG9jayBtYXggMTEwIE1I egooSUkpIFJBREVPTigwKTogTW9uaXRvciBuYW1lOiA3MjBFCihJSSkgUkFERU9OKDApOiBF RElEIChpbiBoZXgpOgooSUkpIFJBREVPTigwKTogCTAwZmZmZmZmZmZmZmZmMDAyMjZjYjQw NjhlYTIwMTAwCihJSSkgUkFERU9OKDApOiAJMzQwYjAxMDIwODIwMTg3ZWVhMTI2OWE1NTI0 OTk5MjQKKElJKSBSQURFT04oMCk6IAkwZTQ4NGNhNDQyMDAzMTU5NDU1OTYxNTk4MTgwMDEw MQooSUkpIFJBREVPTigwKTogCTAxMDEwMTAxMDEwMWVhMjQwMDYwNDEwMDI4MzAzMDYwCihJ SSkgUkFERU9OKDApOiAJMTMwMDMyZTYxMDAwMDAxZTAwMDAwMGZmMDAzMDMwMzAKKElJKSBS QURFT04oMCk6IAkzMDMwMzAzMDMwMzAzMDBhMjAyMDAwMDAwMGZkMDAzMgooSUkpIFJBREVP TigwKTogCWEwMWU0ODBiMDAwYTIwMjAyMDIwMjAyMDAwMDAwMGZjCihJSSkgUkFERU9OKDAp OiAJMDAzNzMyMzA0NTBhMjAyMDIwMjAyMDIwMjAyMDAwYjEKKElJKSBSQURFT04oMCk6IEVE SUQgdmVuZG9yICJIU0wiLCBwcm9kIGlkIDE3MTYKKElJKSBSQURFT04oMCk6IE91dHB1dDog RFZJLTAsIERldGVjdGVkIE1vbml0b3IgVHlwZTogMAooSUkpIFJBREVPTigwKTogT3V0cHV0 IFZHQS0wIGNvbm5lY3RlZAooSUkpIFJBREVPTigwKTogT3V0cHV0IERWSS0wIGRpc2Nvbm5l Y3RlZAooSUkpIFJBREVPTigwKTogVXNpbmcgZXhhY3Qgc2l6ZXMgZm9yIGluaXRpYWwgbW9k ZXMKKElJKSBSQURFT04oMCk6IE91dHB1dCBWR0EtMCB1c2luZyBpbml0aWFsIG1vZGUgMTAy NHg3NjgKYWZ0ZXIgeGY4NkluaXRpYWxDb25maWd1cmF0aW9uCigqKikgUkFERU9OKDApOiBE aXNwbGF5IGRpbWVuc2lvbnM6ICgzMjAsIDI0MCkgbW0KKCoqKSBSQURFT04oMCk6IERQSSBz ZXQgdG8gKDEwMSwgMTM1KQooSUkpIExvYWRpbmcgc3ViIG1vZHVsZSAiZmIiCihJSSkgTG9h ZE1vZHVsZTogImZiIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVz Ly9saWJmYi5zbwooSUkpIE1vZHVsZSBmYjogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJ Y29tcGlsZWQgZm9yIDEuNi41LCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglBQkkgY2xhc3M6 IFguT3JnIEFOU0kgQyBFbXVsYXRpb24sIHZlcnNpb24gMC40Cig9PSkgUkFERU9OKDApOiBV c2luZyBnYW1tYSBjb3JyZWN0aW9uICgxLjAsIDEuMCwgMS4wKQooSUkpIExvYWRpbmcgc3Vi IG1vZHVsZSAicmFtZGFjIgooSUkpIExvYWRNb2R1bGU6ICJyYW1kYWMiCihJSSkgTW9kdWxl ICJyYW1kYWMiIGFscmVhZHkgYnVpbHQtaW4KKD09KSBSQURFT04oMCk6IFdpbGwgYXR0ZW1w dCB0byB1c2UgUjZ4eC9SN3h4IEVYQSBzdXBwb3J0IGlmIERSSSBpcyBlbmFibGVkLgooSUkp IExvYWRpbmcgc3ViIG1vZHVsZSAiZXhhIgooSUkpIExvYWRNb2R1bGU6ICJleGEiCihJSSkg TG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvL2xpYmV4YS5zbwooSUkpIE1v ZHVsZSBleGE6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjYu NSwgbW9kdWxlIHZlcnNpb24gPSAyLjQuMAoJQUJJIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2 ZXIsIHZlcnNpb24gNS4wCig9PSkgUkFERU9OKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2Ug KDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCighISkgUkFERU9OKDApOiBGb3IgaW5m b3JtYXRpb24gb24gdXNpbmcgdGhlIG11bHRpbWVkaWEgY2FwYWJpbGl0aWVzCglvZiB0aGlz IGFkYXB0ZXIsIHBsZWFzZSBzZWUgaHR0cDovL2dhdG9zLnNmLm5ldC4KKCEhKSBSQURFT04o MCk6IE1lcmdlZEZCIHN1cHBvcnQgaGFzIGJlZW4gcmVtb3ZlZCBhbmQgcmVwbGFjZWQgd2l0 aCB4cmFuZHIgMS4yIHN1cHBvcnQKKC0tKSBEZXB0aCAyNCBwaXhtYXAgZm9ybWF0IGlzIDMy IGJwcAooSUkpIGRvIEkgbmVlZCBSQUM/ICBObywgSSBkb24ndC4KKElJKSByZXNvdXJjZSBy YW5nZXMgYWZ0ZXIgcHJlSW5pdDoKCVswXSAtMQkwCTB4MDAwZjAwMDAgLSAweDAwMGZmZmZm ICgweDEwMDAwKSBNWFtCXQoJWzFdIC0xCTAJMHgwMDBjMDAwMCAtIDB4MDAwZWZmZmYgKDB4 MzAwMDApIE1YW0JdCglbMl0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDA5ZmZmZiAoMHhhMDAw MCkgTVhbQl0KCVszXSAwCTAJMHgwMDBhMDAwMCAtIDB4MDAwYWZmZmYgKDB4MTAwMDApIE1T W0JdCglbNF0gMAkwCTB4MDAwYjAwMDAgLSAweDAwMGI3ZmZmICgweDgwMDApIE1TW0JdCglb NV0gMAkwCTB4MDAwYjgwMDAgLSAweDAwMGJmZmZmICgweDgwMDApIE1TW0JdCglbNl0gLTEJ MAkweDAwMDBmZmZmIC0gMHgwMDAwZmZmZiAoMHgxKSBJWFtCXQoJWzddIC0xCTAJMHgwMDAw MDAwMCAtIDB4MDAwMDAwZmYgKDB4MTAwKSBJWFtCXQoJWzhdIDAJMAkweDAwMDAwM2IwIC0g MHgwMDAwMDNiYiAoMHhjKSBJU1tCXQoJWzldIDAJMAkweDAwMDAwM2MwIC0gMHgwMDAwMDNk ZiAoMHgyMCkgSVNbQl0KKElJKSBSQURFT04oMCk6IFJBREVPTlNjcmVlbkluaXQgZDAwMDAw MDAgMCAwCig9PSkgUkFERU9OKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4YTAwMDAs MHgxMDAwMCkgd2FzIGFscmVhZHkgY2xlYXIKT3V0cHV0IENSVDEgZGlzYWJsZSBzdWNjZXNz CkJsYW5rIENSVEMgMCBzdWNjZXNzCkRpc2FibGUgQ1JUQyAwIHN1Y2Nlc3MKRGlzYWJsZSBD UlRDIG1lbXJlcSAwIHN1Y2Nlc3MKQmxhbmsgQ1JUQyAxIHN1Y2Nlc3MKRGlzYWJsZSBDUlRD IDEgc3VjY2VzcwpEaXNhYmxlIENSVEMgbWVtcmVxIDEgc3VjY2VzcwooPT0pIFJBREVPTigw KTogVXNpbmcgMjQgYml0IGRlcHRoIGJ1ZmZlcgooSUkpIFJBREVPTigwKTogUkFERU9OSW5p dE1lbW9yeU1hcCgpIDogCihJSSkgUkFERU9OKDApOiAgIG1lbV9zaXplICAgICAgICAgOiAw eDIwMDAwMDAwCihJSSkgUkFERU9OKDApOiAgIE1DX0ZCX0xPQ0FUSU9OICAgOiAweDAwZGYw MGMwCihJSSkgUkFERU9OKDApOiAgIE1DX0FHUF9MT0NBVElPTiAgOiAweDAwM2YwMDAwCihJ SSkgUkFERU9OKDApOiBEZXB0aCBtb3ZlcyBkaXNhYmxlZCBieSBkZWZhdWx0CihJSSkgUkFE RU9OKDApOiBBbGxvY2F0aW5nIGZyb20gYSBzY3JlZW4gb2YgMjYyMDgwIGtiCihJSSkgUkFE RU9OKDApOiBXaWxsIHVzZSAzMiBrYiBmb3IgaGFyZHdhcmUgY3Vyc29yIDAgYXQgb2Zmc2V0 IDB4MDA2NDAwMDAKKElJKSBSQURFT04oMCk6IFdpbGwgdXNlIDMyIGtiIGZvciBoYXJkd2Fy ZSBjdXJzb3IgMSBhdCBvZmZzZXQgMHgwMDY0NDAwMAooSUkpIFJBREVPTigwKTogV2lsbCB1 c2UgNjQwMCBrYiBmb3IgZnJvbnQgYnVmZmVyIGF0IG9mZnNldCAweDAwMDAwMDAwCihJSSkg UkFERU9OKDApOiBXaWxsIHVzZSA2NCBrYiBmb3IgUENJIEdBUlQgYXQgb2Zmc2V0IDB4MGZm ZjAwMDAKKElJKSBSQURFT04oMCk6IFdpbGwgdXNlIDY0MDAga2IgZm9yIGJhY2sgYnVmZmVy IGF0IG9mZnNldCAweDAwNjQ4MDAwCihJSSkgUkFERU9OKDApOiBXaWxsIHVzZSA2NDAwIGti IGZvciBkZXB0aCBidWZmZXIgYXQgb2Zmc2V0IDB4MDBjODgwMDAKKElJKSBSQURFT04oMCk6 IFdpbGwgdXNlIDEyMDgzMiBrYiBmb3IgdGV4dHVyZXMgYXQgb2Zmc2V0IDB4MDEyYzgwMDAK KElJKSBSQURFT04oMCk6IFdpbGwgdXNlIDEyMjAxNiBrYiBmb3IgWCBTZXJ2ZXIgb2Zmc2Ny ZWVuIGF0IG9mZnNldCAweDA4OGM4MDAwCmRybU9wZW5EZXZpY2U6IG5vZGUgbmFtZSBpcyAv ZGV2L2RyaS9jYXJkMApkcm1PcGVuRGV2aWNlOiBvcGVuIHJlc3VsdCBpcyAxMCwgKE9LKQpk cm1PcGVuRGV2aWNlOiBub2RlIG5hbWUgaXMgL2Rldi9kcmkvY2FyZDAKZHJtT3BlbkRldmlj ZTogb3BlbiByZXN1bHQgaXMgMTAsIChPSykKZHJtT3BlbkJ5QnVzaWQ6IFNlYXJjaGluZyBm b3IgQnVzSUQgcGNpOjAwMDA6MDE6MDUuMApkcm1PcGVuRGV2aWNlOiBub2RlIG5hbWUgaXMg L2Rldi9kcmkvY2FyZDAKZHJtT3BlbkRldmljZTogb3BlbiByZXN1bHQgaXMgMTAsIChPSykK ZHJtT3BlbkJ5QnVzaWQ6IGRybU9wZW5NaW5vciByZXR1cm5zIDEwCmRybU9wZW5CeUJ1c2lk OiBkcm1HZXRCdXNpZCByZXBvcnRzIHBjaTowMDAwOjAxOjA1LjAKKElJKSBbZHJtXSBEUk0g aW50ZXJmYWNlIHZlcnNpb24gMS4yCihJSSkgW2RybV0gRFJNIG9wZW4gbWFzdGVyIHN1Y2Nl ZWRlZC4KKElJKSBSQURFT04oMCk6IFtkcm1dIFVzaW5nIHRoZSBEUk0gbG9jayBTQVJFQSBh bHNvIGZvciBkcmF3YWJsZXMuCihJSSkgUkFERU9OKDApOiBbZHJtXSBmcmFtZWJ1ZmZlciBo YW5kbGUgPSAweGQwMDAwMDAwCihJSSkgUkFERU9OKDApOiBbZHJtXSBhZGRlZCAxIHJlc2Vy dmVkIGNvbnRleHQgZm9yIGtlcm5lbAooSUkpIFJBREVPTigwKTogWCBjb250ZXh0IGhhbmRs ZSA9IDB4MQooSUkpIFJBREVPTigwKTogW2RybV0gaW5zdGFsbGVkIERSTSBzaWduYWwgaGFu ZGxlcgooSUkpIFJBREVPTigwKTogW3BjaV0gMzI3Njgga0IgYWxsb2NhdGVkIHdpdGggaGFu ZGxlIDB4NmEyYzMwMDAKKElJKSBSQURFT04oMCk6IFtwY2ldIHJpbmcgaGFuZGxlID0gMHg2 YTJjMzAwMAooSUkpIFJBREVPTigwKTogW3BjaV0gUmluZyBtYXBwZWQgYXQgMHg4MTJjMDAw MDAKKElJKSBSQURFT04oMCk6IFtwY2ldIFJpbmcgY29udGVudHMgMHgwMDAwMDAwMAooSUkp IFJBREVPTigwKTogW3BjaV0gcmluZyByZWFkIHB0ciBoYW5kbGUgPSAweDZhM2M0MDAwCihJ SSkgUkFERU9OKDApOiBbcGNpXSBSaW5nIHJlYWQgcHRyIG1hcHBlZCBhdCAweDgwMDZkMDAw MAooSUkpIFJBREVPTigwKTogW3BjaV0gUmluZyByZWFkIHB0ciBjb250ZW50cyAweDAwMDAw MDAwCihJSSkgUkFERU9OKDApOiBbcGNpXSB2ZXJ0ZXgvaW5kaXJlY3QgYnVmZmVycyBoYW5k bGUgPSAweDZhM2M1MDAwCihJSSkgUkFERU9OKDApOiBbcGNpXSBWZXJ0ZXgvaW5kaXJlY3Qg YnVmZmVycyBtYXBwZWQgYXQgMHg4MTJkMDEwMDAKKElJKSBSQURFT04oMCk6IFtwY2ldIFZl cnRleC9pbmRpcmVjdCBidWZmZXJzIGNvbnRlbnRzIDB4MDAwMDAwMDAKKElJKSBSQURFT04o MCk6IFtwY2ldIEdBUlQgdGV4dHVyZSBtYXAgaGFuZGxlID0gMHg2YTVjNTAwMAooSUkpIFJB REVPTigwKTogW3BjaV0gR0FSVCBUZXh0dXJlIG1hcCBtYXBwZWQgYXQgMHg4MTJmYzUwMDAK KElJKSBSQURFT04oMCk6IFtkcm1dIHJlZ2lzdGVyIGhhbmRsZSA9IDB4ZmRmZTAwMDAKKElJ KSBSQURFT04oMCk6IFtkcmldIFZpc3VhbCBjb25maWdzIGluaXRpYWxpemVkCihJSSkgUkFE RU9OKDApOiBSQURFT05SZXN0b3JlTWVtTWFwUmVnaXN0ZXJzKCkgOiAKKElJKSBSQURFT04o MCk6ICAgTUNfRkJfTE9DQVRJT04gICA6IDB4MDBkZjAwYzAgMHgwMGRmMDBjMAooSUkpIFJB REVPTigwKTogICBNQ19BR1BfTE9DQVRJT04gIDogMHgwMDNmMDAwMAooPT0pIFJBREVPTigw KTogQmFja2luZyBzdG9yZSBkaXNhYmxlZAooSUkpIFJBREVPTigwKTogW0RSSV0gaW5zdGFs bGF0aW9uIGNvbXBsZXRlCihJSSkgUkFERU9OKDApOiBbZHJtXSBBZGRlZCAzMiA2NTUzNiBi eXRlIHZlcnRleC9pbmRpcmVjdCBidWZmZXJzCihJSSkgUkFERU9OKDApOiBbZHJtXSBNYXBw ZWQgMzIgdmVydGV4L2luZGlyZWN0IGJ1ZmZlcnMKKElJKSBSQURFT04oMCk6IFtkcm1dIGRt YSBjb250cm9sIGluaXRpYWxpemVkLCB1c2luZyBJUlEgMjU4CihJSSkgUkFERU9OKDApOiBb ZHJtXSBJbml0aWFsaXplZCBrZXJuZWwgR0FSVCBoZWFwIG1hbmFnZXIsIDI5ODg0NDE2CihX VykgUkFERU9OKDApOiBEUkkgaW5pdCBjaGFuZ2VkIG1lbW9yeSBtYXAsIGFkanVzdGluZyAu Li4KKFdXKSBSQURFT04oMCk6ICAgTUNfRkJfTE9DQVRJT04gIHdhczogMHgwMGRmMDBjMCBp czogMHgwMGRmMDBjMAooV1cpIFJBREVPTigwKTogICBNQ19BR1BfTE9DQVRJT04gd2FzOiAw eDAwM2YwMDAwIGlzOiAweDAwMDMwMDAwCihJSSkgUkFERU9OKDApOiBSQURFT05SZXN0b3Jl TWVtTWFwUmVnaXN0ZXJzKCkgOiAKKElJKSBSQURFT04oMCk6ICAgTUNfRkJfTE9DQVRJT04g ICA6IDB4MDBkZjAwYzAgMHgwMGRmMDBjMAooSUkpIFJBREVPTigwKTogICBNQ19BR1BfTE9D QVRJT04gIDogMHgwMDAzMDAwMAooSUkpIFJBREVPTigwKTogRGlyZWN0IHJlbmRlcmluZyBl bmFibGVkCihJSSkgUkFERU9OKDApOiBTZXR0aW5nIEVYQSBtYXhQaXRjaEJ5dGVzCihJSSkg RVhBKDApOiBPZmZzY3JlZW4gcGl4bWFwIGFyZWEgb2YgMTI0OTQ0Mzg0IGJ5dGVzCihJSSkg RVhBKDApOiBEcml2ZXIgcmVnaXN0ZXJlZCBzdXBwb3J0IGZvciB0aGUgZm9sbG93aW5nIG9w ZXJhdGlvbnM6CihJSSkgICAgICAgICBTb2xpZAooSUkpICAgICAgICAgQ29weQooSUkpICAg ICAgICAgQ29tcG9zaXRlIChSRU5ERVIgYWNjZWxlcmF0aW9uKQooSUkpICAgICAgICAgVXBs b2FkVG9TY3JlZW4KKElJKSAgICAgICAgIERvd25sb2FkRnJvbVNjcmVlbgooSUkpIFJBREVP TigwKTogQWNjZWxlcmF0aW9uIGVuYWJsZWQKKCoqKSBPcHRpb24gImRwbXMiCigqKikgUkFE RU9OKDApOiBEUE1TIGVuYWJsZWQKKD09KSBSQURFT04oMCk6IFNpbGtlbiBtb3VzZSBlbmFi bGVkCihJSSkgUkFERU9OKDApOiBTZXQgdXAgdGV4dHVyZWQgdmlkZW8KT3V0cHV0IENSVDEg ZGlzYWJsZSBzdWNjZXNzCihJSSkgUkFERU9OKDApOiBESUcwIHRyYW5zbWl0dGVyOiBDb2hl cmVudCBNb2RlIGVuYWJsZWQKT3V0cHV0IERJRzAgdHJhbnNtaXR0ZXIgc2V0dXAgc3VjY2Vz cwpCbGFuayBDUlRDIDAgc3VjY2VzcwpEaXNhYmxlIENSVEMgMCBzdWNjZXNzCkRpc2FibGUg Q1JUQyBtZW1yZXEgMCBzdWNjZXNzCkJsYW5rIENSVEMgMSBzdWNjZXNzCkRpc2FibGUgQ1JU QyAxIHN1Y2Nlc3MKRGlzYWJsZSBDUlRDIG1lbXJlcSAxIHN1Y2Nlc3MKT3V0cHV0IENSVDEg ZGlzYWJsZSBzdWNjZXNzCkJsYW5rIENSVEMgMCBzdWNjZXNzCkRpc2FibGUgQ1JUQyAwIHN1 Y2Nlc3MKRGlzYWJsZSBDUlRDIG1lbXJlcSAwIHN1Y2Nlc3MKTW9kZSAxMDI0eDc2OCAtIDEz NzYgODA4IDUKKElJKSBSQURFT04oMCk6IFJBREVPTlJlc3RvcmVNZW1NYXBSZWdpc3RlcnMo KSA6IAooSUkpIFJBREVPTigwKTogICBNQ19GQl9MT0NBVElPTiAgIDogMHgwMGRmMDBjMCAw eDAwZGYwMGMwCihJSSkgUkFERU9OKDApOiAgIE1DX0FHUF9MT0NBVElPTiAgOiAweDAwMDMw MDAwCmZyZXE6IDk0NTAwMDAwCmJlc3RfZnJlcTogOTQ0OTAzMDMKYmVzdF9mZWVkYmFja19k aXY6IDg3MQpiZXN0X3JlZl9kaXY6IDEyCmJlc3RfcG9zdF9kaXY6IDExCihJSSkgUkFERU9O KDApOiBjcnRjKDApIENsb2NrOiBtb2RlIDk0NTAwLCBQTEwgOTQ0OTAKKElJKSBSQURFT04o MCk6IGNydGMoMCkgUExMICA6IHJlZmRpdiAxMiwgZmJkaXYgMHgzNjcoODcxKSwgcGRpdiAx MQpTZXQgQ1JUQyAwIFBMTCBzdWNjZXNzClNldCBDUlRDIFRpbWluZyBzdWNjZXNzClNldCBD UlRDIDAgT3ZlcnNjYW4gc3VjY2VzcwpOb3QgdXNpbmcgUk1YCnNjYWxlciAwIHNldHVwIHN1 Y2Nlc3MKU2V0IENSVEMgMCBTb3VyY2Ugc3VjY2VzcwpjcnRjIDAgWVVWIGRpc2FibGUgc2V0 dXAgc3VjY2VzcwpPdXRwdXQgREFDMSBzZXR1cCBzdWNjZXNzCk91dHB1dCBDUlQxIGVuYWJs ZSBzdWNjZXNzCkVuYWJsZSBDUlRDIG1lbXJlcSAwIHN1Y2Nlc3MKRW5hYmxlIENSVEMgMCBz dWNjZXNzClVuYmxhbmsgQ1JUQyAwIHN1Y2Nlc3MKKElJKSBSQURFT04oMCk6IERJRzAgdHJh bnNtaXR0ZXI6IENvaGVyZW50IE1vZGUgZW5hYmxlZApPdXRwdXQgRElHMCB0cmFuc21pdHRl ciBzZXR1cCBzdWNjZXNzCkJsYW5rIENSVEMgMSBzdWNjZXNzCkRpc2FibGUgQ1JUQyAxIHN1 Y2Nlc3MKRGlzYWJsZSBDUlRDIG1lbXJlcSAxIHN1Y2Nlc3MKKElJKSBSQURFT04oMCk6IFJh bmRSIDEuMiBlbmFibGVkLCBpZ25vcmUgdGhlIGZvbGxvd2luZyBSYW5kUiBkaXNhYmxlZCBt ZXNzYWdlLgooLS0pIFJhbmRSIGRpc2FibGVkCihJSSkgU2V0dGluZyB2Z2EgZm9yIHNjcmVl biAwLgooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gR2VuZXJpYyBFdmVu dCBFeHRlbnNpb24KKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFNIQVBF CihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBNSVQtU0hNCihJSSkgSW5p dGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYSW5wdXRFeHRlbnNpb24KKElJKSBJbml0 aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhURVNUCihJSSkgSW5pdGlhbGl6aW5nIGJ1 aWx0LWluIGV4dGVuc2lvbiBCSUctUkVRVUVTVFMKKElJKSBJbml0aWFsaXppbmcgYnVpbHQt aW4gZXh0ZW5zaW9uIFNZTkMKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9u IFhLRVlCT0FSRAooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gWEMtTUlT QwooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gWElORVJBTUEKKElJKSBJ bml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhGSVhFUwooSUkpIEluaXRpYWxpemlu ZyBidWlsdC1pbiBleHRlbnNpb24gUkVOREVSCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWlu IGV4dGVuc2lvbiBSQU5EUgooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24g Q09NUE9TSVRFCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBEQU1BR0UK KElJKSBBSUdMWDogTG9hZGVkIGFuZCBpbml0aWFsaXplZCAvdXNyL2xvY2FsL2xpYi9kcmkv c3dyYXN0X2RyaS5zbwooSUkpIEdMWDogSW5pdGlhbGl6ZWQgRFJJU1dSQVNUIEdMIHByb3Zp ZGVyIGZvciBzY3JlZW4gMAooSUkpIFJBREVPTigwKTogU2V0dGluZyBzY3JlZW4gcGh5c2lj YWwgc2l6ZSB0byAzMDYgeCAyMzAKKElJKSBjb25maWcvaGFsOiBBZGRpbmcgaW5wdXQgZGV2 aWNlIEFUIEtleWJvYXJkCihJSSkgTG9hZE1vZHVsZTogImtiZCIKKElJKSBMb2FkaW5nIC91 c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9pbnB1dC8va2JkX2Rydi5zbwooSUkpIE1vZHVs ZSBrYmQ6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjYuNSwg bW9kdWxlIHZlcnNpb24gPSAxLjMuMgoJTW9kdWxlIGNsYXNzOiBYLk9yZyBYSW5wdXQgRHJp dmVyCglBQkkgY2xhc3M6IFguT3JnIFhJbnB1dCBkcml2ZXIsIHZlcnNpb24gNC4wCigqKikg QVQgS2V5Ym9hcmQ6IGFsd2F5cyByZXBvcnRzIGNvcmUgZXZlbnRzCigqKikgT3B0aW9uICJQ cm90b2NvbCIgInN0YW5kYXJkIgooKiopIEFUIEtleWJvYXJkOiBQcm90b2NvbDogc3RhbmRh cmQKKCoqKSBPcHRpb24gIkF1dG9SZXBlYXQiICI1MDAgMzAiCigqKikgT3B0aW9uICJYa2JS dWxlcyIgInhvcmciCigqKikgQVQgS2V5Ym9hcmQ6IFhrYlJ1bGVzOiAieG9yZyIKKCoqKSBP cHRpb24gIlhrYk1vZGVsIiAicGMxMDUiCigqKikgQVQgS2V5Ym9hcmQ6IFhrYk1vZGVsOiAi cGMxMDUiCigqKikgT3B0aW9uICJYa2JMYXlvdXQiICJ1cyIKKCoqKSBBVCBLZXlib2FyZDog WGtiTGF5b3V0OiAidXMiCigqKikgT3B0aW9uICJDdXN0b21LZXljb2RlcyIgIm9mZiIKKCoq KSBBVCBLZXlib2FyZDogQ3VzdG9tS2V5Y29kZXMgZGlzYWJsZWQKKElJKSBYSU5QVVQ6IEFk ZGluZyBleHRlbmRlZCBpbnB1dCBkZXZpY2UgIkFUIEtleWJvYXJkIiAodHlwZTogS0VZQk9B UkQpCihJSSkgY29uZmlnL2hhbDogQWRkaW5nIGlucHV0IGRldmljZSBQUy8yIE1vdXNlCihJ SSkgTG9hZE1vZHVsZTogIm1vdXNlIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9y Zy9tb2R1bGVzL2lucHV0Ly9tb3VzZV9kcnYuc28KKElJKSBNb2R1bGUgbW91c2U6IHZlbmRv cj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjYuNSwgbW9kdWxlIHZlcnNp b24gPSAxLjQuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBYSW5wdXQgRHJpdmVyCglBQkkgY2xh c3M6IFguT3JnIFhJbnB1dCBkcml2ZXIsIHZlcnNpb24gNC4wCigqKikgUFMvMiBNb3VzZTog RGV2aWNlOiAiL2Rldi9zeXNtb3VzZSIKKD09KSBQUy8yIE1vdXNlOiBQcm90b2NvbDogIkF1 dG8iCigqKikgUFMvMiBNb3VzZTogYWx3YXlzIHJlcG9ydHMgY29yZSBldmVudHMKKCoqKSBP cHRpb24gIkRldmljZSIgIi9kZXYvc3lzbW91c2UiCig9PSkgUFMvMiBNb3VzZTogRW11bGF0 ZTNCdXR0b25zLCBFbXVsYXRlM1RpbWVvdXQ6IDUwCigqKikgUFMvMiBNb3VzZTogWkF4aXNN YXBwaW5nOiBidXR0b25zIDQgYW5kIDUKKCoqKSBQUy8yIE1vdXNlOiBCdXR0b25zOiA5Cigq KikgUFMvMiBNb3VzZTogU2Vuc2l0aXZpdHk6IDEKKElJKSBYSU5QVVQ6IEFkZGluZyBleHRl bmRlZCBpbnB1dCBkZXZpY2UgIlBTLzIgTW91c2UiICh0eXBlOiBNT1VTRSkKKCoqKSBQUy8y IE1vdXNlOiAoYWNjZWwpIGtlZXBpbmcgYWNjZWxlcmF0aW9uIHNjaGVtZSAxCigqKikgUFMv MiBNb3VzZTogKGFjY2VsKSBmaWx0ZXIgY2hhaW4gcHJvZ3Jlc3Npb246IDIuMDAKKCoqKSBQ Uy8yIE1vdXNlOiAoYWNjZWwpIGZpbHRlciBzdGFnZSAwOiAyMC4wMCBtcwooKiopIFBTLzIg TW91c2U6IChhY2NlbCkgc2V0IGFjY2VsZXJhdGlvbiBwcm9maWxlIDAKKElJKSBQUy8yIE1v dXNlOiBTZXR1cEF1dG86IGh3LmlmdHlwZSBpcyA0LCBody5tb2RlbCBpcyAwCihJSSkgUFMv MiBNb3VzZTogU2V0dXBBdXRvOiBwcm90b2NvbCBpcyBTeXNNb3VzZQpPdXRwdXQgQ1JUMSBk aXNhYmxlIHN1Y2Nlc3MKQmxhbmsgQ1JUQyAwIHN1Y2Nlc3MKRGlzYWJsZSBDUlRDIDAgc3Vj Y2VzcwpEaXNhYmxlIENSVEMgbWVtcmVxIDAgc3VjY2VzcwpCbGFuayBDUlRDIDEgc3VjY2Vz cwpEaXNhYmxlIENSVEMgMSBzdWNjZXNzCkRpc2FibGUgQ1JUQyBtZW1yZXEgMSBzdWNjZXNz CihJSSkgUkFERU9OKDApOiBSQURFT05SZXN0b3JlTWVtTWFwUmVnaXN0ZXJzKCkgOiAKKElJ KSBSQURFT04oMCk6ICAgTUNfRkJfTE9DQVRJT04gICA6IDB4MDBkZjAwYzAgMHgwMGRmMDBj MAooSUkpIFJBREVPTigwKTogICBNQ19BR1BfTE9DQVRJT04gIDogMHgwMDAwMDAwMAooSUkp IFJBREVPTigwKTogYXZpdm9fcmVzdG9yZSAhCkVuYWJsZSBDUlRDIG1lbXJlcSAwIHN1Y2Nl c3MKRW5hYmxlIENSVEMgMCBzdWNjZXNzClVuYmxhbmsgQ1JUQyAwIHN1Y2Nlc3MKKD09KSBS QURFT04oMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHhhMDAwMCwweDEwMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgooSUkpIFVubG9hZE1vZHVsZTogIm1vdXNlIgooSUkpIFVubG9hZE1v ZHVsZTogImtiZCIKKElJKSBSQURFT04oMCk6IFtkcm1dIHJlbW92ZWQgMSByZXNlcnZlZCBj b250ZXh0IGZvciBrZXJuZWwKKElJKSBSQURFT04oMCk6IFtkcm1dIHVubWFwcGluZyA4MTky IGJ5dGVzIG9mIFNBUkVBIDB4ZmZmZmZmODAwMzY4ZTAwMCBhdCAweDgwMDZjZTAwMAooSUkp IFJBREVPTigwKTogW2RybV0gQ2xvc2VkIERSTSBtYXN0ZXIuCg== --------------080008080901030604030004 Content-Type: text/plain; name="Xorg.aticard.vesadriver.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Xorg.aticard.vesadriver.txt" X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Feb 16 19:28:48 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 14 February 2010 03:35:44PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Feb 16 19:59:12 2010 (++) Using config file: "/root/xorg.conf.new" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/75dpi/"). (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/75dpi/"). (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF (**) ModulePath set to "/usr/local/lib/xorg/modules" (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 (II) Loader magic: 0x3560 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0:1:5:0) 1002:9610:1458:d000 ATI Technologies Inc Radeon HD 3200 Graphics rev 0, Mem @ 0xd0000000/268435456, 0xfdfe0000/65536, 0xfde00000/1048576, I/O @ 0x0000ee00/256, BIOS @ 0x????????/65536 (II) System resource ranges: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "vesa" (II) Loading /usr/local/lib/xorg/modules/drivers//vesa_drv.so (II) Module vesa: vendor="X.Org Foundation" compiled for 1.6.5, module version = 2.1.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) VESA: driver for VESA chipsets: vesa (II) Primary Device is: PCI 01@00:05:0 (II) resource ranges after probing: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/local/lib/xorg/modules//libvbe.so (II) Module vbe: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org Video Driver, version 5.0 (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) VESA(0): initializing int10 (==) VESA(0): Write-combining range (0xa0000,0x20000) was already clear (==) VESA(0): Write-combining range (0xc0000,0x40000) was already clear (II) VESA(0): Primary V_BIOS segment is: 0xc000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 16384 kB (II) VESA(0): VESA VBE OEM: ATI ATOMBIOS (II) VESA(0): VESA VBE OEM Software Rev: 10.87 (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc. (II) VESA(0): VESA VBE OEM Product: RS780 (II) VESA(0): VESA VBE OEM Product Rev: 01.00 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Depth 24, (--) framebuffer bpp 32 (==) VESA(0): RGB weight 888 (==) VESA(0): Default visual is TrueColor (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA VBE DDC supported (II) VESA(0): VESA VBE DDC Level 2 (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec. (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA VBE DDC read successfully (II) VESA(0): Manufacturer: HSL Model: 6b4 Serial#: 107150 (II) VESA(0): Year: 2001 Week: 52 (II) VESA(0): EDID Version: 1.2 (II) VESA(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) VESA(0): Sync: Separate (II) VESA(0): Max Image Size [cm]: horiz.: 32 vert.: 24 (II) VESA(0): Gamma: 2.26 (II) VESA(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) VESA(0): First detailed timing is preferred mode (II) VESA(0): redX: 0.645 redY: 0.321 greenX: 0.285 greenY: 0.600 (II) VESA(0): blueX: 0.142 blueY: 0.057 whiteX: 0.283 whiteY: 0.298 (II) VESA(0): Supported established timings: (II) VESA(0): 720x400@70Hz (II) VESA(0): 640x480@60Hz (II) VESA(0): 640x480@75Hz (II) VESA(0): 800x600@75Hz (II) VESA(0): 1024x768@75Hz (II) VESA(0): Manufacturer's mask: 0 (II) VESA(0): Supported standard timings: (II) VESA(0): #0: hsize: 640 vsize 480 refresh: 85 vid: 22833 (II) VESA(0): #1: hsize: 800 vsize 600 refresh: 85 vid: 22853 (II) VESA(0): #2: hsize: 1024 vsize 768 refresh: 85 vid: 22881 (II) VESA(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) VESA(0): Supported detailed timing: (II) VESA(0): clock: 94.5 MHz Image Size: 306 x 230 mm (II) VESA(0): h_active: 1024 h_sync: 1072 h_sync_end 1168 h_blank_end 1376 h_border: 0 (II) VESA(0): v_active: 768 v_sync: 769 v_sync_end 772 v_blanking: 808 v_border: 0 (II) VESA(0): Serial No: 0000000000 (II) VESA(0): Ranges: V min: 50 V max: 160 Hz, H min: 30 H max: 72 kHz, PixClock max 110 MHz (II) VESA(0): Monitor name: 720E (II) VESA(0): EDID (in hex): (II) VESA(0): 00ffffffffffff00226cb4068ea20100 (II) VESA(0): 340b01020820187eea1269a552499924 (II) VESA(0): 0e484ca4420031594559615981800101 (II) VESA(0): 010101010101ea240060410028303060 (II) VESA(0): 130032e61000001e000000ff00303030 (II) VESA(0): 303030303030300a2020000000fd0032 (II) VESA(0): a01e480b000a202020202020000000fc (II) VESA(0): 00373230450a202020202020202000b1 (II) VESA(0): EDID vendor "HSL", prod id 1716 (II) VESA(0): Using hsync ranges from config file (II) VESA(0): Using vrefresh ranges from config file (II) VESA(0): Printing DDC gathered Modelines: (II) VESA(0): Modeline "1024x768"x0.0 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (68.7 kHz) (II) VESA(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) VESA(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) VESA(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) VESA(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) VESA(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) VESA(0): Modeline "640x480"x0.0 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (43.3 kHz) (II) VESA(0): Modeline "800x600"x0.0 56.25 800 832 896 1048 600 601 604 631 +hsync +vsync (53.7 kHz) (II) VESA(0): Modeline "1024x768"x0.0 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (68.7 kHz) (II) VESA(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) VESA(0): Searching for matching VESA mode(s): (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 100 (640x400) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 640 XResolution: 640 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 63 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 63 LinNumberOfImagePages: 63 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 101 (640x480) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 640 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 50 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 50 LinNumberOfImagePages: 50 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 103 (800x600) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 832 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 31 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 832 BnkNumberOfImagePages: 31 LinNumberOfImagePages: 31 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 105 (1024x768) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1024 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 18 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 18 LinNumberOfImagePages: 18 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 107 (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1280 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 11 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 11 LinNumberOfImagePages: 11 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 111 (640x480) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1280 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 24 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 24 LinNumberOfImagePages: 24 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 114 (800x600) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1600 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 16 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 16 LinNumberOfImagePages: 16 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 117 (1024x768) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2048 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 9 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 9 LinNumberOfImagePages: 9 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 11a (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2560 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 5 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 10e (320x200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 640 XResolution: 320 YResolution: 200 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 127 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 127 LinNumberOfImagePages: 127 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 120 (320x200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1280 XResolution: 320 YResolution: 200 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 63 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 63 LinNumberOfImagePages: 63 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 193 (320x240) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 320 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 127 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 320 BnkNumberOfImagePages: 127 LinNumberOfImagePages: 127 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 195 (320x240) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 640 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 84 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 84 LinNumberOfImagePages: 84 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 196 (320x240) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1280 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 50 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 50 LinNumberOfImagePages: 50 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1b3 (512x384) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 512 XResolution: 512 YResolution: 384 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 63 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 512 BnkNumberOfImagePages: 63 LinNumberOfImagePages: 63 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1b5 (512x384) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1024 XResolution: 512 YResolution: 384 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 35 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 35 LinNumberOfImagePages: 35 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 1b6 (512x384) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2048 XResolution: 512 YResolution: 384 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 18 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 18 LinNumberOfImagePages: 18 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1c3 (640x350) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 640 XResolution: 640 YResolution: 350 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 63 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 63 LinNumberOfImagePages: 63 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1c5 (640x350) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1280 XResolution: 640 YResolution: 350 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 35 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 35 LinNumberOfImagePages: 35 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 1c6 (640x350) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2560 XResolution: 640 YResolution: 350 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 17 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 17 LinNumberOfImagePages: 17 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 133 (720x400) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 768 XResolution: 720 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 50 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 768 BnkNumberOfImagePages: 50 LinNumberOfImagePages: 50 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 135 (720x400) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1472 XResolution: 720 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 27 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1472 BnkNumberOfImagePages: 27 LinNumberOfImagePages: 27 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 136 (720x400) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2944 XResolution: 720 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 13 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2944 BnkNumberOfImagePages: 13 LinNumberOfImagePages: 13 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 153 (1152x864) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1152 XResolution: 1152 YResolution: 864 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 15 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1152 BnkNumberOfImagePages: 15 LinNumberOfImagePages: 15 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 155 (1152x864) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2304 XResolution: 1152 YResolution: 864 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 7 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2304 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 156 (1152x864) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 4608 XResolution: 1152 YResolution: 864 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 4608 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 163 (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1280 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 11 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 11 LinNumberOfImagePages: 11 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 165 (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2560 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 5 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 166 (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 5120 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 5120 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 121 (640x480) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2560 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 12 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 12 LinNumberOfImagePages: 12 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 122 (800x600) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 3200 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 7 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 123 (1024x768) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 4096 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 4 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 4096 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 124 (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 5120 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 5120 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 143 (1400x1050) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1408 XResolution: 1400 YResolution: 1050 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 10 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1408 BnkNumberOfImagePages: 10 LinNumberOfImagePages: 10 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 145 (1400x1050) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 2816 XResolution: 1400 YResolution: 1050 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 4 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2816 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 146 (1400x1050) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 5632 XResolution: 1400 YResolution: 1050 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 5632 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 173 (1600x1200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1600 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 7 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 175 (1600x1200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 3200 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 176 (1600x1200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 6400 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 6400 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 183 (1792x1344) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1792 XResolution: 1792 YResolution: 1344 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 5 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1792 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 185 (1792x1344) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 3584 XResolution: 1792 YResolution: 1344 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3584 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 186 (1792x1344) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 7168 XResolution: 1792 YResolution: 1344 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 7168 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1d3 (1856x1392) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1856 XResolution: 1856 YResolution: 1392 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 5 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1856 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1d5 (1856x1392) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 3712 XResolution: 1856 YResolution: 1392 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3712 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 1d6 (1856x1392) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 7424 XResolution: 1856 YResolution: 1392 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 7424 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1e3 (1920x1440) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 1920 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 4 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1920 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1e5 (1920x1440) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 3840 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3840 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 1e6 (1920x1440) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0005179 BytesPerScanline: 7680 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 7680 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (II) VESA(0): Total Memory: 256 64KB banks (16384kB) (II) VESA(0): Monitor0: Using hsync range of 30.00-72.00 kHz (II) VESA(0): Monitor0: Using vrefresh range of 50.00-160.00 Hz (II) VESA(0): Monitor0: Using maximum pixel clock of 110.00 MHz (WW) VESA(0): Unable to estimate virtual size (II) VESA(0): Not using built-in mode "1920x1440" (no mode of this name) (II) VESA(0): Not using built-in mode "1856x1392" (no mode of this name) (II) VESA(0): Not using built-in mode "1792x1344" (no mode of this name) (II) VESA(0): Not using built-in mode "1600x1200" (no mode of this name) (II) VESA(0): Not using built-in mode "1400x1050" (no mode of this name) (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Not using built-in mode "1152x864" (no mode of this name) (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Not using built-in mode "640x350" (no mode of this name) (II) VESA(0): Not using built-in mode "512x384" (no mode of this name) (II) VESA(0): Not using built-in mode "320x240" (no mode of this name) (II) VESA(0): Not using built-in mode "320x200" (no mode of this name) (--) VESA(0): Virtual size is 1280x1024 (pitch 1280) (**) VESA(0): *Built-in mode "1280x1024" (**) VESA(0): *Built-in mode "1280x1024" (**) VESA(0): *Built-in mode "1024x768" (**) VESA(0): *Built-in mode "800x600" (**) VESA(0): *Built-in mode "640x480" (**) VESA(0): *Built-in mode "720x400" (**) VESA(0): Display dimensions: (320, 240) mm (**) VESA(0): DPI set to (101, 108) (**) VESA(0): Using "Shadow Framebuffer" (II) Loading sub module "shadow" (II) LoadModule: "shadow" (II) Loading /usr/local/lib/xorg/modules//libshadow.so (II) Module shadow: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/local/lib/xorg/modules//libint10.so (II) VESA(0): initializing int10 (==) VESA(0): Write-combining range (0xa0000,0x20000) was already clear (II) VESA(0): Primary V_BIOS segment is: 0xc000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 16384 kB (II) VESA(0): VESA VBE OEM: ATI ATOMBIOS (II) VESA(0): VESA VBE OEM Software Rev: 10.87 (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc. (II) VESA(0): VESA VBE OEM Product: RS780 (II) VESA(0): VESA VBE OEM Product Rev: 01.00 (II) VESA(0): virtual address = 0x802c00000, physical address = 0xd0000000, size = 16777216 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Setting up VESA Mode 0x166 (1280x1024) (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VBESetVBEMode failed(==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear ...Tried again without customized values. (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Default visual is TrueColor (==) VESA(0): Backing store disabled (**) Option "dpms" (**) VESA(0): DPMS enabled (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) config/hal: Adding input device AT Keyboard (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (**) AT Keyboard: always reports core events (**) Option "Protocol" "standard" (**) AT Keyboard: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) AT Keyboard: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) AT Keyboard: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) AT Keyboard: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) AT Keyboard: CustomKeycodes disabled (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD) (II) config/hal: Adding input device PS/2 Mouse (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (**) PS/2 Mouse: Device: "/dev/sysmouse" (==) PS/2 Mouse: Protocol: "Auto" (**) PS/2 Mouse: always reports core events (**) Option "Device" "/dev/sysmouse" (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 (**) PS/2 Mouse: Buttons: 9 (**) PS/2 Mouse: Sensitivity: 1 (II) XINPUT: Adding extended input device "PS/2 Mouse" (type: MOUSE) (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 (**) PS/2 Mouse: (accel) filter chain progression: 2.00 (**) PS/2 Mouse: (accel) filter stage 0: 20.00 ms (**) PS/2 Mouse: (accel) set acceleration profile 0 (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is 0 (II) PS/2 Mouse: SetupAuto: protocol is SysMouse (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) UnloadModule: "mouse" (II) UnloadModule: "kbd" --------------080008080901030604030004 Content-Type: text/plain; name="xorg.conf.default" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xorg.conf.default" Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "extmod" Load "dri2" Load "glx" Load "dbe" Load "dri" Load "record" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" #DisplaySize 320 240 # mm Identifier "Monitor0" VendorName "HSL" ModelName "720E" HorizSync 30.0 - 72.0 VertRefresh 50.0 - 160.0 Option "DPMS" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "Dac6Bit" # [] #Option "Dac8Bit" # [] #Option "BusType" # [] #Option "CPPIOMode" # [] #Option "CPusecTimeout" # #Option "AGPMode" # #Option "AGPFastWrite" # [] #Option "AGPSize" # #Option "GARTSize" # #Option "RingSize" # #Option "BufferSize" # #Option "EnableDepthMoves" # [] #Option "EnablePageFlip" # [] #Option "NoBackBuffer" # [] #Option "DMAForXv" # [] #Option "FBTexPercent" # #Option "DepthBits" # #Option "PCIAPERSize" # #Option "AccelDFS" # [] #Option "IgnoreEDID" # [] #Option "DisplayPriority" # [] #Option "PanelSize" # [] #Option "ForceMinDotClock" # #Option "ColorTiling" # [] #Option "VideoKey" # #Option "RageTheatreCrystal" # #Option "RageTheatreTunerPort" # #Option "RageTheatreCompositePort" # #Option "RageTheatreSVideoPort" # #Option "TunerType" # #Option "RageTheatreMicrocPath" # #Option "RageTheatreMicrocType" # #Option "ScalerWidth" # #Option "RenderAccel" # [] #Option "SubPixelOrder" # [] #Option "ShowCache" # [] #Option "DynamicClocks" # [] #Option "VGAAccess" # [] #Option "ReverseDDC" # [] #Option "LVDSProbePLL" # [] #Option "AccelMethod" # #Option "DRI" # [] #Option "ConnectorTable" # #Option "DefaultConnectorTable" # [] #Option "DefaultTMDSPLL" # [] #Option "TVDACLoadDetect" # [] #Option "ForceTVOut" # [] #Option "TVStandard" # #Option "IgnoreLidStatus" # [] #Option "DefaultTVDACAdj" # [] #Option "Int10" # [] #Option "EXAVSync" # [] #Option "ATOMTVOut" # [] #Option "R4xxATOM" # [] Identifier "Card0" Driver "vesa" VendorName "ATI Technologies Inc" BoardName "Radeon HD 3200 Graphics" # BusID "PCI:1:5:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection --------------080008080901030604030004 Content-Type: text/plain; name="Xorg.nvidia.log.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Xorg.nvidia.log.txt" X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Feb 16 19:28:48 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 14 February 2010 03:35:44PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Feb 16 19:45:53 2010 (++) Using config file: "/root/xorg.conf.new" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/75dpi/"). (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/75dpi/"). (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF (**) ModulePath set to "/usr/local/lib/xorg/modules" (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 (II) Loader magic: 0x3560 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0:1:0:0) 10de:0392:1462:0413 nVidia Corporation G73 [GeForce 7600 GS] rev 161, Mem @ 0xfa000000/16777216, 0xd0000000/268435456, 0xfb000000/16777216, I/O @ 0x0000ef00/128, BIOS @ 0x????????/65536 (II) System resource ranges: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "vesa" (II) Loading /usr/local/lib/xorg/modules/drivers//vesa_drv.so (II) Module vesa: vendor="X.Org Foundation" compiled for 1.6.5, module version = 2.1.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) VESA: driver for VESA chipsets: vesa (II) Primary Device is: PCI 01@00:00:0 (II) resource ranges after probing: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/local/lib/xorg/modules//libvbe.so (II) Module vbe: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org Video Driver, version 5.0 (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) VESA(0): initializing int10 (==) VESA(0): Write-combining range (0xa0000,0x20000) was already clear (==) VESA(0): Write-combining range (0xc0000,0x40000) was already clear (II) VESA(0): Primary V_BIOS segment is: 0xc000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 262144 kB (II) VESA(0): VESA VBE OEM: NVIDIA (II) VESA(0): VESA VBE OEM Software Rev: 5.115 (II) VESA(0): VESA VBE OEM Vendor: NVIDIA Corporation (II) VESA(0): VESA VBE OEM Product: G73 Board - p345h0 (II) VESA(0): VESA VBE OEM Product Rev: Chip Rev (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Depth 24, (--) framebuffer bpp 32 (==) VESA(0): RGB weight 888 (==) VESA(0): Default visual is TrueColor (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA VBE DDC supported (II) VESA(0): VESA VBE DDC Level 2 (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec. (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA VBE DDC read successfully (II) VESA(0): Manufacturer: HSL Model: 6b4 Serial#: 107150 (II) VESA(0): Year: 2001 Week: 52 (II) VESA(0): EDID Version: 1.2 (II) VESA(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) VESA(0): Sync: Separate (II) VESA(0): Max Image Size [cm]: horiz.: 32 vert.: 24 (II) VESA(0): Gamma: 2.26 (II) VESA(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) VESA(0): First detailed timing is preferred mode (II) VESA(0): redX: 0.645 redY: 0.321 greenX: 0.285 greenY: 0.600 (II) VESA(0): blueX: 0.142 blueY: 0.057 whiteX: 0.283 whiteY: 0.298 (II) VESA(0): Supported established timings: (II) VESA(0): 720x400@70Hz (II) VESA(0): 640x480@60Hz (II) VESA(0): 640x480@75Hz (II) VESA(0): 800x600@75Hz (II) VESA(0): 1024x768@75Hz (II) VESA(0): Manufacturer's mask: 0 (II) VESA(0): Supported standard timings: (II) VESA(0): #0: hsize: 640 vsize 480 refresh: 85 vid: 22833 (II) VESA(0): #1: hsize: 800 vsize 600 refresh: 85 vid: 22853 (II) VESA(0): #2: hsize: 1024 vsize 768 refresh: 85 vid: 22881 (II) VESA(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) VESA(0): Supported detailed timing: (II) VESA(0): clock: 94.5 MHz Image Size: 306 x 230 mm (II) VESA(0): h_active: 1024 h_sync: 1072 h_sync_end 1168 h_blank_end 1376 h_border: 0 (II) VESA(0): v_active: 768 v_sync: 769 v_sync_end 772 v_blanking: 808 v_border: 0 (II) VESA(0): Serial No: 0000000000 (II) VESA(0): Ranges: V min: 50 V max: 160 Hz, H min: 30 H max: 72 kHz, PixClock max 110 MHz (II) VESA(0): Monitor name: 720E (II) VESA(0): EDID (in hex): (II) VESA(0): 00ffffffffffff00226cb4068ea20100 (II) VESA(0): 340b01020820187eea1269a552499924 (II) VESA(0): 0e484ca4420031594559615981800101 (II) VESA(0): 010101010101ea240060410028303060 (II) VESA(0): 130032e61000001e000000ff00303030 (II) VESA(0): 303030303030300a2020000000fd0032 (II) VESA(0): a01e480b000a202020202020000000fc (II) VESA(0): 00373230450a202020202020202000b1 (II) VESA(0): EDID vendor "HSL", prod id 1716 (II) VESA(0): Using EDID range info for horizontal sync (II) VESA(0): Using EDID range info for vertical refresh (II) VESA(0): Printing DDC gathered Modelines: (II) VESA(0): Modeline "1024x768"x0.0 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (68.7 kHz) (II) VESA(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) VESA(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) VESA(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) VESA(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) VESA(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) VESA(0): Modeline "640x480"x0.0 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (43.3 kHz) (II) VESA(0): Modeline "800x600"x0.0 56.25 800 832 896 1048 600 601 604 631 +hsync +vsync (53.7 kHz) (II) VESA(0): Modeline "1024x768"x0.0 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (68.7 kHz) (II) VESA(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) VESA(0): Searching for matching VESA mode(s): (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 100 (640x400) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 640 XResolution: 640 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 14 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 14 LinNumberOfImagePages: 14 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 101 (640x480) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 640 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 10 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 10 LinNumberOfImagePages: 10 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 102 (800x600) ModeAttributes: 0x31f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 100 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 4 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 3 BankSize: 0 NumberOfImages: 14 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 100 BnkNumberOfImagePages: 14 LinNumberOfImagePages: 14 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 108500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 103 (800x600) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 800 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 6 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 800 BnkNumberOfImagePages: 6 LinNumberOfImagePages: 6 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 104 (1024x768) ModeAttributes: 0x31f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 128 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 4 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 3 BankSize: 0 NumberOfImages: 6 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 128 BnkNumberOfImagePages: 6 LinNumberOfImagePages: 6 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 108500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 105 (1024x768) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1024 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 3 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 106 (1280x1024) ModeAttributes: 0x31f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 160 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 4 BitsPerPixel: 4 NumberOfBanks: 1 MemoryModel: 3 BankSize: 0 NumberOfImages: 3 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 160 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 108500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 107 (1280x1024) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1280 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 1 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 10e (320x200) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 640 XResolution: 320 YResolution: 200 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 30 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 30 LinNumberOfImagePages: 30 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 10f (320x200) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1280 XResolution: 320 YResolution: 200 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 14 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 14 LinNumberOfImagePages: 14 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 111 (640x480) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1280 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 4 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 112 (640x480) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 2560 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 114 (800x600) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1600 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 115 (800x600) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 3200 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 117 (1024x768) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 2048 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 118 (1024x768) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 4096 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 4096 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 11a (1280x1024) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 2560 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 11b (1280x1024) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 5120 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 5120 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 130 (320x200) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 320 XResolution: 320 YResolution: 200 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 62 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 320 BnkNumberOfImagePages: 62 LinNumberOfImagePages: 62 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 131 (320x400) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 320 XResolution: 320 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 30 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 320 BnkNumberOfImagePages: 30 LinNumberOfImagePages: 30 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 132 (320x400) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 640 XResolution: 320 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 14 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 14 LinNumberOfImagePages: 14 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 133 (320x400) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1280 XResolution: 320 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 6 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 6 LinNumberOfImagePages: 6 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 134 (320x240) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 320 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 30 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 320 BnkNumberOfImagePages: 30 LinNumberOfImagePages: 30 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 135 (320x240) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 640 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 19 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 19 LinNumberOfImagePages: 19 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 136 (320x240) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1280 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 10 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 10 LinNumberOfImagePages: 10 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 13d (640x400) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1280 XResolution: 640 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 6 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 6 LinNumberOfImagePages: 6 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 13e (640x400) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 2560 XResolution: 640 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 145 (1600x1200) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1600 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 1 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 146 (1600x1200) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 3200 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 147 (1400x1050) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 1400 XResolution: 1400 YResolution: 1050 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 1 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1400 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 148 (1400x1050) ModeAttributes: 0x39f WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 2800 XResolution: 1400 YResolution: 1050 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2800 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 229500000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 152 (2048x1536) ModeAttributes: 0x3db WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc0009ae9 BytesPerScanline: 8192 XResolution: 2048 YResolution: 1536 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 0 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 8 RsvdFieldPosition: 24 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 8192 BnkNumberOfImagePages: 0 LinNumberOfImagePages: 0 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 8 LinRsvdFieldPosition: 24 MaxPixelClock: 229500000 (II) VESA(0): Total Memory: 4096 64KB banks (262144kB) (II) VESA(0): Monitor0: Using hsync range of 30.00-72.00 kHz (II) VESA(0): Monitor0: Using vrefresh range of 50.00-160.00 Hz (II) VESA(0): Monitor0: Using maximum pixel clock of 110.00 MHz (WW) VESA(0): Unable to estimate virtual size (II) VESA(0): Not using built-in mode "2048x1536" (no mode of this name) (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Not using built-in mode "640x400" (no mode of this name) (II) VESA(0): Not using built-in mode "320x400" (no mode of this name) (II) VESA(0): Not using built-in mode "320x240" (no mode of this name) (II) VESA(0): Not using built-in mode "320x200" (no mode of this name) (--) VESA(0): Virtual size is 1280x1024 (pitch 1280) (**) VESA(0): *Built-in mode "1280x1024" (**) VESA(0): *Built-in mode "1024x768" (**) VESA(0): *Built-in mode "800x600" (**) VESA(0): *Built-in mode "640x480" (**) VESA(0): Display dimensions: (320, 240) mm (**) VESA(0): DPI set to (101, 108) (**) VESA(0): Using "Shadow Framebuffer" (II) Loading sub module "shadow" (II) LoadModule: "shadow" (II) Loading /usr/local/lib/xorg/modules//libshadow.so (II) Module shadow: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/local/lib/xorg/modules//libint10.so (II) VESA(0): initializing int10 (==) VESA(0): Write-combining range (0xa0000,0x20000) was already clear (II) VESA(0): Primary V_BIOS segment is: 0xc000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 262144 kB (II) VESA(0): VESA VBE OEM: NVIDIA (II) VESA(0): VESA VBE OEM Software Rev: 5.115 (II) VESA(0): VESA VBE OEM Vendor: NVIDIA Corporation (II) VESA(0): VESA VBE OEM Product: G73 Board - p345h0 (II) VESA(0): VESA VBE OEM Product Rev: Chip Rev (II) VESA(0): virtual address = 0x802c00000, physical address = 0xd0000000, size = 268435456 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Setting up VESA Mode 0x11B (1280x1024) (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Default visual is TrueColor (==) VESA(0): Backing store disabled (II) VESA(0): DPMS enabled (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear --------------080008080901030604030004-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 01:28:05 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15A62106566C for ; Wed, 17 Feb 2010 01:28:05 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id C832D8FC0C for ; Wed, 17 Feb 2010 01:28:04 +0000 (UTC) Received: (qmail 22090 invoked by uid 0); 17 Feb 2010 01:28:03 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Feb 2010 01:28:03 -0000 Date: Tue, 16 Feb 2010 20:28:03 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 01:28:05 -0000 Howdy, I'm having some problems getting 8.0 to install over the network. I've got my dhcp, tftp and nfs server working well, and I've tested all three services from this host before attempting to boot over the network. pxeboot seems to work, and I see it get loaded via tftp. The kernel boots, and parses the options in loader.conf that exist in my nfs-exported 8.0 DVD fileset: [root@archive /home/spork/tmp]# cat /usr/local/netboot/freebsd8/boot/loader.conf mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" boot_multicons="YES" boot_serial="YES" console="comconsole,vidconsole" vfs.root.mountfrom="ufs:/dev/md0c" I see the kernel does find mfsroot and attaches it: md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 But then when it's ready to mount the root filesystem, I get this: SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/md0c ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. It doesn't really state what the error is. It's hinting that it's read-only, but that seems odd. Even if it couldn't mount r/w, shouldn't it just drop to single-user at this point? Next it tries nfs: Trying to mount root from nfs: NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 em0: link state changed to UP And there it sits. Remotely I can't do anything. If I'm local, I can ctrl-alt-del a few times and then about a minute later it does an orderly restart. I'm not aware of a good way to snoop on nfs traffic, but tcpdump shows nfs traffic between the two hosts, which appears to be the client stat-ing a file or directory. tcpdump also shows some checksum errors, but I recall a few threads here mentioning that on Intel cards that generally is not a cause for concern. >From another host, I have no issues mounting that nfs filesystem r/w: root@h10[/home/spork]# mount_nfs 192.168.1.111:/usr/local/netboot/freebsd8 /mntroot@h10[/home/spork]# ls /mnt/ .cshrc HARDWARE.TXT boot.catalog media sbin .profile README.HTM cdrom.inf mnt stand 8.0-RELEASE README.TXT dev packages sys COPYRIGHT RELNOTES.HTM docbook.css proc tmp ERRATA.HTM RELNOTES.TXT etc rescue usr ERRATA.TXT bin lib root var HARDWARE.HTM boot libexec rr_moved root@h10[/home/spork]# touch /mnt/foo root@h10[/home/spork]# rm /mnt/foo root@h10[/home/spork]# umount /mnt Any ideas? I've got about a dozen remote boxes to upgrade, so I want to totally nail down this procedure. I've been putting off learning this for a few years, and now I've got an actual need for it. Thanks, Charles From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 02:11:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB9C5106566B for ; Wed, 17 Feb 2010 02:11:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id B49E78FC17 for ; Wed, 17 Feb 2010 02:11:39 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta08.emeryville.ca.mail.comcast.net with comcast id ipKp1d0081wfjNsA8qBf34; Wed, 17 Feb 2010 02:11:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta23.emeryville.ca.mail.comcast.net with comcast id iqBd1d00A3S48mS8jqBd0U; Wed, 17 Feb 2010 02:11:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 89C111E301A; Tue, 16 Feb 2010 18:11:36 -0800 (PST) Date: Tue, 16 Feb 2010 18:11:36 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100217021136.GA10628@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 02:11:40 -0000 On Tue, Feb 16, 2010 at 08:28:03PM -0500, Charles Sprickman wrote: > Howdy, > > I'm having some problems getting 8.0 to install over the network. > I've got my dhcp, tftp and nfs server working well, and I've tested > all three services from this host before attempting to boot over the > network. > > pxeboot seems to work, and I see it get loaded via tftp. The kernel > boots, and parses the options in loader.conf that exist in my > nfs-exported 8.0 DVD fileset: > > [root@archive /home/spork/tmp]# cat > /usr/local/netboot/freebsd8/boot/loader.conf > mfsroot_load="YES" > mfsroot_type="mfs_root" > mfsroot_name="/boot/mfsroot" > boot_multicons="YES" > boot_serial="YES" > console="comconsole,vidconsole" > vfs.root.mountfrom="ufs:/dev/md0c" > > I see the kernel does find mfsroot and attaches it: > > md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 > > But then when it's ready to mount the root filesystem, I get this: > > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/md0c > ROOT MOUNT ERROR: > > If you have invalid mount options, reboot, and first try the > following from the loader prompt: > > set vfs.root.mountfrom.options=rw > > and then remove invalid mount options from /etc/fstab. > > It doesn't really state what the error is. It's hinting that it's > read-only, but that seems odd. Even if it couldn't mount r/w, > shouldn't it just drop to single-user at this point? > > Next it tries nfs: > > Trying to mount root from nfs: > NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 > em0: link state changed to UP > > And there it sits. Remotely I can't do anything. If I'm local, I > can ctrl-alt-del a few times and then about a minute later it does > an orderly restart. We've been talking off-list about this (and other things), but at this point I'm pretty sure the problem is that the local slice naming convention has changed in RELENG_8 from what it was in RELENG_7. This is the cause/result of the "GEOM overhall" (or whatever it is; I don't know what to call it. Is it libdisk changes? GEOM? Both? I really don't know). Basically, the way the full size of the disk gets handled differs now from RELENG_7. (See footnote for "fun") So, try changing this: vfs.root.mountfrom="ufs:/dev/md0c" ...to this (look closely): vfs.root.mountfrom="ufs:/dev/md0" Remember: the mfsroot image is essentially a UFS filesystem that's mounted as memory disk. Since you re-created mfsroot (like you're supposed to :-) ) on a RELENG_8 box, the layout is different. The NFS root mount you see happening later is a result of the root filesystem not being available. This is normal if mfsroot fails. Please let me (on the list) know if this fixes your problem. Footnote: This is why I tell folks to zero out the first 8192 bytes of any disk they've previously installed FreeBSD on (even if the disk has no filesystems/slices on it). The way FreeBSD determines the size of the disk differs in RELENG_8; I believe GEOM "figures it out" on its own now, while previous releases relied on the "c" slice. The method I've recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 02:27:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30C31106566C for ; Wed, 17 Feb 2010 02:27:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5E38FC08 for ; Wed, 17 Feb 2010 02:27:36 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta13.emeryville.ca.mail.comcast.net with comcast id iprW1d0011wfjNsADqTdHu; Wed, 17 Feb 2010 02:27:37 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta23.emeryville.ca.mail.comcast.net with comcast id iqTb1d0083S48mS8jqTcRe; Wed, 17 Feb 2010 02:27:36 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1EA791E301A; Tue, 16 Feb 2010 18:27:34 -0800 (PST) Date: Tue, 16 Feb 2010 18:27:34 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100217022734.GA11020@icarus.home.lan> References: <20100217021136.GA10628@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100217021136.GA10628@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 02:27:37 -0000 On Tue, Feb 16, 2010 at 06:11:36PM -0800, Jeremy Chadwick wrote: > The NFS root mount you see happening later is a result of the root > filesystem not being available. This is normal if mfsroot fails. A follow-up to my own post: The above paragraph is incorrect. The NFS root mount is proper, expected, and required -- but the failures you see later on (e.g. /etc/fstab missing, etc. -- which are in your private mail to me but not here), I believe, are a result of the mfsroot stuff not working. Sorry for the confusion; I should really be asleep right now... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 02:45:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF42106566B; Wed, 17 Feb 2010 02:45:13 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by mx1.freebsd.org (Postfix) with ESMTP id 20C988FC17; Wed, 17 Feb 2010 02:45:11 +0000 (UTC) Received: by bwz23 with SMTP id 23so1650626bwz.13 for ; Tue, 16 Feb 2010 18:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jA9KB50VzJ5dSNnz3VxI9q+mggCsP4oMpRr6F0JArpA=; b=E88ZDKM9pL4CMqmZ62/AZAwVB6rt2vV9sAKHCFsqbRjY2ZN32JH0oRumS+2bGU81iV 6mbYIXI5aqmuG0v21kffetHRUHp2Fdz0UtHeCguRD9ZOgK30oWykzcVJlNxwLixroUvM 1zkfHvn1XRCQXZS45YkITt2e31Vtna844fHLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ohuiMGW2O3f6x0Id2NClVl8Uvhb61bOi5eZndVjIf/f2Qycpqu+/laF2WBEKNGCvTh u61t5jwwzVCfF9uVY3ekEsDseFj66gQ1BOP7vPofuJ2bWFTD0/WRN5IPSV44jB4OrS3b DVmamu16q48It5o0hJbI15Fq9vdEJBME2sG70= MIME-Version: 1.0 Received: by 10.204.38.71 with SMTP id a7mr4863891bke.159.1266374710988; Tue, 16 Feb 2010 18:45:10 -0800 (PST) In-Reply-To: <1266249418.11131.7.camel@balrog.2hip.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> <201002131137.34812.npapke@acm.org> <1266096425.89452.30.camel@balrog.2hip.net> <20100215142305.3f0d7e65@miknet.dk> <1266249418.11131.7.camel@balrog.2hip.net> Date: Wed, 17 Feb 2010 02:45:09 +0000 Message-ID: <6101e8c41002161845q5d78eb99x61f8ba3ca4eb90c9@mail.gmail.com> From: Oliver Pinter To: Robert Noland Content-Type: multipart/mixed; boundary=0003255592bacd100b047fc2d630 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Martin Kristensen , freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 02:45:13 -0000 --0003255592bacd100b047fc2d630 Content-Type: text/plain; charset=ISO-8859-1 Xorg.log after: #killall xdm #kldunload radeon #dmesg: info: [drm] Resetting GPU vgapci0: child drm0 requested pci_disable_busmaster info: [drm] MSI released drm0: detached Warning: memory type drm_bufs leaked memory on destroy (2 allocations, 64 bytes leaked). drm0: on vgapci0 #kldload radeon #dmesg: drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 #xdm after this procedure the X never come up, but the system not crashed, and the log attached. On 2/15/10, Robert Noland wrote: > On Mon, 2010-02-15 at 14:23 +0100, Martin Kristensen wrote: >> On Sat, 13 Feb 2010 15:27:04 -0600 >> Robert Noland wrote: >> >> > On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: >> > > On February 13, 2010, Robert Noland wrote: >> > > > Ok, I've put up a patch at: >> > > > >> > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch >> > > > >> > >> > http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch >> > >> > This one should work on 8... >> > >> > robert. >> > >> > > > This is sort of a mega patch and includes: >> > > > >> > > > Re-worked drm mapping code, that ensures that we don't end up >> > > > incorrectly mapping certain maps with overlapping offsets. This >> > > > generally shows up as the ring buffer not being cleared >> > > > (contents != 0 in xorg.log) which leads to corruption and other >> > > > bad behavior. >> > > > >> > > > Re-written scatter gather allocation code. This interacts >> > > > directly with the VM system, rather than using bus_dma to allow >> > > > us to grab non-contiguous pages for the scatter gather backing of >> > > > the GART. It also makes it easier to handle the caching mode of >> > > > the backing pages. >> > > > >> > > > Disable cache snooping on radeon cards, since we have write >> > > > combining set properly now. >> > > > >> > > > I have at least done a test build on -CURRENT with this patch, >> > > > but I haven't had time to do much else without the rest of the >> > > > code in my tree. I've been running most all of this code for a >> > > > month or two now at least, so it is mostly just a question of >> > > > whether or not I got all of the conflicts sorted out properly >> > > > when I made this patch. >> > > > >> > > > The re-mapping code has the most widespread impact and has been >> > > > tested on radeon r600 amd64, intel g45 i386 and mga amd64. >> > > > >> > > > robert. >> >> The patch applied cleanly. I have applied the patch to a clean 8-STABLE >> environment with WITNESS, INVARIANTS and KDB_UNATTENDED in the kernel. >> I still see the crashes when starting X with DRI on. This is what I see >> in messages: >> >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 0000070001c7b000 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 0000070001c7c000 >> Feb 14 19:13:44 alpha kernel: >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 0000070001c7d000 >> Feb 14 19:13:44 alpha kernel: >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 0000070001c7e000 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 0000070001c7f000 >> Feb 14 19:13:44 alpha kernel: >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, >> cmd=0xc0286415, nr=0x15, dev 0xffffff0001a79400, auth=1 >> Feb 14 19:13:44 alpha kernel: >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] offset = >> 0xfe8e0000, size = 0x00010000, type = 1 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Found kernel map 1 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Added map 1 >> 0xfe8e0000/0x10000 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, >> cmd=0x80106459, nr=0x59, dev 0xffffff0001a79400, auth=1 >> >> >> There has been one odd development. If I startx with DRI off or NoAccel >> set it starts as usual. If I then quit and to cli and restart, I see the >> same crash as if I had DRI on. > > I'm really starting to think that this is a bug in the Xserver > somewhere... If DRI is off, the kernel drm is not involved at all. The > radeon driver does grope around on the pci bus (via libpciaccess) which > could potentially cause issues, but... miwi and a few other folks have > picked up the ball to get us up to xorg 7.5, since I just don't have > time to do it all now. That might be a good thing to try, I expect that > they will have a patch ready soon, like within a few days. > > robert. > >> Martin > -- > Robert Noland > FreeBSD > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --0003255592bacd100b047fc2d630-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 02:49:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69F55106568B for ; Wed, 17 Feb 2010 02:49:33 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 402078FC08 for ; Wed, 17 Feb 2010 02:49:33 +0000 (UTC) Received: by pzk40 with SMTP id 40so3987606pzk.7 for ; Tue, 16 Feb 2010 18:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mLrbMrQG7FRW2J4m+EmRcY0Xbp4NCtqHY7RjQRDNeKk=; b=W8g6q3qRpLKV6rN3NWnl2Y4+N2j3j8W0s3jK4ziitIGBUJFVWS6aAZiSgwDBlUjGkt C7VdWlJancDLIFConpprCFPgp2sKYpR2hWb/0Vuq3WdlVdRaFg02wNjyKCUMcimTV+qX jSiC+Svc5Bq5FCj4m7YZeKYb9XiIPRI/wJDPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=oNqRKOZU6Q0Feplg7H5SQpjzrpkac1e4iAy5faviBEhqX8y40Lbtc7ISXKDh4jITGg ofeiSlIfUwUD6OEHBtlg+upEXyitIv097akQ7OPvKeFJRkLMnwGoZs8NHm63j7citmgN MrpOIp/a+YnbmFIt97yJyRAGc3mX8UFaRygO4= MIME-Version: 1.0 Received: by 10.143.154.8 with SMTP id g8mr4955310wfo.57.1266374972617; Tue, 16 Feb 2010 18:49:32 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Feb 2010 18:49:32 -0800 Message-ID: <7d6fde3d1002161849gacd620cpe8a56c25bffa32bd@mail.gmail.com> From: Garrett Cooper To: Charles Sprickman , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 02:49:33 -0000 On Tue, Feb 16, 2010 at 5:28 PM, Charles Sprickman wrote: > Howdy, > > I'm having some problems getting 8.0 to install over the network. =A0I've= got > my dhcp, tftp and nfs server working well, and I've tested all three > services from this host before attempting to boot over the network. > > pxeboot seems to work, and I see it get loaded via tftp. =A0The kernel bo= ots, > and parses the options in loader.conf that exist in my nfs-exported 8.0 D= VD > fileset: > > [root@archive /home/spork/tmp]# cat > /usr/local/netboot/freebsd8/boot/loader.conf > mfsroot_load=3D"YES" > mfsroot_type=3D"mfs_root" > mfsroot_name=3D"/boot/mfsroot" > boot_multicons=3D"YES" > boot_serial=3D"YES" > console=3D"comconsole,vidconsole" > vfs.root.mountfrom=3D"ufs:/dev/md0c" > > I see the kernel does find mfsroot and attaches it: > > md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 > > But then when it's ready to mount the root filesystem, I get this: > > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/md0c > ROOT MOUNT ERROR: > > If you have invalid mount options, reboot, and first try the following fr= om > the loader prompt: > > =A0 =A0 set vfs.root.mountfrom.options=3Drw > > and then remove invalid mount options from /etc/fstab. > > It doesn't really state what the error is. =A0It's hinting that it's > read-only, but that seems odd. =A0Even if it couldn't mount r/w, shouldn'= t it > just drop to single-user at this point? > > Next it tries nfs: > > Trying to mount root from nfs: > NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 > em0: link state changed to UP > > And there it sits. =A0Remotely I can't do anything. =A0If I'm local, I ca= n > ctrl-alt-del a few times and then about a minute later it does an orderly > restart. > > I'm not aware of a good way to snoop on nfs traffic, but tcpdump shows nf= s > traffic between the two hosts, which appears to be the client stat-ing a > file or directory. =A0tcpdump also shows some checksum errors, but I reca= ll a > few threads here mentioning that on Intel cards that generally is not a > cause for concern. > >> From another host, I have no issues mounting that nfs filesystem r/w: > > root@h10[/home/spork]# mount_nfs 192.168.1.111:/usr/local/netboot/freebsd= 8 > /mntroot@h10[/home/spork]# ls /mnt/ > .cshrc =A0 =A0 =A0 =A0 =A0HARDWARE.TXT =A0 =A0boot.catalog =A0 =A0media = =A0 =A0 =A0 =A0 =A0 sbin > .profile =A0 =A0 =A0 =A0README.HTM =A0 =A0 =A0cdrom.inf =A0 =A0 =A0 mnt = =A0 =A0 =A0 =A0 =A0 =A0 stand > 8.0-RELEASE =A0 =A0 README.TXT =A0 =A0 =A0dev =A0 =A0 =A0 =A0 =A0 =A0 pac= kages =A0 =A0 =A0 =A0sys > COPYRIGHT =A0 =A0 =A0 RELNOTES.HTM =A0 =A0docbook.css =A0 =A0 proc =A0 = =A0 =A0 =A0 =A0 =A0tmp > ERRATA.HTM =A0 =A0 =A0RELNOTES.TXT =A0 =A0etc =A0 =A0 =A0 =A0 =A0 =A0 res= cue =A0 =A0 =A0 =A0 =A0usr > ERRATA.TXT =A0 =A0 =A0bin =A0 =A0 =A0 =A0 =A0 =A0 lib =A0 =A0 =A0 =A0 =A0= =A0 root =A0 =A0 =A0 =A0 =A0 =A0var > HARDWARE.HTM =A0 =A0boot =A0 =A0 =A0 =A0 =A0 =A0libexec =A0 =A0 =A0 =A0 r= r_moved > root@h10[/home/spork]# touch /mnt/foo > root@h10[/home/spork]# rm /mnt/foo > root@h10[/home/spork]# umount /mnt > > Any ideas? =A0I've got about a dozen remote boxes to upgrade, so I want t= o > totally nail down this procedure. =A0I've been putting off learning this = for a > few years, and now I've got an actual need for it. I'll be in your shoes in a little bit... I ran into some issues when I last tried with NFSv3 on a Solaris server so we'll see how things go in the second go-around [with a FreeBSD nfs rootfs server], but 7.x netbooted and 8.x didn't when I tried last; the 7.x images have some secret sauce fixes for PXE booting -- the ones I know of are as follows (apply to loader.conf as you feel fit): vfs.root.mountfrom=3D"nfs" boot.nfsroot.path=3D"/absolute/path/to/netboot/dir" boot.nfsroot.server=3D"nfs-server-ip-addr" There were also some code changes made to `fix' netbooting with pxeloader, but I'm not sure if they're applicable or needed in 8.x, and I'm not sure what the actual changes are TBH... Cheers, -Garrett From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 03:56:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19706106566B for ; Wed, 17 Feb 2010 03:56:13 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id B63F98FC08 for ; Wed, 17 Feb 2010 03:56:12 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so924909qwh.7 for ; Tue, 16 Feb 2010 19:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=IRvNQkl3vmURcQZcqq0wR5lzstls4luzO4gzBll4fXU=; b=SWQJnCIjuXN7mSn6oHUZQl1lmQeRe/dbVyj150kCGGMD0IBN3xBBDuaaSfH91CS+tP XvTnESiVqgcYJHeIoXUUxdvFlfsLAjb2ArvoE07UqFjfYhzY+wSLXiZnHhulaUlRmx3X 17zJYHRLlopwYKgkSSE/zhze2T00gbgfssOFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=lDf6YiObvaWzMbEVGPjPEC3r9Jm4FCz7ZTR/40yBQfOBQThuYDFmZ2YiyU3a4rwLlX 9L6/ZEJo/zX7SC1gTsRf5nfbH77CpwoC6l/gQyIxE8adFMX+oRO3YP7SW8xQt7R/0e1w iZxtSxcgQzd3Sw5kzCeN3TEpdJYz0WfCAnwig= Received: by 10.229.96.82 with SMTP id g18mr3726361qcn.82.1266378971756; Tue, 16 Feb 2010 19:56:11 -0800 (PST) Received: from ppp-22.151.dialinfree.com (ppp-22.151.dialinfree.com [209.172.22.151]) by mx.google.com with ESMTPS id 20sm5574348qyk.9.2010.02.16.19.56.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 19:56:10 -0800 (PST) Sender: "J. Hellenthal" Date: Tue, 16 Feb 2010 22:55:59 -0500 From: jhell To: Matt Reimer In-Reply-To: Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , FreeBSD Stable , Miroslav Lachman <000.fbsd@quip.cz>, Jeremy Chadwick Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 03:56:13 -0000 On Tue, 16 Feb 2010 13:30, mattjreimer@ wrote: > On Mon, Feb 15, 2010 at 5:49 PM, jhell wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> It is funny that you guys are all of a sudden talking about this, as I was >> just working on some modifications to the arc_summary.pl script for some >> better formatting and inclusion of kmem statistics. >> >> My intent on the modifications is to make the output more usable to the >> whole community by revealing the relevant system information that can be >> included in an email to the lists for diagnosis by others. >> > ... > >> Example output: >> - --------------------------------------------------------------------- >> System Summary >> OS Revision: 199506 >> OS Release Date: 703100 >> Hardware Platform: i386 >> Processor Architecture: i386 >> Storage pool Version: 13 >> Filesystem Version: 3 >> >> Kernel Memory Usage >> TEXT: 8950208 KiB, 8 MiB >> DATA: 206347264 KiB, 196 MiB >> TOTAL: 215297472 KiB, 205 MiB >> > > Above did you really mean "8950208 B" not KiB, etc.? > > Matt > Yes, Thank you for pointing this out. I have fixed this and it will be added to the the same url as before in about 3 or so hours from the time of this email. This update will also add some stats for L2 ARC as well. Thanks again. -- jhell From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 04:43:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA50D106566C for ; Wed, 17 Feb 2010 04:43:31 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9B38A8FC0A for ; Wed, 17 Feb 2010 04:43:31 +0000 (UTC) Received: (qmail 11254 invoked by uid 0); 17 Feb 2010 04:43:30 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Feb 2010 04:43:30 -0000 Date: Tue, 16 Feb 2010 23:43:30 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@charles-sprickmans-imac.local To: Jeremy Chadwick In-Reply-To: <20100217021136.GA10628@icarus.home.lan> Message-ID: References: <20100217021136.GA10628@icarus.home.lan> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 04:43:32 -0000 On Tue, 16 Feb 2010, Jeremy Chadwick wrote: > On Tue, Feb 16, 2010 at 08:28:03PM -0500, Charles Sprickman wrote: >> Howdy, >> >> I'm having some problems getting 8.0 to install over the network. >> I've got my dhcp, tftp and nfs server working well, and I've tested >> all three services from this host before attempting to boot over the >> network. >> >> pxeboot seems to work, and I see it get loaded via tftp. The kernel >> boots, and parses the options in loader.conf that exist in my >> nfs-exported 8.0 DVD fileset: >> >> [root@archive /home/spork/tmp]# cat >> /usr/local/netboot/freebsd8/boot/loader.conf >> mfsroot_load="YES" >> mfsroot_type="mfs_root" >> mfsroot_name="/boot/mfsroot" >> boot_multicons="YES" >> boot_serial="YES" >> console="comconsole,vidconsole" >> vfs.root.mountfrom="ufs:/dev/md0c" >> >> I see the kernel does find mfsroot and attaches it: >> >> md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 >> >> But then when it's ready to mount the root filesystem, I get this: >> >> SMP: AP CPU #1 Launched! >> Trying to mount root from ufs:/dev/md0c >> ROOT MOUNT ERROR: >> >> If you have invalid mount options, reboot, and first try the >> following from the loader prompt: >> >> set vfs.root.mountfrom.options=rw >> >> and then remove invalid mount options from /etc/fstab. >> >> It doesn't really state what the error is. It's hinting that it's >> read-only, but that seems odd. Even if it couldn't mount r/w, >> shouldn't it just drop to single-user at this point? >> >> Next it tries nfs: >> >> Trying to mount root from nfs: >> NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 >> em0: link state changed to UP >> >> And there it sits. Remotely I can't do anything. If I'm local, I >> can ctrl-alt-del a few times and then about a minute later it does >> an orderly restart. > > We've been talking off-list about this (and other things), but at this > point I'm pretty sure the problem is that the local slice naming > convention has changed in RELENG_8 from what it was in RELENG_7. > > This is the cause/result of the "GEOM overhall" (or whatever it is; I > don't know what to call it. Is it libdisk changes? GEOM? Both? I > really don't know). Basically, the way the full size of the disk gets > handled differs now from RELENG_7. (See footnote for "fun") So, try > changing this: > > vfs.root.mountfrom="ufs:/dev/md0c" > > ...to this (look closely): > > vfs.root.mountfrom="ufs:/dev/md0" I made the change on the server, but the box is stuck until I can get over there again. Serial consoles are nice, but not being able to send "ctrl-alt-del" is a sad limitation. :) > Remember: the mfsroot image is essentially a UFS filesystem that's > mounted as memory disk. Since you re-created mfsroot (like you're > supposed to :-) ) on a RELENG_8 box, the layout is different. In this case, I'm still using the stock 8.0 mfsroot. The only change was to un-gzip it. But this particular issue is probably due to the geom change you noted, so we'll see what happens on reboot. > The NFS root mount you see happening later is a result of the root > filesystem not being available. This is normal if mfsroot fails. I'm still stumped as to why it hangs there. I do have something for it to mount there via NFS (the 8.0 dvd contents), and it appears to try, but then it just sits there. Not locked up, just waiting... > Please let me (on the list) know if this fixes your problem. As soon as she boots, I'll report back. > Footnote: This is why I tell folks to zero out the first 8192 bytes of > any disk they've previously installed FreeBSD on (even if the disk has > no filesystems/slices on it). The way FreeBSD determines the size of > the disk differs in RELENG_8; I believe GEOM "figures it out" on its own > now, while previous releases relied on the "c" slice. The method I've > recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16. Is it also advisable to blot out any old glabel stuff at the end of the disk? What's the math to get that? Get a sector count for the whole disk, set "bs" to 512 and "skip" to (sector count - 1)? Thanks, Charles > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 04:47:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 207A61065672 for ; Wed, 17 Feb 2010 04:47:12 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id C56198FC08 for ; Wed, 17 Feb 2010 04:47:11 +0000 (UTC) Received: (qmail 17287 invoked by uid 0); 17 Feb 2010 04:47:11 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Feb 2010 04:47:11 -0000 Date: Tue, 16 Feb 2010 23:47:10 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@charles-sprickmans-imac.local To: Garrett Cooper In-Reply-To: <7d6fde3d1002161849gacd620cpe8a56c25bffa32bd@mail.gmail.com> Message-ID: References: <7d6fde3d1002161849gacd620cpe8a56c25bffa32bd@mail.gmail.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-16367842-1266382031=:78881" Cc: FreeBSD-STABLE Mailing List Subject: Re: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 04:47:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-16367842-1266382031=:78881 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 16 Feb 2010, Garrett Cooper wrote: > On Tue, Feb 16, 2010 at 5:28 PM, Charles Sprickman wrote: >> Howdy, >> >> I'm having some problems getting 8.0 to install over the network.  I've got >> my dhcp, tftp and nfs server working well, and I've tested all three >> services from this host before attempting to boot over the network. >> >> pxeboot seems to work, and I see it get loaded via tftp.  The kernel boots, >> and parses the options in loader.conf that exist in my nfs-exported 8.0 DVD >> fileset: >> >> [root@archive /home/spork/tmp]# cat >> /usr/local/netboot/freebsd8/boot/loader.conf >> mfsroot_load="YES" >> mfsroot_type="mfs_root" >> mfsroot_name="/boot/mfsroot" >> boot_multicons="YES" >> boot_serial="YES" >> console="comconsole,vidconsole" >> vfs.root.mountfrom="ufs:/dev/md0c" >> >> I see the kernel does find mfsroot and attaches it: >> >> md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 >> >> But then when it's ready to mount the root filesystem, I get this: >> >> SMP: AP CPU #1 Launched! >> Trying to mount root from ufs:/dev/md0c >> ROOT MOUNT ERROR: >> >> If you have invalid mount options, reboot, and first try the following from >> the loader prompt: >> >>     set vfs.root.mountfrom.options=rw >> >> and then remove invalid mount options from /etc/fstab. >> >> It doesn't really state what the error is.  It's hinting that it's >> read-only, but that seems odd.  Even if it couldn't mount r/w, shouldn't it >> just drop to single-user at this point? >> >> Next it tries nfs: >> >> Trying to mount root from nfs: >> NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 >> em0: link state changed to UP >> >> And there it sits.  Remotely I can't do anything.  If I'm local, I can >> ctrl-alt-del a few times and then about a minute later it does an orderly >> restart. >> >> I'm not aware of a good way to snoop on nfs traffic, but tcpdump shows nfs >> traffic between the two hosts, which appears to be the client stat-ing a >> file or directory.  tcpdump also shows some checksum errors, but I recall a >> few threads here mentioning that on Intel cards that generally is not a >> cause for concern. >> >>> From another host, I have no issues mounting that nfs filesystem r/w: >> >> root@h10[/home/spork]# mount_nfs 192.168.1.111:/usr/local/netboot/freebsd8 >> /mntroot@h10[/home/spork]# ls /mnt/ >> .cshrc          HARDWARE.TXT    boot.catalog    media           sbin >> .profile        README.HTM      cdrom.inf       mnt             stand >> 8.0-RELEASE     README.TXT      dev             packages        sys >> COPYRIGHT       RELNOTES.HTM    docbook.css     proc            tmp >> ERRATA.HTM      RELNOTES.TXT    etc             rescue          usr >> ERRATA.TXT      bin             lib             root            var >> HARDWARE.HTM    boot            libexec         rr_moved >> root@h10[/home/spork]# touch /mnt/foo >> root@h10[/home/spork]# rm /mnt/foo >> root@h10[/home/spork]# umount /mnt >> >> Any ideas?  I've got about a dozen remote boxes to upgrade, so I want to >> totally nail down this procedure.  I've been putting off learning this for a >> few years, and now I've got an actual need for it. > > I'll be in your shoes in a little bit... I ran into some issues > when I last tried with NFSv3 on a Solaris server so we'll see how > things go in the second go-around [with a FreeBSD nfs rootfs server], In my case the server is FreeBSD (7.2). It's running with default nfsd flags, so I suppose it's offering both tcp and udp. No idea what version. It seems to work enough for the loader to fetch the loader files and kernel... > but 7.x netbooted and 8.x didn't when I tried last; the 7.x images > have some secret sauce fixes for PXE booting -- the ones I know of are > as follows (apply to loader.conf as you feel fit): > > vfs.root.mountfrom="nfs" > boot.nfsroot.path="/absolute/path/to/netboot/dir" > boot.nfsroot.server="nfs-server-ip-addr" Is this documented somewhere? > There were also some code changes made to `fix' netbooting with > pxeloader, but I'm not sure if they're applicable or needed in 8.x, > and I'm not sure what the actual changes are TBH... Ugh. With all these variables AND the general nuttiness of PC hardware I see many reboot cycles in my future. Charles > Cheers, > -Garrett > --0-16367842-1266382031=:78881-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 04:51:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9721D1065692 for ; Wed, 17 Feb 2010 04:51:44 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 697918FC16 for ; Wed, 17 Feb 2010 04:51:44 +0000 (UTC) Received: by pzk40 with SMTP id 40so4085932pzk.7 for ; Tue, 16 Feb 2010 20:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uO2rC2Po4LWgbE7ZuI55GHAtcVakvg5+N7v6HkA7y8k=; b=IJWuUaajk1Kl3SsI2NwNhfPNKVEFDzuwE82nbM8QuhpVzWYLHyhwpBMC2dCbjW5QVl +vsH9zfFzDCftDfwpjfd+zCLKBI5+t3YK4EJu9imyGK2INem9DMvhfE3y67l8PhFZZgB NPDEELyyJ0wJeaEHnsCGVF2UjZi97CKbD3aL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iuGJUDyoob//5TEnCSDHjIb5sK0FZTdR6nTJK4KIQuxV6SVIl4LuxTq7GnJNaX3DM9 Aprho26/hCREsHvDQEkwsHQLJehHFTMlLAaIA/DofMZe0uubfKmovIC4vAq+jT9dYYLw nWtd1sRlI8Zv7ijiV9D1qnFAcm5+wMe2jhU+Y= MIME-Version: 1.0 Received: by 10.142.59.3 with SMTP id h3mr5056670wfa.93.1266382303889; Tue, 16 Feb 2010 20:51:43 -0800 (PST) In-Reply-To: References: <7d6fde3d1002161849gacd620cpe8a56c25bffa32bd@mail.gmail.com> Date: Tue, 16 Feb 2010 22:51:43 -0600 Message-ID: <6201873e1002162051r63be801fx567ed44235a26e4f@mail.gmail.com> From: Adam Vande More To: Charles Sprickman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , FreeBSD-STABLE Mailing List Subject: Re: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 04:51:44 -0000 On Tue, Feb 16, 2010 at 10:47 PM, Charles Sprickman wrote: > Is this documented somewhere? > Here: http://www.nber.org/sys-admin/FreeBSD-diskless.html Whoever wrote that, thank you. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 07:59:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62509106566C for ; Wed, 17 Feb 2010 07:59:09 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 194158FC18 for ; Wed, 17 Feb 2010 07:59:08 +0000 (UTC) Received: by iwn5 with SMTP id 5so3115911iwn.9 for ; Tue, 16 Feb 2010 23:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=mc9QYmf9kmS5MWjTr0Z6ISXfDQD1ECqlobKpOJnMdJQ=; b=Sxks6ic9wWK5hWH+wPgZXtzuBcPfQeuF6tHFrBSAspDuBx7m1PkbtObnklye7gWNzq EWbS+cq5sKxc/FGJ7Uqtdyfi5Zt6koovqq5nvMCyJEsA4nM8MoW0DFq3abypiaKGBOQA P8piQebiXTM/1HPf5U29jx7PE2L5Qm2wfcw/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=Pv/ranlGbvlRNYyPDD8mNzA0pXsoNfoZHLG3JMAJKy9XNnEIpeMASoan9Z1pA8UEsr KXxHHZ8rBXzU8c3aKMEC/x4YywgCyfWOx1Ld/Q3orx3TIV2BOaHe5gnsHItgJO8QXX9C wTJx6nODwE2kgWFIle0AR18Mm6wM0fKsfDyg4= Received: by 10.231.160.205 with SMTP id o13mr1273454ibx.13.1266393548340; Tue, 16 Feb 2010 23:59:08 -0800 (PST) Received: from centel.dataix.local (ppp-21.195.dialinfree.com [209.172.21.195]) by mx.google.com with ESMTPS id 21sm1739473iwn.14.2010.02.16.23.59.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 23:59:06 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 17 Feb 2010 02:58:46 -0500 From: jhell To: FreeBSD Stable In-Reply-To: <20100216215637.GA4299@icarus.home.lan> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> <20100216200511.GA95812@server.vk2pj.dyndns.org> <20100216215637.GA4299@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Alexander Leidinger , Jeremy Chadwick , Peter Jeremy Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 07:59:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 16 Feb 2010 16:56, freebsd@ wrote: > On Wed, Feb 17, 2010 at 07:05:11AM +1100, Peter Jeremy wrote: >> Overall, Barry's script makes an excellent proof-of-concept - which is >> what he was offering. > > You know, I had a verbose in-line response typed up, agreeing with some > points of yours and disagreeing with others (with perlfaq and other > reference material), but decided... fuck it! :-) > > Lol, (anyway)... To all those involved in this. More up-to-date: arc_summary.pl r182 I have done some more minor formatting with the heading section. I have added some L2 ARC stats. Adjusted called binaries to have full paths for the moment until I get around to fixing it a little more. Not having the full path caused some frustrations with emailing the output while running from cron. If this will be a problem with anyone running it and you come across errors where something can not be executed please be patient as I will have this adjusted soon. arcstat.pl: Please update the WiKi with the missing URL, I uploaded the original FreeBSD modified copy of arcstat.pl script to the same location as arc_summary.pl in case anyone wants to grab that file for FreeBSD while they are their. I have also signed this file with my public key. I won't be making any mods to this script as I see it works as intended. I may be persuaded in the future to make adjustments to keep it working and small bug fixes. http://jhell.googlecode.com/files/arc_summary.pl http://jhell.googlecode.com/files/arcstat.pl MD5 (arc_summary.pl) = 6587be39266bd131ed5f4611f321c9e2 SHA256 (arc_summary.pl) = fea99963562e1caee01d6ccd9af1b592cb18fcfaf81308bd1ee21c546c8290ad SIZE (arc_summary.pl) = 12875 MD5 (arcstat.pl) = 9b7d7b4d52ba997c7c59bc0afaca8aa9 SHA256 (arcstat.pl) = b97fc59460468bb2bab6d53009e67f2de87fd5817e7b5656266ea4fd75079b2a SIZE (arcstat.pl) = 8172 Best regards. And watching for replies, - -- jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe6G9AAoJEJBXh4mJ2FR++mYIAJXgJ468WX65PErzYiNySmB/ Sliz5Qur7kpqeP/LHuJHXk/FG+JaaQJQbh/9vIsX2zoqnBK7gqyqTOdv2pw+sKff PNcwdhYbJXEYTnGorj4FXmEI4IkXfuYM281nEpytSVU1CLTnL8oeWU9YRFTw0Fhh Gtvcy2jSnOmjjARt/0Ot1PKfOE9/PTghBTjvmGJIUz11evKsacZmXEIpv1P3KnS9 XMmeDjARkMpXCqDsBPPWeD/YYWUW6SA3Iq+BP0CeVqk7ytQ/q2WI7wH5pC+EscTx dLczky3GR5TeeHrRVQCKWVzQGoxQFH85X2MGipgOae6viHHC+Nk2J1cKVWhLx5s= =zRvh -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 08:16:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 779FB1065670 for ; Wed, 17 Feb 2010 08:16:59 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 3339B8FC15 for ; Wed, 17 Feb 2010 08:16:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXZ007IU8BEL090@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 09:16:26 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXZ00CNS8BE7740@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 09:16:26 +0100 (CET) Date: Wed, 17 Feb 2010 09:16:25 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 08:16:59 -0000 Another crash last night. In /var/log/messages: Feb 16 23:13:22 kg-f2 ntpd[2826]: time reset +1.780863 s Feb 16 23:16:42 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:16:42 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 00000080 Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=65614674 Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 00000080 Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 00000080 Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=65614674 Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 00000080 Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ad6: WARNING - WRITE_DMA requeued due to channel reset LBA=65614674 Feb 16 23:20:39 kg-f2 kernel: ata3: FAILURE - already active DMA on this device Feb 16 23:20:39 kg-f2 kernel: ata3: setting up DMA failed Feb 16 23:20:39 kg-f2 kernel: ad6: TIMEOUT - READ_DMA retrying (1 retry left) LBA=8389026 Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 00000080 Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=65614674 Feb 16 23:20:39 kg-f2 kernel: ad6: TIMEOUT - READ_DMA retrying (0 retries left) LBA=8389026 Feb 16 23:20:39 kg-f2 root: ZFS: vdev I/O failure, zpool=zroot path=/dev/gpt/disk1 offset=29299662848 size=4096 error=5 Feb 17 09:09:40 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel But ad4 and ad6 are the two disk mirrir (zfs) that I have built my root filesystem on. Hmm. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 08:20:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3C5A106566B for ; Wed, 17 Feb 2010 08:20:06 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 624A08FC15 for ; Wed, 17 Feb 2010 08:20:06 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o1H8K1TY003217 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Feb 2010 08:20:01 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk o1H8K1TY003217 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1266394801; bh=D1miyA3BWK9dlADuBEcdBAb5FTciHK0vVzsOk3RUhy8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding:Cc:Content-Type: Date:From:In-Reply-To:Message-ID:Mime-Version:References:To; z=Message-ID:=20<4B7BA6B1.2040209@infracaninophile.co.uk>|Date:=20W ed,=2017=20Feb=202010=2008:20:01=20+0000|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Mozilla/5.0=20(Macintosh=3B=20U=3B=20Intel=20Mac= 20OS=20X=2010.6=3B=20en-GB=3B=20rv:1.9.1.7)=20Gecko/20100111=20Thu nderbird/3.0.1|MIME-Version:=201.0|To:=20Christian=20Schramm=20|CC:=20freebsd-stable@freebsd.org|Sub ject:=20Re:=20blank=20X=20screen=20with=20differnt=20cards|Referen ces:=20<6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.co m>=09<20100211074933.GJ9748@acme.spoerlein.net>=09<1266080709.8945 2.21.camel@balrog.2hip.net>=09<201002131137.34812.npapke@acm.org>= 09<1266096425.89452.30.camel@balrog.2hip.net>=09<20100215142305.3f 0d7e65@miknet.dk>=09<1266249418.11131.7.camel@balrog.2hip.net>=20< 4B7AFA79.6060508@parative.org>|In-Reply-To:=20<4B7AFA79.6060508@pa rative.org>|X-Enigmail-Version:=201.0|Content-Type:=20text/plain=3 B=20charset=3DUTF-8|Content-Transfer-Encoding:=207bit; b=NfGTCSBAEf1vIcJohvokM8Mr5QTk1gNijS/ItwIDWHBxi9oJW5aACkzk8rIrfKa7l MW51V/HnTQmA0p54GinwCAxqq59KrmYV2QI3CFYj/y3qvOlca1h1DiAcHcskwdXFvK vmL4c0t1nBMsFN7G0XzMiwn1DwqbTcPI2mV1HOpI= Message-ID: <4B7BA6B1.2040209@infracaninophile.co.uk> Date: Wed, 17 Feb 2010 08:20:01 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christian Schramm References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> <201002131137.34812.npapke@acm.org> <1266096425.89452.30.camel@balrog.2hip.net> <20100215142305.3f0d7e65@miknet.dk> <1266249418.11131.7.camel@balrog.2hip.net> <4B7AFA79.6060508@parative.org> In-Reply-To: <4B7AFA79.6060508@parative.org> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: blank X screen with differnt cards X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 08:20:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/02/2010 20:05, Christian Schramm wrote: > I press Xorg -configure and X -config /root/xorg.conf.new but my CRT > Screen is blank. I can switch in tty0 an kill Xorg with CTRL-C. This is actually perfectly normal nowadays. For reasons impenetrable to us poor mortals, the developers of Xorg have decreed that the default shall be that when testing X displays a blank, black screen impossible to distinguish from certain classes of things /going horribly wrong/(tm). If you want the old grey patterned screen, try: # X -config /root/xorg.conf -retro It's all documented in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt7prAACgkQ8Mjk52CukIwNHgCggXJOsPnYCxrk8NzYpTaYHhtL 0HYAn2CrOYCEQpaVO4QA/9uftqDhCWZt =Pven -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 08:20:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E7410656A6 for ; Wed, 17 Feb 2010 08:20:10 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCA88FC21 for ; Wed, 17 Feb 2010 08:20:09 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nhf8Y-0001e9-O0; Wed, 17 Feb 2010 09:20:06 +0100 Message-ID: <4B7BA6A5.9020306@it4pro.pl> Date: Wed, 17 Feb 2010 09:19:49 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100125 Shredder/3.0.1 MIME-Version: 1.0 To: jhell References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> <20100216200511.GA95812@server.vk2pj.dyndns.org> <20100216215637.GA4299@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.71 (build at 02-Feb-2010 20:10:28) X-Date: 2010-02-17 09:20:06 X-Connected-IP: 78.8.144.74:64110 X-Message-Linecount: 119 X-Body-Linecount: 102 X-Message-Size: 3450 X-Body-Size: 2180 X-Received-Count: 1 X-Recipient-Count: 5 X-Local-Recipient-Count: 5 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: Alexander Leidinger , FreeBSD Stable , Peter Jeremy , Jeremy Chadwick Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 08:20:11 -0000 On 2010-02-17 08:58, jhell wrote: > > To all those involved in this. > > More up-to-date: arc_summary.pl r182 > > > Best regards. > > And watching for replies, > So here's my reply (last line seems most interesting ;) : # ./arc_summary.pl --------------------------------------------------------------------- System Summary Å›ro 17 lut 2010 08:16:37 UTC FreeBSD 9.0-CURRENT #20: Fri Feb 12 19:21:34 CET 2010 ncpnc Kernel Version: 900009 (osreldate) Hardware Platform: i386 Processor Architecture: i386 Storage pool Version: 14 Filesystem Version: 3 Physical RAM: 1523.41 MiB Kernel Memory Usage TEXT: 9782828, 9.33 MiB DATA: 216801280, 206.76 MiB TOTAL: 226584108, 216.09 MiB 9:16 up 4 days, 6:54, 1 user, load averages: 0,47 0,92 0,59 --------------------------------------------------------------------- ARC Summary Meta Limit: 120.00 MiB Meta Used: 135.00% 162.00 MiB Throttle Count: 0 ARC Size: Current Size: 190.03 MiB (arcsize) Target Size (Adaptive): 209.12 MiB (c) Min Size (Hard Limit): 60.00 MiB (arc_min) Max Size (Hard Limit): 480.00 MiB (arc_max) ARC Size Breakdown: Recently Used Cache Size: 16.00% 33.46 MiB (p) Frequently Used Cache Size: 84.00% 175.66 MiB (c-p) ARC Efficiency: Cache Access Total: 28459411 Cache Hit Ratio: 94.57% 26913166 Cache Miss Ratio: 5.43% 1546245 Actual Hit Ratio: 81.81% 23282481 Data Demand Efficiency: 99.48% Data Prefetch Efficiency: 54.15% CACHE HITS BY CACHE LIST: Anonymous: 11.07% 2978474 Most Recently Used: 16.42% 4419712 (mru) Most Frequently Used: 70.09% 18862769 (mfu) Most Recently Used Ghost: 0.98% 264205 (mru_ghost) Most Frequently Used Ghost: 1.44% 388006 (mfu_ghost) CACHE HITS BY DATA TYPE: Demand Data: 53.58% 14419664 Prefetch Data: 0.07% 20017 Demand Metadata: 32.68% 8794182 Prefetch Metadata: 13.67% 3679303 CACHE MISSES BY DATA TYPE: Demand Data: 4.88% 75410 Prefetch Data: 1.10% 16946 Demand Metadata: 59.18% 915133 Prefetch Metadata: 34.84% 538756 L2 ARC Summary Low Memory Aborts: 0 Bad Checksums: 0 IO Errors: 0 L2 ARC Size: Current Size: 0.00 MiB Header Size: 0.00 MiB L2 ARC Breakdown: L2 Access Total: 0 Illegal division by zero at ./arc_summary.pl line 242. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 08:32:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52D73106568F for ; Wed, 17 Feb 2010 08:32:59 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 09E7B8FC22 for ; Wed, 17 Feb 2010 08:32:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXZ0073892DL0E0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 09:32:37 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXZ00EPF92D1X00@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 09:32:37 +0100 (CET) Date: Wed, 17 Feb 2010 09:32:37 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100217093237.fe4b4e14.torfinn.ingolfsen@broadpark.no> In-reply-to: <4B7BA6A5.9020306@it4pro.pl> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> <20100216200511.GA95812@server.vk2pj.dyndns.org> <20100216215637.GA4299@icarus.home.lan> <4B7BA6A5.9020306@it4pro.pl> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 08:32:59 -0000 On Wed, 17 Feb 2010 09:19:49 +0100 Bartosz Stec wrote: > So here's my reply (last line seems most interesting ;) : [...snipped...] > Illegal division by zero at ./arc_summary.pl line 242. FWIW, I also got this line when I ran this script on my idle zfs server. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 08:42:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBC2C106566B for ; Wed, 17 Feb 2010 08:42:36 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7646A8FC15 for ; Wed, 17 Feb 2010 08:42:36 +0000 (UTC) Received: by iwn5 with SMTP id 5so3128793iwn.9 for ; Wed, 17 Feb 2010 00:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=pRxrNaEJlh2izYjxHBGIH1JJ+UvNg4eviYy00B0uUEc=; b=oQ6CcfxfSA9z4TRc1z/ApUOGJJF7nJxnc6LDxuMLrzL/35AVb/TAefB/gVu0e5GdRJ 3NBQY+GsVwzedepl0gWON5pHjSa54A2iYwcRW62QtvuDNbHOjIs1RTDiz5Gucm0/5CyU vU9WpP9Ss4jcdUEbM4kdNu8s0nJOAdOKKCW/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=rExRnCZCMKHgvaaHCjJ8AVNPew9sD732pyaVw5h1YakW/9cQAG0y/6Kt19KbD8JYGj 43Cl3jEIUCr9W0fvJ7CS6stjvQAnNWjh7E42NbjzAbQdAzQi3q+CJ97wCJC44R0DsmUA 2J+Zts4gL7VdyycQ/rHBz2VcxdaNaka10kIWg= Received: by 10.231.147.70 with SMTP id k6mr1764419ibv.55.1266396155882; Wed, 17 Feb 2010 00:42:35 -0800 (PST) Received: from centel.dataix.local (ppp-21.195.dialinfree.com [209.172.21.195]) by mx.google.com with ESMTPS id 21sm1778050iwn.14.2010.02.17.00.42.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 00:42:34 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 17 Feb 2010 03:42:28 -0500 From: jhell To: Barry Pederson In-Reply-To: <4B7AD0A3.9080701@barryp.org> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 08:42:36 -0000 On Tue, 16 Feb 2010 12:06, bp@ wrote: > On 2/15/10 7:49 PM, jhell wrote: > >> As I make final modifications to the script I will keep the below URLs >> updated and welcome any bug reports or modification requests to me >> personally. >> >> Here is the URLs: >> http://jhell.googlecode.com/files/arc_summary.pl >> http://jhell.googlecode.com/files/arc_summary.pl.asc > > Nice. How about including relevant lines from /boot/loader.conf, maybe > something like this tacked on the end of the script (excuse my Perl, I'm a > Python guy). > > ---- > #### Loader Settings ############# > open(LOADER, '/boot/loader.conf'); > print "\n/boot/loader.conf settings:\n"; > while (){ > chomp; > if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){ > print "\t$_\n"; > } > } > ---- > > Yes, it should more or less duplicate the sysctl values, but it may make it > more obvious where the settings are coming from, or if the user has bad or > ignored settings > > Barry > Hi Barry, This is a very nice idea so please do not get me wrong when I say that I would rather stay away from having to open config files and start comparing results. I don't feel that this is in the place of the script to do this type of action and can lead to confusion upon the users behalf. sysctl(8) is by far better off getting the values from a running system rather than parsing values obtained from a file that does not change the system except for after a reboot upon which the values outlined in loader.conf can be obtained from sysctl mibs. The latest version of the script that I have uploaded has the sysctl mibs spilled out at the bottom. These are mibs that I felt were relevent to the tuning of ZFS and FreeBSD obtained from various sources and memory recall so I might have missed a few so if you or anyone else has a mib to be added please forward them to me in a email and I will be sure to add it. Regards, and thanks for the feedback. -- jhell From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 08:43:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48F261065693 for ; Wed, 17 Feb 2010 08:43:25 +0000 (UTC) (envelope-from "cyb."@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A14828FC17 for ; Wed, 17 Feb 2010 08:43:24 +0000 (UTC) Received: (qmail invoked by alias); 17 Feb 2010 08:16:42 -0000 Received: from pD952D170.dip0.t-ipconnect.de (EHLO core2duo) [217.82.209.112] by mail.gmx.net (mp005) with SMTP; 17 Feb 2010 09:16:42 +0100 X-Authenticated: #4870692 X-Provags-ID: V01U2FsdGVkX1+K1vVSUU6K1vIjCEaG4Xkjfvuh0QbEHJcVy3XyRJ mjZvo+1oxLlkql Date: Wed, 17 Feb 2010 09:16:38 +0100 From: Andreas Rudisch To: Christian Schramm Message-Id: <20100217091638.252fc866.cyb.@gmx.net> In-Reply-To: <4B7AFA79.6060508@parative.org> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> <201002131137.34812.npapke@acm.org> <1266096425.89452.30.camel@balrog.2hip.net> <20100215142305.3f0d7e65@miknet.dk> <1266249418.11131.7.camel@balrog.2hip.net> <4B7AFA79.6060508@parative.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__17_Feb_2010_09_16_38_+0100_oLalI.NlezyIrkGo" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64000000000000001 Cc: freebsd-stable@freebsd.org Subject: Re: blank X screen with differnt cards X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 08:43:25 -0000 --Signature=_Wed__17_Feb_2010_09_16_38_+0100_oLalI.NlezyIrkGo Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 16 Feb 2010 21:05:13 +0100 Christian Schramm wrote: > Hi > at first this is my first message to a mailing list. Second sorry for my= =20 > bad english. >=20 > On Saturday i have installed 8-0-Release, after I build 8-stable include= =20 > world an d kernel. After the build of stable I build some ports also=20 > xorg-minimal >=20 > I press Xorg -configure and X -config /root/xorg.conf.new but my CRT=20 > Screen is blank. I can switch in tty0 an kill Xorg with CTRL-C. Take a look at this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html The next step is to test the existing configuration to verify that Xorg can work with the graphics hardware on the target system. In Xorg versions up to 7.3, type: # Xorg -config xorg.conf.new Starting with Xorg 7.4 and above, this test produces a black screen which may make it difficult to diagnose whether X11 is working properly. The older behavior is still available by using the retro option: # Xorg -config xorg.conf.new -retro Andreas -- GnuPG key : 0x2A573565 | http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 --Signature=_Wed__17_Feb_2010_09_16_38_+0100_oLalI.NlezyIrkGo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) iEYEARECAAYFAkt7peYACgkQ8P3NNypXNWUCMwCeKUlz8wQu4LlkiVdo7R4PYt0x B2cAoJWpL7tAI+WmWuub0IMSEHhy9Pf4 =1VYw -----END PGP SIGNATURE----- --Signature=_Wed__17_Feb_2010_09_16_38_+0100_oLalI.NlezyIrkGo-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 08:48:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 835AC106566B for ; Wed, 17 Feb 2010 08:48:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDD68FC13 for ; Wed, 17 Feb 2010 08:48:01 +0000 (UTC) Received: by iwn5 with SMTP id 5so3130239iwn.9 for ; Wed, 17 Feb 2010 00:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=euM4CbQYVmdqBTJA1nWSWyfXNHjE/j8tv0UTka6azlQ=; b=N2KPe115di2qtvNC9Vwga2z046lx30ZO79Mtw799weZrp3a/ASDNI07FSRhdWdLLZW nBLsstXimtLs6VD6UKGgOY+rYO/SqZP77NEovbNCQoSYduCFIgDcUFQ9tWKtt8BrKdeo mHTJGMOe2aJpnLafhCfKMCYeI4HexTASujz3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=WO8Wo9A9UbNpiQjPb3kHgybdYyde/4T9GBUzJu0XfZmq68TeZUntIOO33bDtWdv4/v mfr2zFobfPZl25YqXvGkFrj4vl0iycNAxz9zZ5/pqfSWgdUQL4LEXPYJJu2hftXYV/Am DKvK2u/UQrGVYmEv1ehOC0z/jYfyP30wpqmU4= Received: by 10.231.145.5 with SMTP id b5mr7079418ibv.70.1266396481495; Wed, 17 Feb 2010 00:48:01 -0800 (PST) Received: from centel.dataix.local (ppp-21.195.dialinfree.com [209.172.21.195]) by mx.google.com with ESMTPS id 23sm7940837iwn.15.2010.02.17.00.47.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 00:48:00 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 17 Feb 2010 03:47:54 -0500 From: jhell To: Jeremy Chadwick In-Reply-To: <20100216175946.GA98082@icarus.home.lan> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 08:48:02 -0000 On Tue, 16 Feb 2010 12:59, freebsd@ wrote: > On Tue, Feb 16, 2010 at 11:06:43AM -0600, Barry Pederson wrote: >> On 2/15/10 7:49 PM, jhell wrote: >> >>> As I make final modifications to the script I will keep the below URLs >>> updated and welcome any bug reports or modification requests to me >>> personally. >>> >>> Here is the URLs: >>> http://jhell.googlecode.com/files/arc_summary.pl >>> http://jhell.googlecode.com/files/arc_summary.pl.asc >> >> Nice. How about including relevant lines from /boot/loader.conf, >> maybe something like this tacked on the end of the script (excuse my >> Perl, I'm a Python guy). >> >> ---- >> #### Loader Settings ############# >> open(LOADER, '/boot/loader.conf'); >> print "\n/boot/loader.conf settings:\n"; >> while (){ >> chomp; >> if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){ >> print "\t$_\n"; >> } >> } >> ---- >> >> Yes, it should more or less duplicate the sysctl values, but it may >> make it more obvious where the settings are coming from, or if the >> user has bad or ignored settings > > Major problems with the above code: > > 1) Opens /boot/loader.conf for rw access; should be read-only > 2) Makes the assumption /boot/loader.conf exists > 3) Does not close the fd > 4) Excessively quotes variables for no justified reason > 5) Makes some bad assumptions about the contents of the file (ex. > comments with the word "zfs" in them would match) > > The code should really be something like what's below. This should > be much more manageable as well (@tunables that is), although I always > worry when using grep()... > > Very nice!, Ill keep this for reference later on. This might just come in handy at some point. But for the sake of arc_summary.pl I feel this is beyond the scope of what its intended use is. See previous email in response to Barry. Thanks Jeremy -- jhell From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 08:57:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 753331065679 for ; Wed, 17 Feb 2010 08:57:10 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id DE67D8FC14 for ; Wed, 17 Feb 2010 08:57:09 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NhfiP-0001m2-Ou for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 09:57:08 +0100 Message-ID: <4B7BAF59.7040407@it4pro.pl> Date: Wed, 17 Feb 2010 09:56:57 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100125 Shredder/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> <20100216200511.GA95812@server.vk2pj.dyndns.org> <20100216215637.GA4299@icarus.home.lan> <4B7BA6A5.9020306@it4pro.pl> <20100217093237.fe4b4e14.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20100217093237.fe4b4e14.torfinn.ingolfsen@broadpark.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.2 X-Spam-Score-Int: -81 X-Exim-Version: 4.71 (build at 02-Feb-2010 20:10:28) X-Date: 2010-02-17 09:57:08 X-Connected-IP: 78.8.144.74:63200 X-Message-Linecount: 45 X-Body-Linecount: 32 X-Message-Size: 2221 X-Body-Size: 1039 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 08:57:10 -0000 On 2010-02-17 09:32, Torfinn Ingolfsen wrote: > On Wed, 17 Feb 2010 09:19:49 +0100 > Bartosz Stec wrote: > > >> So here's my reply (last line seems most interesting ;) : >> > [...snipped...] > >> Illegal division by zero at ./arc_summary.pl line 242. >> > FWIW, I also got this line when I ran this script on my idle zfs server. > I'm not a PERL programmer (or programmer at all ;), but what I see is script doesn't check if L2ARC is used at all, so it will always try compute these lines: printf("\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_hits / ( $l2_hits + $l2_misses )), $l2_hits ); printf("\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_misses / ( $l2_hits + $l2_misses )), $l2_misses ); printf("\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_feeds / ( $l2_hits + $l2_misses )), $l2_feeds ); Without active L2ARC it will always generate divide at zeo error, so it seems that additional check for usable L2ARC values is needed at first place. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 09:30:56 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B8C01065692 for ; Wed, 17 Feb 2010 09:30:56 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id E70928FC13 for ; Wed, 17 Feb 2010 09:30:55 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.3/8.14.3) with ESMTP id o1H9UqLo062496 for ; Wed, 17 Feb 2010 10:30:52 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.3/8.14.3/Submit) id o1H9Upiu062495 for stable@freebsd.org; Wed, 17 Feb 2010 10:30:51 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Wed, 17 Feb 2010 10:30:51 +0100 From: Ruben de Groot To: stable@freebsd.org Message-ID: <20100217093051.GA61483@ei.bzerk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Wed, 17 Feb 2010 10:30:54 +0100 (CET) Cc: Subject: devd hang after upgrade to 8.0-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 09:30:56 -0000 Just wondering if others have seen this too. Yesterday, after upgrading from 7.2-stable to 8.0-stable, my server would hang on startup on the "Starting devd" line. bootverbose did not get me any more information, and I had to manually hit ^C or ^\ to continue booting. Also, the reboot command will hang after killing syslogd. Only a reboot -q will actually reboot the system. Now, I've disabled devd in rc.conf, but this is not an ideal configuration for me. Any hints on how to further debug this? cheers, Ruben From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 09:33:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF5B01065672 for ; Wed, 17 Feb 2010 09:33:07 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-gx0-f219.google.com (mail-gx0-f219.google.com [209.85.217.219]) by mx1.freebsd.org (Postfix) with ESMTP id A2B838FC0C for ; Wed, 17 Feb 2010 09:33:07 +0000 (UTC) Received: by gxk19 with SMTP id 19so751199gxk.3 for ; Wed, 17 Feb 2010 01:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3syGoO1Ap4Vd4TGujS01BGbZPcXfvfVHzaVbUVJ4tWg=; b=MXiN5THCo4KWJOBJCpa0ogpfrjXYjc2jO12R9YCiRrSl+905Yi6RkR8dBz+SrtqmQg IV9ClbqM8TVWMDirsmiEF5+OHi5jXoudRsByAVY/v+2RKb6hlSbwufn5/u5xz1U1wGDC nElOyedrZnpFwID9mioqpaQVTcm4K0vuuIsUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YAjsTqDQSq0I2NBNl+Cv7vp9hh4eAH5BKbfk22N4l5IQglsAsxbJUFwEeGGJNhKDQq fc5dA0WO2JeIdQ3on0UR/Xa2XFUk8JH+ZwsVXc9ApqBS/hb3KttSKFH3mxDCN1MbS6nX Nr7SPzwBwuWF9O+rWTmMPihH/KmCzG/c530nE= MIME-Version: 1.0 Received: by 10.90.246.19 with SMTP id t19mr3942723agh.119.1266398856914; Wed, 17 Feb 2010 01:27:36 -0800 (PST) In-Reply-To: <4B7BAF59.7040407@it4pro.pl> References: <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> <20100216200511.GA95812@server.vk2pj.dyndns.org> <20100216215637.GA4299@icarus.home.lan> <4B7BA6A5.9020306@it4pro.pl> <20100217093237.fe4b4e14.torfinn.ingolfsen@broadpark.no> <4B7BAF59.7040407@it4pro.pl> Date: Wed, 17 Feb 2010 03:27:36 -0600 Message-ID: <790a9fff1002170127s153a6813p5e92055dc5d94ba2@mail.gmail.com> From: Scot Hetzel To: jhell , Bartosz Stec Content-Type: multipart/mixed; boundary=001636283dce02a68e047fc8769e Cc: freebsd-stable@freebsd.org Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 09:33:08 -0000 --001636283dce02a68e047fc8769e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 17, 2010 at 2:56 AM, Bartosz Stec wrot= e: > On 2010-02-17 09:32, Torfinn Ingolfsen wrote: >> >> On Wed, 17 Feb 2010 09:19:49 +0100 >> Bartosz Stec =A0wrote: >> >> >>> >>> So here's my reply (last line seems most interesting ;) : >>> >> >> [...snipped...] >> >>> >>> Illegal division by zero at ./arc_summary.pl line 242. >>> >> >> FWIW, I also got this line when I ran this script on my idle zfs server. >> > > I'm not a PERL programmer (or programmer at all ;), but what I see is scr= ipt > doesn't check if L2ARC is used at all, so it will always try compute thes= e > lines: > > printf("\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_hits / ( $l2_hit= s + > $l2_misses )), $l2_hits ); > printf("\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_misses / ( > $l2_hits + $l2_misses )), $l2_misses ); > printf("\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_feeds / ( > $l2_hits + $l2_misses )), $l2_feeds ); > > Without active L2ARC it will always generate divide at zeo error, so it > seems that additional check for usable L2ARC values is needed at first > place. > The attached patch fixes the divide by zero errors. Scot --001636283dce02a68e047fc8769e Content-Type: application/octet-stream; name=patch1 Content-Disposition: attachment; filename=patch1 Content-Transfer-Encoding: base64 X-Attachment-Id: f_g5rwz9800 LS0tIGFyY19zdW1tYXJ5LnBsLW9yaWcJMjAxMC0wMi0xNyAwNzozMDo0OS4wMDAwMDAwMDAgKzAw MDAKKysrIGFyY19zdW1tYXJ5LnBsCTIwMTAtMDItMTcgMDM6MTA6MzEuODA4OTYwNjM1ICswMDAw CkBAIC0yMTAsNiArMjEwLDcgQEAKICMjIyMgTDIgQVJDIFN0YXRzIFN5c2N0bCdzICMjIyMjIyMj IyMjIyMKIG15ICRsMl9oaXRzID0gJHtLc3RhdH0tPnt6ZnN9LT57MH0tPnthcmNzdGF0c30tPnts Ml9oaXRzfTsgIyB1c2VkCiBteSAkbDJfbWlzc2VzID0gJHtLc3RhdH0tPnt6ZnN9LT57MH0tPnth cmNzdGF0c30tPntsMl9taXNzZXN9OyAjIHVzZWQKK215ICRsMl9oaXRzX21pc3NlcyA9ICRsMl9o aXRzICsgJGwyX21pc3NlczsgIyB1c2VkCiBteSAkbDJfZmVlZHMgPSAke0tzdGF0fS0+e3pmc30t PnswfS0+e2FyY3N0YXRzfS0+e2wyX2ZlZWRzfTsgIyB1c2VkCiBteSAkbDJfcndfY2xhc2ggPSAk e0tzdGF0fS0+e3pmc30tPnswfS0+e2FyY3N0YXRzfS0+e2wyX3J3X2NsYXNofTsKIG15ICRsMl93 cml0ZXNfc2VudCA9ICR7S3N0YXR9LT57emZzfS0+ezB9LT57YXJjc3RhdHN9LT57bDJfd3JpdGVz X3NlbnR9OyAjIHVzZWQKQEAgLTIzOCwxOCArMjM5LDM4IEBACiBwcmludCAiXG4iOwogCiBwcmlu dCAiTDIgQVJDIEJyZWFrZG93bjpcbiI7Ci1wcmludGYoIlx0TDIgQWNjZXNzIFRvdGFsOlx0XHRc dCVkXG4iLCAoICRsMl9oaXRzICsgJGwyX21pc3NlcyApICk7Ci1wcmludGYoIlx0TDIgSGl0IFJh dGlvOlx0XHRcdCUwLjJmJSVcdCVkXG4iLCAxMDAgKiAoICRsMl9oaXRzIC8gKCAkbDJfaGl0cyAr ICRsMl9taXNzZXMgKSksICRsMl9oaXRzICk7Ci1wcmludGYoIlx0TDIgTWlzcyBSYXRpbzpcdFx0 XHQlMC4yZiUlXHQlZFxuIiwgMTAwICogKCAkbDJfbWlzc2VzIC8gKCAkbDJfaGl0cyArICRsMl9t aXNzZXMgKSksICRsMl9taXNzZXMgKTsKLXByaW50ZigiXHRMMiBGZWVkcyBSYXRpbzpcdFx0XHQl MC4yZiUlXHQlZFxuIiwgMTAwICogKCAkbDJfZmVlZHMgLyAoICRsMl9oaXRzICsgJGwyX21pc3Nl cyApKSwgJGwyX2ZlZWRzICk7CitwcmludGYoIlx0TDIgQWNjZXNzIFRvdGFsOlx0XHRcdCVkXG4i LCAoICRsMl9oaXRzX21pc3NlcyApICk7CitpZiAoICRsMl9oaXRzX21pc3NlcyA+IDApIHsKKwlw cmludGYoIlx0TDIgSGl0IFJhdGlvOlx0XHRcdCUwLjJmJSVcdCVkXG4iLCAxMDAgKiAoICRsMl9o aXRzIC8gKCAkbDJfaGl0c19taXNzZXMgKSksICRsMl9oaXRzICk7CisJcHJpbnRmKCJcdEwyIE1p c3MgUmF0aW86XHRcdFx0JTAuMmYlJVx0JWRcbiIsIDEwMCAqICggJGwyX21pc3NlcyAvICggJGwy X2hpdHNfbWlzc2VzICkpLCAkbDJfbWlzc2VzICk7CisJcHJpbnRmKCJcdEwyIEZlZWRzIFJhdGlv Olx0XHRcdCUwLjJmJSVcdCVkXG4iLCAxMDAgKiAoICRsMl9mZWVkcyAvICggJGwyX2hpdHNfbWlz c2VzICkpLCAkbDJfZmVlZHMgKTsKK30gZWxzZSB7CisJcHJpbnRmKCJcdEwyIEhpdCBSYXRpbzpc dFx0XHRVbmtub3duXHQlZFxuIiwgJGwyX2hpdHMgKTsKKwlwcmludGYoIlx0TDIgTWlzcyBSYXRp bzpcdFx0XHRVbmtub3duXHQlZFxuIiwgJGwyX21pc3NlcyApOworCXByaW50ZigiXHRMMiBGZWVk cyBSYXRpbzpcdFx0XHRVbmtub3duXHQlZFxuIiwgICRsMl9mZWVkcyApOworfQogcHJpbnQgIlxu IjsKIAotcHJpbnRmKCAiXHRMMiBSZWFkczpcdFx0XHQlMC4yZiUlXHQlZFxuIiwgMTAwICogKCgg JGwyX2hpdHMgKyAkbDJfbWlzc2VzIC0gJGwyX3dyaXRlc19zZW50ICkgLyAoICRsMl9oaXRzICsg JGwyX21pc3NlcyApKSwgKCAkbDJfaGl0cyArICRsMl9taXNzZXMgLSAkbDJfd3JpdGVzX3NlbnQg KSk7CitpZiAoICRsMl9oaXRzX21pc3NlcyA+IDApIHsKKwlwcmludGYoICJcdEwyIFJlYWRzOlx0 XHRcdCUwLjJmJSVcdCVkXG4iLCAxMDAgKiAoKCAkbDJfaGl0c19taXNzZXMgLSAkbDJfd3JpdGVz X3NlbnQgKSAvICggJGwyX2hpdHNfbWlzc2VzICkpLCAoICRsMl9oaXRzX21pc3NlcyAtICRsMl93 cml0ZXNfc2VudCApKTsKK30gZWxzZSB7CisJIHByaW50ZiggIlx0TDIgUmVhZHM6XHRcdFx0VW5r bm93blx0JWRcbiIsICggJGwyX2hpdHNfbWlzc2VzIC0gJGwyX3dyaXRlc19zZW50ICkpOworfQog cHJpbnQgIlxuIjsKKwogcHJpbnQgIlx0TDIgV3JpdGVzOlxuIjsKLXByaW50ZigiXHQgIFNlbnQg UmF0aW86XHRcdFx0JTAuMmYlJVx0JWRcbiIsIDEwMCAqICggJGwyX3dyaXRlc19zZW50IC8gKCRs Ml9oaXRzICsgJGwyX21pc3NlcykpLCAkbDJfd3JpdGVzX3NlbnQgKTsKLXByaW50ZigiXHQgIERv bmUgUmF0aW86XHRcdFx0JTAuMmYlJVx0JWRcbiIsIDEwMCAqICggJGwyX3dyaXRlc19kb25lIC8g JGwyX3dyaXRlc19zZW50ICksICRsMl93cml0ZXNfZG9uZSApOwotcHJpbnRmKCJcdCAgRXJyb3Ig UmF0aW86XHRcdFx0JTAuMmYlJVx0JWRcbiIsIDEwMCAqICggJGwyX3dyaXRlc19lcnJvciAvICRs Ml93cml0ZXNfc2VudCApLCAkbDJfd3JpdGVzX2Vycm9yICk7CitpZiAoICRsMl9oaXRzX21pc3Nl cyA+IDApIHsKKwlwcmludGYoIlx0ICBTZW50IFJhdGlvOlx0XHRcdCUwLjJmJSVcdCVkXG4iLCAx MDAgKiAoICRsMl93cml0ZXNfc2VudCAvICgkbDJfaGl0c19taXNzZXMpKSwgJGwyX3dyaXRlc19z ZW50ICk7Cit9IGVsc2UgeworCXByaW50ZigiXHQgIFNlbnQgUmF0aW86XHRcdFx0VW5rbm93blx0 JWRcbiIsICRsMl93cml0ZXNfc2VudCApOworfQoraWYgKCAkbDJfd3JpdGVzX3NlbnQgPiAwKSB7 CisJcHJpbnRmKCJcdCAgRG9uZSBSYXRpbzpcdFx0XHQlMC4yZiUlXHQlZFxuIiwgMTAwICogKCAk bDJfd3JpdGVzX2RvbmUgLyAkbDJfd3JpdGVzX3NlbnQgKSwgJGwyX3dyaXRlc19kb25lICk7CisJ cHJpbnRmKCJcdCAgRXJyb3IgUmF0aW86XHRcdFx0JTAuMmYlJVx0JWRcbiIsIDEwMCAqICggJGwy X3dyaXRlc19lcnJvciAvICRsMl93cml0ZXNfc2VudCApLCAkbDJfd3JpdGVzX2Vycm9yICk7Cit9 IGVsc2UgeworCXByaW50ZigiXHQgIERvbmUgUmF0aW86XHRcdFx0VW5rbm93blx0JWRcbiIsICRs Ml93cml0ZXNfZG9uZSApOworCXByaW50ZigiXHQgIEVycm9yIFJhdGlvOlx0XHRcdFVua25vd25c dCVkXG4iLCAkbDJfd3JpdGVzX2Vycm9yICk7Cit9CiBwcmludCAiXG5cbiI7CiAKICMjIyMgVHVu YWJsZXMgIyMjIyMjIyMjIyMjIyMjIyMjIyMjCg== --001636283dce02a68e047fc8769e-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 09:53:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36FDA106566B for ; Wed, 17 Feb 2010 09:53:36 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id E147D8FC0C for ; Wed, 17 Feb 2010 09:53:35 +0000 (UTC) Received: by iwn5 with SMTP id 5so3146187iwn.9 for ; Wed, 17 Feb 2010 01:53:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=5Pa3yjattPbCcmSBtU1/I//fbsl6MUY/5wmVW/kBBY4=; b=sGEfZoao1YRaEK19Fk4uGIahDnQBuo9qxhxK8GBmanJgENiybBV26J0AshBd4Ec3T8 /vkWc6c93KjLWJZu07dSJ70VZbQOn97iN9DtDQQDDEdrm0z2l+fUilMiNcBtcTcKNb/J eLe1sQVZTpOMrIJ9QzGod28VWJXfVS57sOtlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=r5wfE4l70Yz6YRU+Kh3GLVlsLxp6erFF3eSJ1NR2lIBTntvCOgkcYCaFcdaYpdqmBb kNIO/RkDllVD37zSfue3FK0DTZmmJKBio8Qj217nTlewqdBw9zBCbb7XiSQolr66Uz+O r+6Zb6HK59loZxXL4pb5fRT/S/SGBgAFkPjtI= Received: by 10.231.79.136 with SMTP id p8mr7719545ibk.4.1266400415254; Wed, 17 Feb 2010 01:53:35 -0800 (PST) Received: from centel.dataix.local (ppp-21.195.dialinfree.com [209.172.21.195]) by mx.google.com with ESMTPS id 21sm7996606iwn.2.2010.02.17.01.53.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 01:53:34 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 17 Feb 2010 04:53:20 -0500 From: jhell To: Bartosz Stec In-Reply-To: <4B7BAF59.7040407@it4pro.pl> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> <20100216200511.GA95812@server.vk2pj.dyndns.org> <20100216215637.GA4299@icarus.home.lan> <4B7BA6A5.9020306@it4pro.pl> <20100217093237.fe4b4e14.torfinn.ingolfsen@broadpark.no> <4B7BAF59.7040407@it4pro.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 09:53:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 17 Feb 2010 03:56, bartosz.stec@ wrote: > On 2010-02-17 09:32, Torfinn Ingolfsen wrote: >> On Wed, 17 Feb 2010 09:19:49 +0100 >> Bartosz Stec wrote: >> >> >>> So here's my reply (last line seems most interesting ;) : >>> >> [...snipped...] >> >>> Illegal division by zero at ./arc_summary.pl line 242. >>> >> FWIW, I also got this line when I ran this script on my idle zfs server. >> > I'm not a PERL programmer (or programmer at all ;), but what I see is script > doesn't check if L2ARC is used at all, so it will always try compute these > lines: > > printf("\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_hits / ( $l2_hits + > $l2_misses )), $l2_hits ); > printf("\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_misses / ( $l2_hits > + $l2_misses )), $l2_misses ); > printf("\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_feeds / ( $l2_hits > + $l2_misses )), $l2_feeds ); > > Without active L2ARC it will always generate divide at zeo error, so it seems > that additional check for usable L2ARC values is needed at first place. > > Thanks for reporting this. As I am usually on a system that is using a L2ARC I wouldn't have noticed it. I should have this fixed in about 10 hours. But as I am writing this email I am heading off to bed, work calls in the morning. Check back tomorrow night for a updated version and adjust the current to your liking for the moment. ;) Thanks again. - -- jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe7yXAAoJEJBXh4mJ2FR+NyAH/jBS6W0b9tZZVOm5nQ+kmjG2 CZxWqkkNe6ldQ3ggdmSNlz324Vr+6ZpHvLHjlpRDloyCEX2//9exzpDAMY/3yYL/ 4hrY7WeaAVDhwaCmvVxyiuP3QFnF1ENl+mMBxpbc6sYoYpDJ1900qh/0FFFjIRxm V9vaBWl1vYzLxiAp55b+UBLI5NNPEKTJgxQMBAflh24A3KuDtNijS23EEeA/g2vq eZorXS/55n5ZJxVWXMOn0i9IKdpn0sYPu5xoMWCihKxN6KRnighBfr9BIjpXZEEC rktEX4wY4bOMpULQJff/9MAjlisq5jvsY7JulYHX22D+HjC4/Z3TLQ/RVCI2d5Q= =GRta -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 10:39:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B7FE106566B for ; Wed, 17 Feb 2010 10:39:18 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id D4F808FC17 for ; Wed, 17 Feb 2010 10:39:17 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1HAdGBP095030 for ; Wed, 17 Feb 2010 12:39:16 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B7BC74C.702@eng.auth.gr> Date: Wed, 17 Feb 2010 12:39:08 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B74502C.3080906@eng.auth.gr> <4B75D4C4.10400@eng.auth.gr> In-Reply-To: <4B75D4C4.10400@eng.auth.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 10:39:18 -0000 On 13/02/2010 00:23, George Mamalakis wrote: > On 12/2/2010 8:48 πμ, jhell wrote: >> >> >> This is a lot of information to consume. >> >> Lets start with this: >> >> All of the machines in question are of some form of FreeBSD 8. >> >> You enter gdb and very clearly it starts whining about a segfault & >> libc.so.7 >> >> Did you happen to upgrade these clients & server from FreeBSD 7 ? >> >> AFAIK the libc version on FreeBSD 8 was bumped to libc.so.8 >> >> If you upgraded and from source did you run make delete-old and make >> delete-old-libs after your make install and after your mergemaster ? >> >> Will wait here for results. >> >> Best wishes. >> > Guys(?!), anybody having taken a look at the issue or has an opinion/workaround whatsoever? Thanks again. mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 11:18:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE11E106566C for ; Wed, 17 Feb 2010 11:18:16 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8278C8FC13 for ; Wed, 17 Feb 2010 11:18:16 +0000 (UTC) Received: by iwn5 with SMTP id 5so3165431iwn.9 for ; Wed, 17 Feb 2010 03:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=HFTegxz9fgJ/mqz8XE2bsRQYl6DgkzFEYPRq7FFUVBA=; b=Yhu7NDgAXkr2gGZJ5F3yojZRG8BMNZmZJyaGBINk9VX6prxT8nO7evneQhw5n3AHjo K9e3DKgVhr1nOB4za5MSMkmvtcedYvh/FPHMTzBjoaKMwPdJVEsIGcLmRTqeuYegLK3A aI4QWixIULHREWlfkU8H+L9Dt3xoytNeKFSeA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=C0OXmc0VVVJ1of6tIUODR2w5JztV7Qcfxekzghz1e4p/ChZ5UkwaaDH34Ty00GGwSQ ENhNsQx6cf2iQu6roi3Hb+RP8Ke20uy4f5Xp5AsyweH8a5LdyXDDgC5ImEUbIUl6koPX /vLObUeXGp78k/kUuJGIC5KPcP1kR8Y0UB04Y= Received: by 10.231.145.196 with SMTP id e4mr3968772ibv.54.1266405495812; Wed, 17 Feb 2010 03:18:15 -0800 (PST) Received: from centel.dataix.local (ppp-21.195.dialinfree.com [209.172.21.195]) by mx.google.com with ESMTPS id 20sm1929715iwn.1.2010.02.17.03.18.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 03:18:14 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 17 Feb 2010 06:18:01 -0500 From: jhell To: Bartosz Stec In-Reply-To: Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <20100216175946.GA98082@icarus.home.lan> <20100216200511.GA95812@server.vk2pj.dyndns.org> <20100216215637.GA4299@icarus.home.lan> <4B7BA6A5.9020306@it4pro.pl> <20100217093237.fe4b4e14.torfinn.ingolfsen@broadpark.no> <4B7BAF59.7040407@it4pro.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 11:18:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 17 Feb 2010 04:53, jhell@ wrote: > ---------------------------- PGP Command Output ---------------------------- > gpg: Signature made Wed Feb 17 04:53:27 2010 EST using RSA key ID 89D8547E > gpg: Good signature from "jhell " > ----------- Begin PGP Signed Message Verified 2010-02-17 06:13:53 ---------- > > > > On Wed, 17 Feb 2010 03:56, bartosz.stec@ wrote: >> On 2010-02-17 09:32, Torfinn Ingolfsen wrote: >>> On Wed, 17 Feb 2010 09:19:49 +0100 >>> Bartosz Stec wrote: >>> >>> >>>> So here's my reply (last line seems most interesting ;) : >>>> >>> [...snipped...] >>> >>>> Illegal division by zero at ./arc_summary.pl line 242. >>>> >>> FWIW, I also got this line when I ran this script on my idle zfs server. >>> >> I'm not a PERL programmer (or programmer at all ;), but what I see is >> script >> doesn't check if L2ARC is used at all, so it will always try compute these >> lines: >> >> printf("\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_hits / ( $l2_hits >> + >> $l2_misses )), $l2_hits ); >> printf("\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_misses / ( >> $l2_hits >> + $l2_misses )), $l2_misses ); >> printf("\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_feeds / ( >> $l2_hits >> + $l2_misses )), $l2_feeds ); >> >> Without active L2ARC it will always generate divide at zeo error, so it >> seems >> that additional check for usable L2ARC values is needed at first place. >> >> > > Thanks for reporting this. As I am usually on a system that is using a > L2ARC I wouldn't have noticed it. > > I should have this fixed in about 10 hours. But as I am writing this email > I am heading off to bed, work calls in the morning. > > Check back tomorrow night for a updated version and adjust the current to > your liking for the moment. > > ;) Thanks again. > > -- > > jhell > > > ------------ End PGP Signed Message Verified 2010-02-17 06:13:53 ----------- > I take that back. I just uploaded a modified version that I wrapped with a if statement to check and see if l2_hits >= 0. If you don't have a L2ARC you will now get a message explaining why its not included in your summary. I couldn't sleep until I fixed this knowing that more people are probably going to come across this problem and email back. New rev: 184 MD5 (arc_summary.pl) = f47bac165e7bf707d5f81cfdd007c30a SHA256 (arc_summary.pl) = 794dce069ff649598d99204b362d141a19da47dcf60ec165b260d55a5c9d493f SIZE (arc_summary.pl) = 12695 http://jhell.googlecode.com/files/arc_summary.pl http://jhell.googlecode.com/files/arc_summary.pl.asc Now I can finally sleep ;) - -- jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe9BrAAoJEJBXh4mJ2FR+0K8IAKA43hk95Kll9mLfMWj5bUPp ZLlDzZPPy30Ign6wfbSO0wImLW0UVa9wAL0EwWb78F9T/3AJ2fQZFgWrOp/t+eV4 iKG8rsEy6t6YDYYZ7G6XnSibiCO+M+L+b6eSWMbcl/Ak8n+1PZUQisFevq/K0cCu 31ktjNxC6eqK1s0rKn/CgyXKO/rga60U12OHG9SLInM8J1dtHSGAp6kBO0B6C9+m uzEKOkUxXlYZpo+vlR9alByPWfiG9JqkgiYcOeXcgo0kb405cVT5jwBrOY9UnTb8 phxY6RXUViGP/quX2P+tGIYO47gDvBiGY/XRyTO1bmM+O0nPTnnKHpJg9NBvZ/g= =OFDn -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 11:31:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2D29106566B for ; Wed, 17 Feb 2010 11:31:40 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3058FC16 for ; Wed, 17 Feb 2010 11:31:40 +0000 (UTC) Received: by iwn5 with SMTP id 5so3168592iwn.9 for ; Wed, 17 Feb 2010 03:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:cc:subject :in-reply-to:message-id:references:user-agent:followup-to :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=VCTDzkvEbD63g8YN3v7Ujs5A+YL6JNSxrle3C8qswlg=; b=TKcpr8rzLXznyGDhathnE3dOW/s+bgNCJs44tXl+dOYxSBZszGnvrsFo0g4SJkfrbs Irc3eOSIN/XADQ0Flqt3ARUKM9bJzDdz5WFjjbqIhh5lqhTHEwxrCW6oNG/LfrUHe1Gn V4vloZsFGnp+4isEiwL94Fncz20S0SIqabE7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:cc:subject:in-reply-to:message-id:references :user-agent:followup-to:x-openpgp-key-id:x-openpgp-key-fingerprint :mime-version:content-type; b=DdDSBSGyfKkUhoKM8m+Vwno+Uwbj9B9I4GLpM7xFRUwnjg9rgRMq3/XpEt4vpgxaHp FIX0bhkIBlSGYhUy/PzgOIriQU0kH3Uaok+Owi+r/9dettz6PgoEH+BQAhnR0HEZKT3P QzZyJY0ZnSLLFJ9q4kaSCGnPnnl/xujkD2tRk= Received: by 10.231.151.212 with SMTP id d20mr3266563ibw.53.1266406299548; Wed, 17 Feb 2010 03:31:39 -0800 (PST) Received: from centel.dataix.local (ppp-21.195.dialinfree.com [209.172.21.195]) by mx.google.com with ESMTPS id 22sm1977602iwn.8.2010.02.17.03.31.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 03:31:37 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 17 Feb 2010 06:31:24 -0500 From: jhell cc: FreeBSD Stable In-Reply-To: <4B79BA9C.3020402@quip.cz> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Followup-To: freebsd-filesystems@freebsd.org X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: ZFS tuning [was: hardware for home use large storage] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 11:31:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Due to the nature of this thread and its current list involvement I am going to be starting a new thread in freebsd-filesystems@ just for arc_summary.pl tomorrow night with the subject below. [arc_summary.pl] Adjustments, PR & Requests I would appreciate if you would join me there for any response or problems that may arise for the use of this script. I don't feel that this list is any longer the correct place to hold this discussion as it is more ZFS centric than stable@ was meant for. If someone would like to start the subject off before I get to it please feel free. Thanks in advance. - -- jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe9OTAAoJEJBXh4mJ2FR+LdwH/0cCwnsWogtHfGyU4PJcu1fG PV/PxpgMKQsTIfckGI8ef/UPCG7lki6FD9+bPrsOrFy2ZuvGhK+jfxXsa+99Rt4h ovi6qopLjfHde9Ztd87E3Ds88kR0KEszdnDvbg7mr/xAz9V7hFrLWvmIqxaedg06 I+j932tUfFmA2xiExBWVjtHfdYD2YaO671SET0nPSGz0b6yRlfedOvTZvheI+l05 fB1pXQNwve1en6oDtBBb0pgoODI9HgrZyrQbJzTFH/hXremdO5Dv5AUULI/XKwNA KSSWRMRKYODdX7cDIDbS2+7GjLj1V85gdBc10usR4AqpSFl8aGmTIUfK187y+qs= =7QZB -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 12:34:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30FB11065670 for ; Wed, 17 Feb 2010 12:34:36 +0000 (UTC) (envelope-from h.skuhra@gmail.com) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by mx1.freebsd.org (Postfix) with ESMTP id AC2418FC08 for ; Wed, 17 Feb 2010 12:34:35 +0000 (UTC) Received: by bwz23 with SMTP id 23so1899003bwz.13 for ; Wed, 17 Feb 2010 04:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ZhIXvJ/rndLxmPf+1umOFogEy8PEeo9TBTyEaaSbfmo=; b=Xdcn7IhGjogDvGAhUViz/vytvTzjwa9wuX+qdXDcNVpwW2YHWsrpRYyqvE2NRzum9K CGgkBSb3prky7CYUH4KjhEfJJB7sMHGgawQZ/T6rreuibR8oBD+Cp3IpQ9qWOQ6Tpk4A IOnd+fbr2MRWw8WNNQVKvAp1YmrnaUDuUOQew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=to5F8pMPzJYDUjTD7BoJFcndM8bJhSJTeH7u1JByxNzLco8hrXZzgjNPEymA3oY/Am e6uPR1H3XVMW4EgozIW7l6Dv83RzgCPygBZIZoKtHqiHrQoAer0f3W4V9WBhUPxocF/Q 73Jr+/4iIXGYZxlu2Mb3VpKB80JvLTxc5qLFc= MIME-Version: 1.0 Received: by 10.204.16.88 with SMTP id n24mr1935989bka.89.1266408177737; Wed, 17 Feb 2010 04:02:57 -0800 (PST) In-Reply-To: <1266251479.6979.28.camel@bauer.cse.buffalo.edu> References: <1266251479.6979.28.camel@bauer.cse.buffalo.edu> Date: Wed, 17 Feb 2010 13:02:57 +0100 Message-ID: From: "Herbert J. Skuhra" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: 7.3-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 12:34:36 -0000 Hi! Today I tried to upgrade from 7.3-BETA2 to 7.3-RC1: # freebsd-update upgrade -r 7.3-RC1 # freebsd-update install # shutdown -r now # uname -a FreeBSD oslo.ath.cx 7.3-RC1 FreeBSD 7.3-RC1 #0: Wed Feb 10 07:47:42 UTC 2010 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Looks OK, but another "freebsd-update install" tells me that there are no updates available. Files in /bin /sbin /usr/bin /usr/sbin /usr/src were not updated. Only kernel changes? But why was /usr/src not updated? Thanks. -Herbert On Mon, Feb 15, 2010 at 5:31 PM, Ken Smith wrote: > > The second of the test builds for the 7.3-RELEASE cycle, 7.3-RC1, is now > available for amd64, i386, pc98, and sparc64 architectures. =C2=A0The tar= get > schedule as well as the current status of the release is available here: > > =C2=A0http://wiki.freebsd.org/Releng/7.3TODO > > The schedule has slipped by about a week but so far it looks like we are > on track for just having one more public test build (7.3-RC2) followed > by the release itself. =C2=A0If you notice problems you can report them > through the normal Gnats PR system or on the freebsd-stable mailing > list. > > ISO images for the architectures listed above are available on the FTP > mirror sites. =C2=A0Packages were included for amd64 and i386 architectur= es > though the list of packages is still preliminary and the packages > themselves were taken from what is currently available in the > packages-7-stable directories on the FTP servers. =C2=A0There have been s= ome > significant changes to the ports that are not incorporated in this set > of pre-built packages (e.g. the default version of perl has been updated > to 5.10). > > If you are using csup/cvsup methods to update an older system the branch > tag to use is now RELENG_7_3. =C2=A0Note that due to the mechanism still = in > place for exporting the SVN repository to CVS unfortunately the version > numbers for all the files get changed. =C2=A0If you have not looked into = it > before check out the -F argument for mergemaster(8). > > The freebsd-update(8) utility supports binary upgrades of i386 and amd64 > systems running earlier FreeBSD releases. =C2=A0Systems running 7.1-RELEA= SE > 7.2-RELEASE, or 7.3-BETA1 can upgrade as follows: > > # freebsd-update upgrade -r 7.3-RC1 > > During this process, FreeBSD Update may ask the user to help by merging > some configuration files or by confirming that the automatically > performed merging was done correctly. > > # freebsd-update install > > The system must be rebooted with the newly installed kernel before > continuing. > > # shutdown -r now > > After rebooting, freebsd-update needs to be run again to install the new > userland components, and the system needs to be rebooted again: > > # freebsd-update install > # shutdown -r now > > Users of earlier FreeBSD releases (FreeBSD 6.x) can also use > freebsd-update to upgrade to FreeBSD 7.3-RC1, but will be prompted to > rebuild all third-party applications (e.g., anything installed from the > ports tree) after the second invocation of "freebsd-update install", in > order to handle differences in the system libraries between FreeBSD 6.x > and FreeBSD 7.x. > > Checksums: > > MD5 (FreeBSD-7.3-RC1-amd64-bootonly.iso) =3D 9203d41e40bfaa916a493e0ec7de= 7b43 > MD5 (FreeBSD-7.3-RC1-amd64-disc1.iso) =3D e6601834cb700e4c250439ada6e5568= 4 > MD5 (FreeBSD-7.3-RC1-amd64-disc2.iso) =3D 4e8b9f30078b0bee18b8cded3b9889b= 4 > MD5 (FreeBSD-7.3-RC1-amd64-disc3.iso) =3D 045cb0e6fb365d3542fe1ff22bdb386= b > MD5 (FreeBSD-7.3-RC1-amd64-docs.iso) =3D 6f84de26ee4141c84dfbc3e75937553f > MD5 (FreeBSD-7.3-RC1-amd64-dvd1.iso) =3D 3db866ef9b922a2ee4fa05860370f66f > MD5 (FreeBSD-7.3-RC1-amd64-livefs.iso) =3D 0bd317eaacb4b410c6a9b505570cdc= f2 > > MD5 (FreeBSD-7.3-RC1-i386-bootonly.iso) =3D 72e07086fd7d772dab19b3c371582= 28e > MD5 (FreeBSD-7.3-RC1-i386-disc1.iso) =3D 94beb0afaa3f7b90403842b32d23e5f8 > MD5 (FreeBSD-7.3-RC1-i386-disc2.iso) =3D 2972b3033fb5f49c46e5896ce59c0de6 > MD5 (FreeBSD-7.3-RC1-i386-disc3.iso) =3D 129eb39afdb5ed80b08cc425cdd838af > MD5 (FreeBSD-7.3-RC1-i386-docs.iso) =3D d754c44cee26f1d386db9550d3839c0e > MD5 (FreeBSD-7.3-RC1-i386-dvd1.iso) =3D 53553d8b3197f2146e1e135e3779ab39 > MD5 (FreeBSD-7.3-RC1-i386-livefs.iso) =3D 72bfb8309379e2f2b0cb00fa82aa432= 9 > > MD5 (FreeBSD-7.3-RC1-pc98-bootonly.iso) =3D ef34e0b903a16212c40d3a28c124b= f1e > MD5 (FreeBSD-7.3-RC1-pc98-disc1.iso) =3D f6df8cf617a96d4fbcc6732cbd92de27 > MD5 (FreeBSD-7.3-RC1-pc98-livefs.iso) =3D 72816364465e561074d6260e862c40e= e > > MD5 (FreeBSD-7.3-RC1-sparc64-bootonly.iso) =3D fa2d3a04b3524c0a6441b27ab3= e9c260 > MD5 (FreeBSD-7.3-RC1-sparc64-disc1.iso) =3D 8b7c20c4de27bd6f8dcdcacc9c308= 6fd > MD5 (FreeBSD-7.3-RC1-sparc64-disc2.iso) =3D 856250a506426adea48a2d8c36eaa= f60 > MD5 (FreeBSD-7.3-RC1-sparc64-disc3.iso) =3D 9e91eba398769bb3b8bf88b3a45a7= e9f > MD5 (FreeBSD-7.3-RC1-sparc64-docs.iso) =3D 392698fa73e325a49ca8a350bca7e1= 5c > > SHA256 (FreeBSD-7.3-RC1-amd64-bootonly.iso) =3D 244a7b3a14cdd03b69038d192= 36929085b76867b238ecaab0bdeda21be98e6f8 > SHA256 (FreeBSD-7.3-RC1-amd64-disc1.iso) =3D 55b62c9926c4b15561d9fb8b4dae= 74ce051f0389e00fbf08d888f41491288bc1 > SHA256 (FreeBSD-7.3-RC1-amd64-disc2.iso) =3D 3f8d314d917ace574c98957cb99e= 6094d6b3ee43e15a27786fe305afcb61c267 > SHA256 (FreeBSD-7.3-RC1-amd64-disc3.iso) =3D 349c0da03bf42c399da2e8235dbd= f8877dfc5ca601b38110c1decd88b8322239 > SHA256 (FreeBSD-7.3-RC1-amd64-docs.iso) =3D 901bb101d7c428f10065b2b78a2a2= 7670c36d832afb4e96f239f3ff1b5f3603a > SHA256 (FreeBSD-7.3-RC1-amd64-dvd1.iso) =3D 6ebfba0e66d3a23077c74407bb6d1= bdff7f45d690aae7f1c08753c7a41ee5125 > SHA256 (FreeBSD-7.3-RC1-amd64-livefs.iso) =3D 88b2c22f37ed5a80eb2600aaa85= d347af534a18ff41450462bd8174c06f033b2 > > SHA256 (FreeBSD-7.3-RC1-i386-bootonly.iso) =3D dd7a06c197c62f10b85b9fd9ba= d209b677d9c0a497bb84b9f5276ee088e55b1d > SHA256 (FreeBSD-7.3-RC1-i386-disc1.iso) =3D 226153815575aa4e43e3772f1abdf= c69084a825e4f269fbe953ffafb5be2112d > SHA256 (FreeBSD-7.3-RC1-i386-disc2.iso) =3D 976172cf5c4c67c589c6f8234ab96= 16210509c34ab485e1384a7a589a6459d6a > SHA256 (FreeBSD-7.3-RC1-i386-disc3.iso) =3D ddeaed4ef86d3c69d7096b6a363ca= 43226e0c923881e1a70846e87ce8f20782f > SHA256 (FreeBSD-7.3-RC1-i386-docs.iso) =3D 4adcb739cf5d0ed54ac564129d3d97= 2ff76439cba8e8027f80ea7242d5272bcb > SHA256 (FreeBSD-7.3-RC1-i386-dvd1.iso) =3D f7f5663b1b2b7716edd96517c3f511= ea7ec1605f46c453d58b0f31c6ab7df5be > SHA256 (FreeBSD-7.3-RC1-i386-livefs.iso) =3D 42e28e767afe8ff8b51199a88914= 1637576d939d3adf4566b07bb7360b7e98b2 > > SHA256 (FreeBSD-7.3-RC1-pc98-bootonly.iso) =3D 83f7e822e7e18794ff3a5b6f8b= 041c9dd3eb7d54a9b7b49803ceb49fee3c0113 > SHA256 (FreeBSD-7.3-RC1-pc98-disc1.iso) =3D e9f0072b4f4f0053a1967fdc0b045= 6d156abc1df17481eac6083c1527331912e > SHA256 (FreeBSD-7.3-RC1-pc98-livefs.iso) =3D f93258ea2f25fe84c9a69014ef66= 778585e1d34a18167d99bf7f59147544af2f > > SHA256 (FreeBSD-7.3-RC1-sparc64-bootonly.iso) =3D ef40738bc1f02d4d93a9846= 560fd553de52b8cd350eec0ba9377d3cf23ed2319 > SHA256 (FreeBSD-7.3-RC1-sparc64-disc1.iso) =3D d922a754de7c826679281887ea= dd78fb520cc428fea6bc8f0c14178b01ab559d > SHA256 (FreeBSD-7.3-RC1-sparc64-disc2.iso) =3D 5e99fc0d9324c5acfed3498b11= 1b081f9b11a035457822fb1fee187a71abc74c > SHA256 (FreeBSD-7.3-RC1-sparc64-disc3.iso) =3D 5e78718de7898753d2701f7ff2= 7ea09d44544a0cfa4a7aba3bbaa855c22b0636 > SHA256 (FreeBSD-7.3-RC1-sparc64-docs.iso) =3D 048e045a418ebea6cbe2a27c36f= 8d9e56de19c107a6ffc8d776bf3c4207eb6ae > > -- > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Ken Smith > - From there to here, from here to =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 kensmith@buffalo.edu > =C2=A0there, funny things are everywhere. =C2=A0 | > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- Theodore Geisel | > > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 13:06:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A03E41065670 for ; Wed, 17 Feb 2010 13:06:51 +0000 (UTC) (envelope-from h.skuhra@gmail.com) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by mx1.freebsd.org (Postfix) with ESMTP id 336E68FC1E for ; Wed, 17 Feb 2010 13:06:50 +0000 (UTC) Received: by bwz23 with SMTP id 23so1922664bwz.13 for ; Wed, 17 Feb 2010 05:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=D8CPYSMiFTM/Y6ZXIWJsDLqKryO9VHrDK6BaWWMGDV8=; b=v+EN46MT4nSTinGxPXubVtTR+4KTE0gSXlX4UV3voWD767quFAhNrUK9raBJCrVYIg skiQPtDJn1RJ63f39A6YjGv6ocJZC7v9gHeTQaoAEkMNgfSDQ6Hbf8POkOjBZPa+Z9XE 2N6edVYk+KJjhFRvPIUwbRR8eWrphVvAJDfCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=KRQfcYTMlRZH6aRwn5HFVkEk8JfWhRzeh1DL/bt90RHQpnK/jFTwCt5jZ+SZso4wFn qayzZHAavRljQXcG1TrVHgPjBJuWiDU5eH/nKWwvcBoUeNT/hqBs9Rt/ExwgmE9TIbEK eXic2HCw3GPhjZufrbYszqzjfqrqac9eLGwcE= MIME-Version: 1.0 Received: by 10.204.5.217 with SMTP id 25mr5339415bkw.114.1266412009894; Wed, 17 Feb 2010 05:06:49 -0800 (PST) In-Reply-To: References: <1266251479.6979.28.camel@bauer.cse.buffalo.edu> Date: Wed, 17 Feb 2010 14:06:49 +0100 Message-ID: From: "Herbert J. Skuhra" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: 7.3-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 13:06:51 -0000 Hi, OK, I could resolve the problem by running "freebsd rollback" a few times until I was at FreeBSD 7.2-RELEASE again and removing /var/db/freebsd-update afterwards. Sorry for the full quote. :-( -Herbert From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 16:03:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 159C2106566C for ; Wed, 17 Feb 2010 16:03:59 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 964A88FC0C for ; Wed, 17 Feb 2010 16:03:58 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1HG3uEf012436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Feb 2010 17:03:57 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7C1365.9070806@omnilan.de> Date: Wed, 17 Feb 2010 17:03:49 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA4D8CCF8A03C431C0F3FD4CA" Subject: best practice to watch TCP parms of established sockets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 16:03:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA4D8CCF8A03C431C0F3FD4CA Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, while doing some ZFS tests with RELENG_8 I recognized a mysterious=20 performace drop after an hour uptime. Now my first idea is to compare MSS and windows sizes before and after=20 the performance drop. How do I best capture them? tdpcump? It's GbE linkspeed... Or is netstat capable to show these values? Or is there any way to read=20 out the values stored in tcp.hostcache? Thanks, -Harry --------------enigA4D8CCF8A03C431C0F3FD4CA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt8E2wACgkQLDqVQ9VXb8jxRQCfQGmiM2RjL+9tOVzVC0zcFh+Z eFQAoNJQ2I02+aJa+ZD4Xl5rxqESBFTC =JyA8 -----END PGP SIGNATURE----- --------------enigA4D8CCF8A03C431C0F3FD4CA-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 18:49:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA578106568D for ; Wed, 17 Feb 2010 18:49:29 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 65F9B8FC2E for ; Wed, 17 Feb 2010 18:49:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY000BS41MGOPB0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 19:49:28 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY000J321MGBJL0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 19:49:28 +0100 (CET) Date: Wed, 17 Feb 2010 19:49:27 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 18:49:29 -0000 On Fri, 12 Feb 2010 17:44:52 +0100 Torfinn Ingolfsen wrote: > On Fri, 12 Feb 2010 05:11:17 -0800 > Jeremy Chadwick wrote: > > > Please try doing this: > > > > - stop ntpd > > - rm /var/db/ntpd.drift > > - sysctl kern.timecounter.hardware=ACPI-safe > > - start ntpd > > Thanks, I'm currently testing that. Results in 72 hours (or less) :-) Well, using ACPI-safe only get a small improvement, here are the lines from /var/log/messages: Feb 17 17:16:47 kg-f2 ntpd[912]: time reset +1.785920 s Feb 17 17:32:39 kg-f2 ntpd[912]: time reset +1.836376 s Feb 17 17:48:18 kg-f2 ntpd[912]: time reset +1.811593 s Feb 17 18:04:12 kg-f2 ntpd[912]: time reset +1.840545 s Feb 17 18:19:19 kg-f2 ntpd[912]: time reset +1.751837 s Feb 17 18:35:19 kg-f2 ntpd[912]: time reset +1.852328 s Feb 17 18:51:18 kg-f2 ntpd[912]: time reset +1.850928 s Feb 17 19:06:50 kg-f2 ntpd[912]: time reset +1.798706 s Feb 17 19:22:35 kg-f2 ntpd[912]: time reset +1.823697 s Feb 17 19:37:56 kg-f2 ntpd[912]: time reset +1.777376 s Unfortunately, it isn't enough to keep the machine in sync all the time. But it is better than HPET so I'll keep it. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 18:56:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00347106568F for ; Wed, 17 Feb 2010 18:56:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id DF8BD8FC13 for ; Wed, 17 Feb 2010 18:56:43 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KY000E681XFFO30@asmtp024.mac.com> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 10:56:33 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002170089 From: Chuck Swiger In-reply-to: <4B7C1365.9070806@omnilan.de> Date: Wed, 17 Feb 2010 10:56:03 -0800 Message-id: <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> References: <4B7C1365.9070806@omnilan.de> To: Harald Schmalzbauer X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: best practice to watch TCP parms of established sockets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 18:56:44 -0000 Hi-- On Feb 17, 2010, at 8:03 AM, Harald Schmalzbauer wrote: > while doing some ZFS tests with RELENG_8 I recognized a mysterious performace drop after an hour uptime. > Now my first idea is to compare MSS and windows sizes before and after the performance drop. > How do I best capture them? tdpcump? It's GbE linkspeed... It seems more likely that ZFS is running into slowdowns from resource contention, memory fragmentation, etc than your network would suddenly drop out, but tcpdump -w outfile.pcap is a good method of looking.... Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 19:03:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DEF1065693 for ; Wed, 17 Feb 2010 19:03:31 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 1CAE38FC13 for ; Wed, 17 Feb 2010 19:03:30 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY000B9S29POPE0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 20:03:25 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY000KZU29MJ7L0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 17 Feb 2010 20:03:25 +0100 (CET) Date: Wed, 17 Feb 2010 20:03:22 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 19:03:31 -0000 On Wed, 17 Feb 2010 19:49:27 +0100 Torfinn Ingolfsen wrote: > Unfortunately, it isn't enough to keep the machine in sync all the time. > But it is better than HPET so I'll keep it. This thread is interesting: http://lkml.indiana.edu/hypermail/linux/kernel/0903.1/01356.html Is there a way in FreeBSD to perform adjustmenst like adjtimex? 'apropos adjtime' only gives me a system call, the man pages for hz(9) and hardclock(9) doesn't exist on 8.0-stable (or on 7.2-stable). -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 19:16:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53FB8106566B for ; Wed, 17 Feb 2010 19:16:03 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id B243C8FC13 for ; Wed, 17 Feb 2010 19:16:02 +0000 (UTC) Received: from [172.21.1.29] (akima-win.flintsbach.schmalzbauer.de [172.21.1.29]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1HJFvrM015735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Feb 2010 20:16:01 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnilan.net: Host akima-win.flintsbach.schmalzbauer.de [172.21.1.29] claimed to be [172.21.1.29] Message-ID: <4B7C4066.5040006@omnilan.de> Date: Wed, 17 Feb 2010 20:15:50 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: Chuck Swiger References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> In-Reply-To: <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> X-Enigmail-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC69D5F768CE3065A98DEFFF4" Cc: freebsd-stable@freebsd.org Subject: Re: best practice to watch TCP parms of established sockets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 19:16:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC69D5F768CE3065A98DEFFF4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 17.02.2010 19:56, schrieb Chuck Swiger: > Hi-- >=20 > On Feb 17, 2010, at 8:03 AM, Harald Schmalzbauer wrote: >> while doing some ZFS tests with RELENG_8 I recognized a mysterious per= formace drop after an hour uptime. >> Now my first idea is to compare MSS and windows sizes before and after= the performance drop. >> How do I best capture them? tdpcump? It's GbE linkspeed... >=20 > It seems more likely that ZFS is running into slowdowns from resource c= ontention, memory fragmentation, etc than your network would suddenly dro= p out, but tcpdump -w outfile.pcap is a good method of looking.... Thanks, but fisrt tests showed that ZFS is not causing the slowdown. I noticed that disabling window scaling (rfc1323) speeds up the transfer rate by factor 1.5 (rsync transfers start at 75MB/s, settling down at 55MB/s, while rfc1323 enabled leads to half the windows size (8k) and rsync transfers start with 50MB/s and go down to 38MB/s). Now I'm going through "internet core protocols" becaus it's been a long time ago I had such a deep look into TCP/IP and I don't have all the TCP sequences and options in memory. Not falsified yet, but as soon as I open a second high data rate transfer, simultanious to the rsync, (a smb transfer of a large file for example) the shared speed will stay at that level, even if the second transfer has finbished. Meaning: I can rsync with 50MB/s. If I simultaniously transfer another file via samba, I have two 25MB/s transfers. From that moment on I can never get more that 25MB/s per transfer until I reboot the machine. Like mentioned eralier, I first have to refresh some networking basics, but expect some more results soon. Thanks, -Harry --------------enigC69D5F768CE3065A98DEFFF4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt8QG8ACgkQLDqVQ9VXb8izsgCgjIP9AQ8y50fxYNFaYsIUfPmA v+IAoJ3UCyzamZ0JR5kDBdbNtYBX/kDq =id9Q -----END PGP SIGNATURE----- --------------enigC69D5F768CE3065A98DEFFF4-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 19:22:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57DEC1065672 for ; Wed, 17 Feb 2010 19:22:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9AC8FC0C for ; Wed, 17 Feb 2010 19:22:54 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta13.emeryville.ca.mail.comcast.net with comcast id j3Ed1d0090b6N64AD7NvKS; Wed, 17 Feb 2010 19:22:55 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta03.emeryville.ca.mail.comcast.net with comcast id j7Nu1d00E3S48mS8P7Nv9A; Wed, 17 Feb 2010 19:22:55 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C45B51E301A; Wed, 17 Feb 2010 11:22:53 -0800 (PST) Date: Wed, 17 Feb 2010 11:22:53 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100217192253.GA31689@icarus.home.lan> References: <20100217021136.GA10628@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 19:22:55 -0000 On Tue, Feb 16, 2010 at 11:43:30PM -0500, Charles Sprickman wrote: > >Footnote: This is why I tell folks to zero out the first 8192 bytes of > >any disk they've previously installed FreeBSD on (even if the disk has > >no filesystems/slices on it). The way FreeBSD determines the size of > >the disk differs in RELENG_8; I believe GEOM "figures it out" on its own > >now, while previous releases relied on the "c" slice. The method I've > >recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16. > > Is it also advisable to blot out any old glabel stuff at the end of > the disk? What's the math to get that? Get a sector count for the > whole disk, set "bs" to 512 and "skip" to (sector count - 1)? I don't think the glabel data (which goes at the end of the disk) is relevant to the above problem I described. You can erase it if you want, but I doubt it's responsible for warnings like "Disk geometry does not match label!" or situations where a user is re-using a disk (that had its slices created on RELENG_7) on RELENG_8 and experiences problems. An alternative to the dd method might be to try "gpart destroy"; I haven't tried to see if relieves the problem. As far as how to erase the glabel metadata -- "glabel clear" is supposed to do this for you. What I don't know is whether or not addition of a glabel decreases what GEOM thinks the total size of the disk is, so I can't say for certain doing some math + zeroing the last sector of the disk would actually work. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 20:30:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B791065697 for ; Wed, 17 Feb 2010 20:30:33 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3769B8FC29 for ; Wed, 17 Feb 2010 20:30:32 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id EB4143984A; Wed, 17 Feb 2010 22:30:29 +0200 (SAST) Date: Wed, 17 Feb 2010 22:30:29 +0200 From: John Hay To: Torfinn Ingolfsen Message-ID: <20100217203029.GA70542@zibbi.meraka.csir.co.za> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 20:30:33 -0000 On Wed, Feb 17, 2010 at 08:03:22PM +0100, Torfinn Ingolfsen wrote: > On Wed, 17 Feb 2010 19:49:27 +0100 > Torfinn Ingolfsen wrote: > > > Unfortunately, it isn't enough to keep the machine in sync all the time. > > But it is better than HPET so I'll keep it. > > This thread is interesting: > http://lkml.indiana.edu/hypermail/linux/kernel/0903.1/01356.html > > Is there a way in FreeBSD to perform adjustmenst like adjtimex? > 'apropos adjtime' only gives me a system call, > the man pages for hz(9) and hardclock(9) doesn't exist on 8.0-stable > (or on 7.2-stable). You can set the timecounter frequency with sysctl. On my one time server I have these lines in /etc/sysctl.conf machdep.tsc_freq=132658584 kern.timecounter.hardware=TSC John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 22:35:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 747731065676; Wed, 17 Feb 2010 22:35:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 458BD8FC08; Wed, 17 Feb 2010 22:35:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EAD7346B0C; Wed, 17 Feb 2010 17:35:27 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2AEF38A021; Wed, 17 Feb 2010 17:35:27 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 17 Feb 2010 16:41:40 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B79459E.2090207@FreeBSD.org> <000901caae46$84d73300$8e859900$@org> In-Reply-To: <000901caae46$84d73300$8e859900$@org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002171641.40779.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 17 Feb 2010 17:35:27 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: 'Alexander Motin' , 'Jeremy Chadwick' Subject: Re: kernel compile failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 22:35:28 -0000 On Monday 15 February 2010 8:55:13 am Larry Rosenman wrote: > For the record, it appears that cvsup17.us.freebsd.org is serving outdated > files. Try sending an e-mail to hubs@. The last time cvsup17 had issues the owner fixed them after seeing an e-mail to hubs@. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 22:38:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F18710656AA; Wed, 17 Feb 2010 22:38:12 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 41D528FC24; Wed, 17 Feb 2010 22:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=Jme5gLr8sJsti2o543HVUEPzcq3oF70+INyvElho3bY=; b=S9KIJIyq7MMIwiaVqxZn0RWjUzIXxxmqjsawYs+wDeRuZ+Qw9IQMI04CIUxBngUeE5EeVP4Xg9y7B5e3PEBwk5QsdXBWGft9IvFfsc12SrRKkbyr3CTE5N04gW4Z6wY6FytSE2sLp0dFY1wn7vmiLOIzhFeIBGXQYn3guGkwqLw=; Received: from 64.3.1.253.ptr.us.xo.net ([64.3.1.253]:52859 helo=LROSENMAN) by thebighonker.lerctr.org with esmtpa (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NhsX4-000Muh-H7; Wed, 17 Feb 2010 16:38:11 -0600 From: "Larry Rosenman" To: "'John Baldwin'" , References: <4B79459E.2090207@FreeBSD.org> <000901caae46$84d73300$8e859900$@org> <201002171641.40779.jhb@freebsd.org> In-Reply-To: <201002171641.40779.jhb@freebsd.org> Date: Wed, 17 Feb 2010 16:38:00 -0600 Message-ID: <012201cab021$e1fc0600$a5f41200$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqwIYG0wigMJjUyRdCO+A1phfuVXQAAEzwg Content-Language: en-us X-Spam-Score: -2.2 (--) X-LERCTR-Spam-Score: -2.2 (--) X-Spam-Report: SpamScore (-2.2/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.695 X-LERCTR-Spam-Report: SpamScore (-2.2/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.695 Cc: 'Alexander Motin' , 'Jeremy Chadwick' Subject: RE: kernel compile failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 22:38:12 -0000 Already done on Monday at 08:12am US/Central (GMT-6). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----Original Message----- From: John Baldwin [mailto:jhb@freebsd.org] Sent: Wednesday, February 17, 2010 3:42 PM To: freebsd-stable@freebsd.org Cc: Larry Rosenman; 'Alexander Motin'; 'Jeremy Chadwick' Subject: Re: kernel compile failure On Monday 15 February 2010 8:55:13 am Larry Rosenman wrote: > For the record, it appears that cvsup17.us.freebsd.org is serving outdated > files. Try sending an e-mail to hubs@. The last time cvsup17 had issues the owner fixed them after seeing an e-mail to hubs@. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 04:41:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 570D6106566B for ; Thu, 18 Feb 2010 04:41:20 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 389DB8FC1F for ; Thu, 18 Feb 2010 04:41:19 +0000 (UTC) Received: by pzk40 with SMTP id 40so5424031pzk.7 for ; Wed, 17 Feb 2010 20:41:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.101.7 with SMTP id d7mr5700023rvm.78.1266466659541; Wed, 17 Feb 2010 20:17:39 -0800 (PST) In-Reply-To: <20100217192253.GA31689@icarus.home.lan> References: <20100217021136.GA10628@icarus.home.lan> <20100217192253.GA31689@icarus.home.lan> Date: Thu, 18 Feb 2010 15:17:39 +1100 Message-ID: From: Antony Mawer To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: netboot issues, 8.0, mfsroot mount failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 04:41:20 -0000 On Thu, Feb 18, 2010 at 6:22 AM, Jeremy Chadwick wrote: > On Tue, Feb 16, 2010 at 11:43:30PM -0500, Charles Sprickman wrote: >> >Footnote: This is why I tell folks to zero out the first 8192 bytes of >> >any disk they've previously installed FreeBSD on (even if the disk has >> >no filesystems/slices on it). =A0The way FreeBSD determines the size of >> >the disk differs in RELENG_8; I believe GEOM "figures it out" on its ow= n >> >now, while previous releases relied on the "c" slice. =A0The method I'v= e >> >recommended: do dd if=3D/dev/zero of=3D/dev/adX bs=3D512 count=3D16. >> >> Is it also advisable to blot out any old glabel stuff at the end of >> the disk? =A0What's the math to get that? =A0Get a sector count for the >> whole disk, set "bs" to 512 and "skip" to (sector count - 1)? > > I don't think the glabel data (which goes at the end of the disk) is > relevant to the above problem I described. =A0You can erase it if you > want, but I doubt it's responsible for warnings like "Disk geometry does > not match label!" or situations where a user is re-using a disk (that > had its slices created on RELENG_7) on RELENG_8 and experiences > problems. =A0An alternative to the dd method might be to try "gpart > destroy"; I haven't tried to see if relieves the problem. > > As far as how to erase the glabel metadata -- "glabel clear" is supposed > to do this for you. =A0What I don't know is whether or not addition of a > glabel decreases what GEOM thinks the total size of the disk is, so I > can't say for certain doing some math + zeroing the last sector of the > disk would actually work. I have recently been using the following snippet in an install script to zero out any existing gmirror/etc metadata before the install proceeds (and potentially reconfigures a new gmirror etc): # Specify the disk device to clear diskdev=3D"da0" # Clear metadata from the last sector on the drive echo "Clearing any GEOM metadata on drive..." diskinfo=3D`diskinfo /dev/$diskdev` sector_size=3D`echo $diskinfo | cut -f2 -d\ ` size_in_sectors=3D`echo $diskinfo | cut -f4 -d\ ` geom_offset=3D$(($size_in_sectors-1)) dd if=3D/dev/zero of=3D/dev/$diskdev bs=3D$sector_size oseek=3D$geom_offset count=3D1 2> /dev/null In preliminary testing it seems to do the job... -- Antony From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 09:11:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85381065670 for ; Thu, 18 Feb 2010 09:11:06 +0000 (UTC) (envelope-from 143500@gmail.com) Received: from mail-fx0-f219.google.com (mail-fx0-f219.google.com [209.85.220.219]) by mx1.freebsd.org (Postfix) with ESMTP id 699C88FC17 for ; Thu, 18 Feb 2010 09:11:06 +0000 (UTC) Received: by fxm19 with SMTP id 19so1206367fxm.3 for ; Thu, 18 Feb 2010 01:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=Lz2GkLjjApTBmIPhDYBpHdK9gGqvE6Ut2K69CujWYp8=; b=J5xkQyCv9dknPOAJgb34beTaZCi+NJbg3Ppn/fIXj8W9+6Rg+zCI7CyCTF4GwLi8i0 yB3dyWhbtyyyf+UdOExIIB6SzmwiPHyRGA8khGc3dfpRp3NzhRRE7IuLh4jKg51o9n9y zfXhRXYKH6YqO58EIC6jPwPRJra2LBsQloK60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=ImqKsRlk9H3SowbY+CTtMOcHNY74F5Vo6+o0OtR+PghmuqQX3QnAXqAn4JA+d9NEVr 8Ak19zMVWx12Y12htL8cSqiCB1wOBdVv8OBh+lTislOlhju952DuqIMHFY34vtvADZq/ +SwyzAgGOZ/wIuHXvU1AOBxqbKEsn2srJC+vI= MIME-Version: 1.0 Sender: 143500@gmail.com Received: by 10.223.6.88 with SMTP id 24mr8418508fay.2.1266484264994; Thu, 18 Feb 2010 01:11:04 -0800 (PST) In-Reply-To: References: From: Ivan Kudryashov Date: Thu, 18 Feb 2010 12:10:44 +0300 X-Google-Sender-Auth: 9ccd06e8f93fce11 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Fwd: Transport Problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 09:11:07 -0000 Hi All! Use freeBSD 8.0 + pf as a gateway to the network. The network is divided into segments 192.168.1.h, 192.168.2.h etc. Gateway raised aliases. ifconfig_net0_alias0 = "inet 192.168.1.1 netmask 255.255.255.0" ifconfig_net0_alias1 = "inet 192.168.2.1 netmask 255.255.255.0", etc. There is a server, such as 192.168.1.200 (WINDOWS). I went at it from the network 192.168.2.h. Traffic went through the gateway, of course. I went to \ \ 192.168.1.200. When starting to shake with 1,200 large files - Connect falls off. What can I do? -------------------- Server for some reason stubbornly refuses to work on this scheme at the physical connection to 1 network card. Once the server with Windows physically delivered to another network interface - all at once to work This be corrected? -- http://kudr.net -- http://kudr.net From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 10:06:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B089D1065672 for ; Thu, 18 Feb 2010 10:06:37 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABF48FC16 for ; Thu, 18 Feb 2010 10:06:37 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ni3H7-000GJt-Kg for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 10:06:25 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ni3H7-000OTz-Jt for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 10:06:25 +0000 Date: Thu, 18 Feb 2010 10:06:25 +0000 Message-Id: To: freebsd-stable@freebsd.org From: Pete French Subject: Odd rsync warnings out of latest 8-STABLE & ZFS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 10:06:37 -0000 Having just updated a couple of machines to the latest stable, I am seeing warnings like this out of rsync when writing to a ZFS filesystem on the machine: default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Invalid argument, falling back on umask ANy ideas whats going on here ? cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 12:57:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0C1B106566C for ; Thu, 18 Feb 2010 12:57:38 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4DFF48FC15 for ; Thu, 18 Feb 2010 12:57:37 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1ICvaWY036598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 13:57:36 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7D3938.1000309@omnilan.de> Date: Thu, 18 Feb 2010 13:57:28 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Chuck Swiger References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> In-Reply-To: <4B7C4066.5040006@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA4590C226364FBF460EE45E" Cc: freebsd-stable@freebsd.org Subject: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 12:57:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA4590C226364FBF460EE45E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 17.02.2010 20:15 (localtime): =2E.. >>> Now my first idea is to compare MSS and windows sizes before and afte= r the performance drop. >>> How do I best capture them? tdpcump? It's GbE linkspeed... >> It seems more likely that ZFS is running into slowdowns from resource = contention, memory fragmentation, etc than your network would suddenly dr= op out, but tcpdump -w outfile.pcap is a good method of looking.... >=20 > Thanks, but fisrt tests showed that ZFS is not causing the slowdown. Hello, I got exactly the same limitations when using tmpfs. So for now I'll=20 concentrate on that, back to ZFS later. Please clarify my TCP understanding. If I have the window set to 65535 in the header and a MSS of 1460, how=20 often should the receiver send ACK segments? window/MSS, right? Now I see every two segments acknowledged in my dump (rsync between two=20 em0 interaces). I'd like to understand a) why disabling net.inet.tcp.rfc1323 gives slightly better rsync=20 throughput than enabled b) why I can't transfer more than 50MB/s over my direct linked GbE boxes.= But right now I even don't understand the dump I see. As far as I=20 understand I should only see every 45 data segments one ACK segment.=20 That would clearly explain to me why I can't saturate my GbE link. But I = can't imagine this is a uncovered faulty behaviour, so I guess I haven't = understood TCP. Please help. Thanks in advance, -Harry --------------enigDA4590C226364FBF460EE45E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt9OUAACgkQLDqVQ9VXb8hkMgCgj1MefInItFaZNUR0MYGKy0yh MesAoIFExZul/0EiKCDnIIf60SMC+xVW =yH9D -----END PGP SIGNATURE----- --------------enigDA4590C226364FBF460EE45E-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 15:14:42 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50145106568F for ; Thu, 18 Feb 2010 15:14:42 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 69AE08FC1D for ; Thu, 18 Feb 2010 15:14:41 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ni7WI-0002MK-4S; Thu, 18 Feb 2010 17:38:22 +0300 Date: Thu, 18 Feb 2010 17:38:22 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100218143822.GA8380@zxy.spb.ru> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100216175719.GB1394@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 15:14:42 -0000 On Tue, Feb 16, 2010 at 09:57:19AM -0800, Pyun YongHyeon wrote: > On Sun, Feb 14, 2010 at 10:04:58AM -0800, Nick Rogers wrote: > > I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone > > shed light on the below error? I unfortunately cannot provide a proper crash > > dump. The pointer addresses are always the same. The only other thing I've > > noticed that may be related is a watchdog timeout on bge0 error before the > > panic. Thanks. > > > > Any chance to get backtrace from the crash? I got same trouble on the same platform (8.0-STABLE/amd64). hw.bge.allow_asf=0 already I got 2 proper crash dump (first w/ net.inet.ip.forwarding=1 and second w/ net.inet.ip.forwarding=0). backtrace from the first crash: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff802ea751 stack pointer = 0x28:0xffffff80000ef930 frame pointer = 0x28:0xffffff80000ef970 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq26: bge1) panic: from debugger cpuid = 0 Uptime: 5h23m50s Physical memory: 2039 MB Dumping 1316 MB: 1301 1285 1269 1253 1237 1221 1205 1189 1173 1157 1141 1125 1109 1093 1077 1061 1045 1029 1013 997 981 965 949 933 917 901 885 869 853 837 821 805 789 773 757 741 725 709 693 677 661 645 629 613 597 581 565 549 533 517 501 485 469 453 437 421 405 389 373 357 341 325 309 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 Reading symbols from /boot/kernel/if_bge.ko...Reading symbols from /boot/kernel/if_bge.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_bge.ko Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /boot/kernel/miibus.ko.symbols...done. done. Loaded symbols for /boot/kernel/miibus.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/nfsserver.ko...Reading symbols from /boot/kernel/nfsserver.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfsserver.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kernel/krpc.ko.symbols...done. done. Loaded symbols for /boot/kernel/krpc.ko Reading symbols from /boot/kernel/nfssvc.ko...Reading symbols from /boot/kernel/nfssvc.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfssvc.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff802909b9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff80290e0c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff801a5bc7 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801a5fd1 in db_command (last_cmdp=0xffffffff806b1fa0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801a6220 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801a81e9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff802c0995 in kdb_trap (type=12, code=0, tf=0xffffff80000ef880) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xffffffff8049ee0d in trap_fatal (frame=0xffffff80000ef880, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #9 0xffffffff8049f1e4 in trap_pfault (frame=0xffffff80000ef880, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773 #10 0xffffffff8049fa6a in trap (frame=0xffffff80000ef880) at /usr/src/sys/amd64/amd64/trap.c:499 #11 0xffffffff80484ff3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #12 0xffffffff802ea751 in m_copydata (m=0x0, off=0, len=108, cp=0xffffff0027865194 "Â\026zHqJ÷\220ãðùóPo~@<22>Feb 17 15:10:2") at /usr/src/sys/kern/uipc_mbuf.c:816 #13 0xffffffff8035e72d in ip_forward (m=0xffffff0001530900, srcrt=Variable "srcrt" is not available. ) at /usr/src/sys/netinet/ip_input.c:1444 #14 0xffffffff8035fef7 in ip_input (m=0xffffff0001530900) at /usr/src/sys/netinet/ip_input.c:717 #15 0xffffffff80342e9e in netisr_dispatch_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:917 #16 0xffffffff8033fd5d in ether_demux (ifp=0xffffff0001412800, m=0xffffff0001530900) at /usr/src/sys/net/if_ethersubr.c:895 #17 0xffffffff80340127 in ether_input (ifp=0xffffff0001412800, m=0xffffff0001530900) at /usr/src/sys/net/if_ethersubr.c:754 #18 0xffffffff80838257 in bge_rxeof (sc=0xffffff800023b000, rx_prod=773, holdlck=1) at /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3392 #19 0xffffffff8083a058 in bge_intr (xsc=Variable "xsc" is not available. ) at /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3657 #20 0xffffffff8026964d in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1220 #21 0xffffffff8026acfe in ithread_loop (arg=0xffffff0001430740) at /usr/src/sys/kern/kern_intr.c:1233 #22 0xffffffff80267088 in fork_exit (callout=0xffffffff8026ac70 , arg=0xffffff0001430740, frame=0xffffff80000efc80) at /usr/src/sys/kern/kern_fork.c:843 #23 0xffffffff804854ce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000001 in ?? () backtrace from the second crash (ipforwardinf disabled): GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff802eb3b7 stack pointer = 0x28:0xffffff80001c66e0 frame pointer = 0x28:0xffffff80001c6740 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 732 (named) panic: from debugger cpuid = 0 Uptime: 8h28m38s Physical memory: 2039 MB Dumping 1425 MB: 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/kernel/if_bge.ko...Reading symbols from /boot/kernel/if_bge.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_bge.ko Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /boot/kernel/miibus.ko.symbols...done. done. Loaded symbols for /boot/kernel/miibus.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/nfsserver.ko...Reading symbols from /boot/kernel/nfsserver.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfsserver.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kernel/krpc.ko.symbols...done. done. Loaded symbols for /boot/kernel/krpc.ko Reading symbols from /boot/kernel/nfssvc.ko...Reading symbols from /boot/kernel/nfssvc.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfssvc.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff802909b9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff80290e0c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff801a5bc7 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801a5fd1 in db_command (last_cmdp=0xffffffff806b1fa0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801a6220 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801a81e9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff802c0995 in kdb_trap (type=12, code=0, tf=0xffffff80001c6630) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xffffffff8049ee0d in trap_fatal (frame=0xffffff80001c6630, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #9 0xffffffff8049f1e4 in trap_pfault (frame=0xffffff80001c6630, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773 #10 0xffffffff8049fa6a in trap (frame=0xffffff80001c6630) at /usr/src/sys/amd64/amd64/trap.c:499 #11 0xffffffff80484ff3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #12 0xffffffff802eb3b7 in m_copym (m=0x0, off0=1496, len=1496, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:541 #13 0xffffffff80361041 in ip_fragment (ip=0xffffff004c748830, m_frag=0xffffff80001c6848, mtu=Variable "mtu" is not available. ) at /usr/src/sys/netinet/ip_output.c:805 #14 0xffffffff8036206e in ip_output (m=0xffffff0012d4ed00, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:636 #15 0xffffffff803d8ac5 in udp_send (so=Variable "so" is not available. ) at /usr/src/sys/netinet/udp_usrreq.c:1236 #16 0xffffffff802f5a72 in sosend_dgram (so=0xffffff00018da000, addr=0xffffff00018ad120, uio=Variable "uio" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1069 #17 0xffffffff802f9b75 in kern_sendit (td=0xffffff00015fd740, s=514, mp=0xffffff80001c6af0, flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/uipc_syscalls.c:784 #18 0xffffffff802f9dbc in sendit (td=0xffffff00015fd740, s=514, mp=0xffffff80001c6af0, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:720 #19 0xffffffff802f9e47 in sendmsg (td=0xffffff00015fd740, uap=0xffffff80001c6bf0) at /usr/src/sys/kern/uipc_syscalls.c:917 #20 0xffffffff8049f3f7 in syscall (frame=0xffffff80001c6c80) at /usr/src/sys/amd64/amd64/trap.c:1025 #21 0xffffffff804852d1 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 #22 0x0000000800c82c6c in ?? () Previous frame inner to this frame (corrupt stack?) -- Slawa Olhovchenkov From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 15:26:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E646D10656C1 for ; Thu, 18 Feb 2010 15:26:09 +0000 (UTC) (envelope-from me@pollux.local.net) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA9E8FC0C for ; Thu, 18 Feb 2010 15:26:07 +0000 (UTC) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id C47A34C80DC for ; Thu, 18 Feb 2010 16:26:04 +0100 (CET) Received: from pollux.local.net (che78-3-82-246-30-233.fbx.proxad.net [82.246.30.233]) by smtp4-g21.free.fr (Postfix) with ESMTP id E4EE24C802F for ; Thu, 18 Feb 2010 16:26:01 +0100 (CET) Received: by pollux.local.net (Postfix, from userid 2000) id BA3A01CD80; Thu, 18 Feb 2010 16:26:01 +0100 (CET) Date: Thu, 18 Feb 2010 16:26:01 +0100 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20100218152601.GA3076@pollux.local.net> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Incorrect super block X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 15:26:10 -0000 Has anybody encountered the following problem ? Mac OS X does recognize FreeBSD partitions on USB disks, but doesn't want to mount them because ``Incorrect super block''. This is extremely annoying for my ``client'' because he relies on dayly backups on USB keys. Is there a solution ? Thank you in advance. -- Harald Weis From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 15:31:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30B93106568F for ; Thu, 18 Feb 2010 15:31:06 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id DB9F58FC20 for ; Thu, 18 Feb 2010 15:31:05 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o1IFO8vR073328; Thu, 18 Feb 2010 07:24:08 -0800 (PST) (envelope-from mahan@mahan.org) Message-ID: <4B7D5AC4.9020509@mahan.org> Date: Thu, 18 Feb 2010 07:20:36 -0800 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Harald Schmalzbauer References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> In-Reply-To: <4B7D3938.1000309@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 15:31:06 -0000 See inline... Harald Schmalzbauer wrote: > Harald Schmalzbauer schrieb am 17.02.2010 20:15 (localtime): > ... >>>> Now my first idea is to compare MSS and windows sizes before and >>>> after the performance drop. >>>> How do I best capture them? tdpcump? It's GbE linkspeed... >>> It seems more likely that ZFS is running into slowdowns from resource >>> contention, memory fragmentation, etc than your network would >>> suddenly drop out, but tcpdump -w outfile.pcap is a good method of >>> looking.... >> >> Thanks, but fisrt tests showed that ZFS is not causing the slowdown. > > Hello, > > I got exactly the same limitations when using tmpfs. So for now I'll > concentrate on that, back to ZFS later. > > Please clarify my TCP understanding. > If I have the window set to 65535 in the header and a MSS of 1460, how > often should the receiver send ACK segments? window/MSS, right? How soon you see the ACK is based on two values in the kernel: net.inet.tcp.delacktime net.inet.tcp.delayed_ack The first one controls how soon the peer replies with an ACK if there is no data to send back, ie. it is just a plain ack. Van Jacobson first recommended it in the early days of TCP/IP. Historically, it has been implemented as a 200 ms timer, but in FreeBSD it is a 100 ms timer. The second one controls wheter delayed acking is enabled. Setting this sysctl variable to 0 should cause you to seem more ACKs. > Now I see every two segments acknowledged in my dump (rsync between two > em0 interaces). I'm curious what an iperf between your systems shows? We have recently upgrade some of test systems from 6.2 to 8.0-Stable and are seeing almost 1/2 the bandwidth over the em(4). Other systems that have been upgraded are not seeing and drop in bandwidth. > I'd like to understand > a) why disabling net.inet.tcp.rfc1323 gives slightly better rsync > throughput than enabled rfc1323 deals with window scaling and timestamp options. Perhaps these are getting in the way? > b) why I can't transfer more than 50MB/s over my direct linked GbE boxes. > > But right now I even don't understand the dump I see. As far as I > understand I should only see every 45 data segments one ACK segment. > That would clearly explain to me why I can't saturate my GbE link. But I > can't imagine this is a uncovered faulty behaviour, so I guess I haven't > understood TCP. > No we are also seeing similar behavior over the em(4) interface under FreeBSD 8.0-Stable. Patrick > Please help. > > Thanks in advance, > > -Harry > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 15:40:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC9B31065676 for ; Thu, 18 Feb 2010 15:40:30 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 87EC98FC0A for ; Thu, 18 Feb 2010 15:40:30 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ni8UO-0001kT-Ri for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 16:40:28 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Feb 2010 16:40:28 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Feb 2010 16:40:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 18 Feb 2010 16:40:06 +0100 Lines: 9 Message-ID: References: <20100218152601.GA3076@pollux.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <20100218152601.GA3076@pollux.local.net> Sender: news Subject: Re: Incorrect super block X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 15:40:30 -0000 On 02/18/10 16:26, Harald Weis wrote: > Has anybody encountered the following problem ? > > Mac OS X does recognize FreeBSD partitions on USB disks, but doesn't > want to mount them because ``Incorrect super block''. > This is extremely annoying for my ``client'' because he relies on dayly > backups on USB keys. Is there a solution ? Are you using UFS1 or UFS2? If one, try the other :) From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 15:50:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2AE8106566B for ; Thu, 18 Feb 2010 15:50:57 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2604C8FC13 for ; Thu, 18 Feb 2010 15:50:56 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1IFotRh039188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 16:50:55 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7D61DE.2020906@omnilan.de> Date: Thu, 18 Feb 2010 16:50:54 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Patrick Mahan References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> In-Reply-To: <4B7D5AC4.9020509@mahan.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig940FE569D003DF9BA36FBBAE" Cc: freebsd-stable@freebsd.org Subject: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 15:50:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig940FE569D003DF9BA36FBBAE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Patrick Mahan schrieb am 18.02.2010 16:20 (localtime): > See inline... =2E.. >> Please clarify my TCP understanding. >> If I have the window set to 65535 in the header and a MSS of 1460, how= =20 >> often should the receiver send ACK segments? window/MSS, right? >=20 > How soon you see the ACK is based on two values in the kernel: > net.inet.tcp.delacktime > net.inet.tcp.delayed_ack >=20 > The first one controls how soon the peer replies with an ACK if there i= s > no data to send back, ie. it is just a plain ack. Van Jacobson first > recommended it in the early days of TCP/IP. Historically, it has been > implemented as a 200 ms timer, but in FreeBSD it is a 100 ms timer. Thank you for your hint. I heard of that but never thought about it,=20 because 100ms is a magnitude higher than my =B5s LAN delay and since I'm = not suffering from extremeley slow speeds. =2E.. >> a) why disabling net.inet.tcp.rfc1323 gives slightly better rsync=20 >> throughput than enabled >=20 > rfc1323 deals with window scaling and timestamp options. Perhaps these= > are getting in the way? >=20 >> b) why I can't transfer more than 50MB/s over my direct linked GbE box= es. >> >> But right now I even don't understand the dump I see. As far as I=20 >> understand I should only see every 45 data segments one ACK segment.=20 >> That would clearly explain to me why I can't saturate my GbE link. But= =20 >> I can't imagine this is a uncovered faulty behaviour, so I guess I=20 >> haven't understood TCP. >> >=20 > No we are also seeing similar behavior over the em(4) interface under > FreeBSD 8.0-Stable. Some experimental results: When rsyncing with windows, and FreeBSD is receiver, I see the same ACK=20 ever two segemnts, but speed is at 72MB/s. When FreeBSD is sender and Windows is receiver, it looks more I=20 expected. There are about 20 data segments before a ACK is returned. And = there are TCP Window Update Segments, reflecting smaller receiver=20 buffers on the windows side. But this happens at a throughput of=20 82MB/s!!! So the windows machine is behaving like I understand the TCP=20 flow control. Any explanation why the FreeBSD machine seems to ignore window size? Thanks, -Harry --------------enig940FE569D003DF9BA36FBBAE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt9Yd8ACgkQLDqVQ9VXb8iOlwCgvD6US4J6+km41ndHL0eL9NUw YqoAn22a8BMVi+VNzqBPcA59il03x3df =FBYQ -----END PGP SIGNATURE----- --------------enig940FE569D003DF9BA36FBBAE-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:01:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAC71106566C for ; Thu, 18 Feb 2010 16:01:36 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from proton.sasknet.sk.ca (proton.sasknet.sk.ca [142.165.20.178]) by mx1.freebsd.org (Postfix) with ESMTP id B0D598FC16 for ; Thu, 18 Feb 2010 16:01:35 +0000 (UTC) Received: from pps.filterd (proton [127.0.0.1]) by proton.sasknet.sk.ca (8.14.3/8.14.3) with SMTP id o1IFrHhq014578 for ; Thu, 18 Feb 2010 10:01:35 -0600 Received: from bgmpomr1.sasknet.sk.ca (bgmpOMR1.sasknet.sk.ca [142.165.72.22]) by proton.sasknet.sk.ca with ESMTP id m17srv97d-1 for ; Thu, 18 Feb 2010 10:01:35 -0600 Received: from ace.hurd.local (outgoing.bbsdev.net [76.202.204.46]) by bgmpomr1.sasknet.sk.ca (SaskTel eMessaging Service) with ESMTPA id <0KY100J4MOIMIC00@bgmpomr1.sasknet.sk.ca> for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 10:01:34 -0600 (CST) Date: Thu, 18 Feb 2010 08:01:33 -0800 From: Stephen Hurd In-reply-to: <4B7D61DE.2020906@omnilan.de> To: Harald Schmalzbauer Message-id: <4B7D645D.3090104@sasktel.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20091205 SeaMonkey/1.1.18 Mnenhy/0.7.6.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-18_10:2010-02-06, 2010-02-18, 2010-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002180108 Cc: freebsd-stable@freebsd.org, Patrick Mahan Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:01:37 -0000 Harald Schmalzbauer wrote: > Some experimental results: > When rsyncing with windows, and FreeBSD is receiver, I see the same > ACK ever two segemnts, but speed is at 72MB/s. > When FreeBSD is sender and Windows is receiver, it looks more I > expected. There are about 20 data segments before a ACK is returned. > And there are TCP Window Update Segments, reflecting smaller receiver > buffers on the windows side. But this happens at a throughput of > 82MB/s!!! So the windows machine is behaving like I understand the TCP > flow control. > Any explanation why the FreeBSD machine seems to ignore window size? IIRC, the delayed ACK RFC requires an ACK at least every second segment. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:04:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45C901065692 for ; Thu, 18 Feb 2010 16:04:38 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id A5B568FC17 for ; Thu, 18 Feb 2010 16:04:37 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1IG4aTs039419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 17:04:36 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7D6513.6020406@omnilan.de> Date: Thu, 18 Feb 2010 17:04:35 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Stephen Hurd References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> <4B7D645D.3090104@sasktel.net> In-Reply-To: <4B7D645D.3090104@sasktel.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig24FCC04F34504334AF94C7C0" Cc: freebsd-stable@freebsd.org, Patrick Mahan Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:04:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig24FCC04F34504334AF94C7C0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stephen Hurd schrieb am 18.02.2010 17:01 (localtime): > Harald Schmalzbauer wrote: >> Some experimental results: >> When rsyncing with windows, and FreeBSD is receiver, I see the same=20 >> ACK ever two segemnts, but speed is at 72MB/s. >> When FreeBSD is sender and Windows is receiver, it looks more I=20 >> expected. There are about 20 data segments before a ACK is returned.=20 >> And there are TCP Window Update Segments, reflecting smaller receiver= =20 >> buffers on the windows side. But this happens at a throughput of=20 >> 82MB/s!!! So the windows machine is behaving like I understand the TCP= =20 >> flow control. >> Any explanation why the FreeBSD machine seems to ignore window size? >=20 > IIRC, the delayed ACK RFC requires an ACK at least every second segment= =2E Good hint, but disabling leads to ACK after every single data segment ?!?= Thanks, -Harry --------------enig24FCC04F34504334AF94C7C0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt9ZRQACgkQLDqVQ9VXb8jQtwCfZnCWjfH5hQ92PMd4KgHrZtXZ lzoAnRGFYEg3iwLw7N/PonsMx3hCEXxQ =d8DW -----END PGP SIGNATURE----- --------------enig24FCC04F34504334AF94C7C0-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:09:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E06DF106566C for ; Thu, 18 Feb 2010 16:09:28 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from neutron.sasknet.sk.ca (neutron.sasknet.sk.ca [142.165.20.180]) by mx1.freebsd.org (Postfix) with ESMTP id A5C458FC2B for ; Thu, 18 Feb 2010 16:09:28 +0000 (UTC) Received: from pps.filterd (neutron [127.0.0.1]) by neutron.sasknet.sk.ca (8.14.3/8.14.3) with SMTP id o1IG8PYw029933 for ; Thu, 18 Feb 2010 10:09:28 -0600 Received: from bgmpomr2.sasknet.sk.ca (bgmpOMR2.sasknet.sk.ca [142.165.72.23]) by neutron.sasknet.sk.ca with ESMTP id m18ac25qv-1 for ; Thu, 18 Feb 2010 10:09:27 -0600 Received: from ace.hurd.local (outgoing.bbsdev.net [76.202.204.46]) by bgmpomr2.sasknet.sk.ca (SaskTel eMessaging Service) with ESMTPA id <0KY100MUIOVQMJ00@bgmpomr2.sasknet.sk.ca> for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 10:09:27 -0600 (CST) Date: Thu, 18 Feb 2010 08:09:25 -0800 From: Stephen Hurd In-reply-to: <4B7D61DE.2020906@omnilan.de> To: Harald Schmalzbauer Message-id: <4B7D6635.20605@sasktel.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20091205 SeaMonkey/1.1.18 Mnenhy/0.7.6.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-18_10:2010-02-06, 2010-02-18, 2010-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002180110 Cc: freebsd-stable@freebsd.org, Patrick Mahan Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:09:29 -0000 Harald Schmalzbauer wrote: > Some experimental results: > When rsyncing with windows, and FreeBSD is receiver, I see the same > ACK ever two segemnts, but speed is at 72MB/s. > When FreeBSD is sender and Windows is receiver, it looks more I > expected. There are about 20 data segments before a ACK is returned. > And there are TCP Window Update Segments, reflecting smaller receiver > buffers on the windows side. But this happens at a throughput of > 82MB/s!!! So the windows machine is behaving like I understand the TCP > flow control. > Any explanation why the FreeBSD machine seems to ignore window size? Yes, here we are in RFC1122: 4.2.3.2 When to Send an ACK Segment A host that is receiving a stream of TCP data segments can increase efficiency in both the Internet and the hosts by sending fewer than one ACK (acknowledgment) segment per data segment received; this is known as a "delayed ACK" [TCP:5]. A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. The idea of delayed ACKs is to allow an ACK to be sent with data if there will be data sent right away, not to combine ACKs... leaving out ACKs makes calculation of RTT problematical which causes performance problems all over the place... maybe the dearth of ACKs from the windows system is causing the problem? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:18:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7E52106566B for ; Thu, 18 Feb 2010 16:18:33 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from neutron.sasknet.sk.ca (neutron.sasknet.sk.ca [142.165.20.180]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9EB8FC0A for ; Thu, 18 Feb 2010 16:18:33 +0000 (UTC) Received: from pps.filterd (neutron [127.0.0.1]) by neutron.sasknet.sk.ca (8.14.3/8.14.3) with SMTP id o1IGINlO013539 for ; Thu, 18 Feb 2010 10:18:32 -0600 Received: from bgmpomr1.sasknet.sk.ca (bgmpOMR1.sasknet.sk.ca [142.165.72.22]) by neutron.sasknet.sk.ca with ESMTP id m18ac2hm6-1 for ; Thu, 18 Feb 2010 10:18:32 -0600 Received: from ace.hurd.local (outgoing.bbsdev.net [76.202.204.46]) by bgmpomr1.sasknet.sk.ca (SaskTel eMessaging Service) with ESMTPA id <0KY100JJNPAVIC00@bgmpomr1.sasknet.sk.ca> for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 10:18:32 -0600 (CST) Date: Thu, 18 Feb 2010 08:18:31 -0800 From: Stephen Hurd In-reply-to: <4B7D6635.20605@sasktel.net> To: Harald Schmalzbauer Message-id: <4B7D6857.80902@sasktel.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> <4B7D6635.20605@sasktel.net> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20091205 SeaMonkey/1.1.18 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-18_10:2010-02-06, 2010-02-18, 2010-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002180112 Cc: freebsd-stable@freebsd.org, Patrick Mahan Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:18:33 -0000 Stephen Hurd wrote: >> Some experimental results: >> When rsyncing with windows, and FreeBSD is receiver, I see the same >> ACK ever two segemnts, but speed is at 72MB/s. >> When FreeBSD is sender and Windows is receiver, it looks more I >> expected. There are about 20 data segments before a ACK is returned. >> And there are TCP Window Update Segments, reflecting smaller >> receiver buffers on the windows side. But this happens at a >> throughput of 82MB/s!!! So the windows machine is behaving like I >> understand the TCP flow control. >> Any explanation why the FreeBSD machine seems to ignore window size? > > The idea of delayed ACKs is to allow an ACK to be sent with data if > there will be data sent right away, not to combine ACKs... leaving out > ACKs makes calculation of RTT problematical which causes performance > problems all over the place... maybe the dearth of ACKs from the > windows system is causing the problem? If the problem is the ACKs from the Windows system, you should be seeing a large number of retransmits from the FreeBSD system (on the order of one retransmit per five packets). Is this what you're seeing? If you have a capture you could share covering a few seconds, I could take a look and provide a better opinion. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:24:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 868BE1065670 for ; Thu, 18 Feb 2010 16:24:08 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E4CEC8FC16 for ; Thu, 18 Feb 2010 16:24:07 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1IGO6C4039719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 17:24:06 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7D69A5.4010506@omnilan.de> Date: Thu, 18 Feb 2010 17:24:05 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Stephen Hurd References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> <4B7D6635.20605@sasktel.net> In-Reply-To: <4B7D6635.20605@sasktel.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD29873D2A213BACAF2C862D3" Cc: freebsd-stable@freebsd.org, Patrick Mahan Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:24:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD29873D2A213BACAF2C862D3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stephen Hurd schrieb am 18.02.2010 17:09 (localtime): =2E.. > A TCP SHOULD implement a delayed ACK, but an ACK should not be=20 > excessively delayed; in particular, the delay MUST be less than 0.5=20 > seconds, and in a stream of full-sized segments there SHOULD be an ACK = > for at least every second segment. That's why I asked for help understandig TCP. I'm surely wrong then. I=20 thought the ACK segment gets sent after the transfer of n segments=20 equals windows-size. I don't undesrtand that window size yet... I'm back = into my books > The idea of delayed ACKs is to allow an ACK to be sent with data if=20 > there will be data sent right away, not to combine ACKs... leaving out = > ACKs makes calculation of RTT problematical which causes performance=20 > problems all over the place... maybe the dearth of ACKs from the window= s=20 > system is causing the problem? The problem is not with the windows box, these transfer rates are=20 sensible. The problem is with two RELENG_8 machines. I'm doing this whole thing because I observed slowdowns under 20MB/s and = I try to reproduce and investigate this. But first I have to get the=20 idea right... If I don't understamd things going on when transfers make=20 sense, I won't be able to determine what happens when transfers are=20 slowed down... Thanks, -Harry --------------enigD29873D2A213BACAF2C862D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt9aaYACgkQLDqVQ9VXb8gYpQCfeJSz+CmIPUe47T+IEdKL+Rtf SqoAn1DOzDMZ4aIRgIE+wSg3v9fv4Gcp =GF9X -----END PGP SIGNATURE----- --------------enigD29873D2A213BACAF2C862D3-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:28:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9E06106568B for ; Thu, 18 Feb 2010 16:28:17 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9622A8FC12 for ; Thu, 18 Feb 2010 16:28:17 +0000 (UTC) Received: by vws14 with SMTP id 14so769436vws.13 for ; Thu, 18 Feb 2010 08:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tuyhyU+kb7b0d/cKm9yu2O/CodbT9yvHCptMOciDAQo=; b=HOkRsuphS15Vfl15+m/MDJa0McWxE6hjgmRNeN0pE6m16BhsdwJJJEsF/w0YAt150a hl9JrnNwGd1MAEOtNHJV8GdH4Nhrv3L0gDYzVp5o3rK3C2ZOdcqOyXpSCP8vPOLlrLrU z+9TbIXdLFIar0KcOPwy4LgZ0dUwIRM9j57to= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LaeV1IGUUstScY7UuxXTp55KwCbuY6ipdegpx5QQ2a8VEovXTJ+bOFKScwnZpdoQl4 eniFrR8mRfk1/CrXyQSBfuCVhV6nmg/YAPG7np2M6Mm3H5vmL1+lQ9IQX3mLvX9Ci+BB OfZBqsXv8h4UmAjBHecjPPlUznm1USjwV/XY4= MIME-Version: 1.0 Received: by 10.142.8.32 with SMTP id 32mr1765815wfh.161.1266510495752; Thu, 18 Feb 2010 08:28:15 -0800 (PST) In-Reply-To: <4B7D69A5.4010506@omnilan.de> References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> <4B7D6635.20605@sasktel.net> <4B7D69A5.4010506@omnilan.de> Date: Thu, 18 Feb 2010 10:28:15 -0600 Message-ID: <6201873e1002180828y406dca32k30ef64c05d1f7640@mail.gmail.com> From: Adam Vande More To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Patrick Mahan , freebsd-stable@freebsd.org, Stephen Hurd Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:28:18 -0000 On Thu, Feb 18, 2010 at 10:24 AM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > The problem is not with the windows box, these transfer rates are sensible. > The problem is with two RELENG_8 machines. > > I'm doing this whole thing because I observed slowdowns under 20MB/s and I > try to reproduce and investigate this. But first I have to get the idea > right... If I don't understamd things going on when transfers make sense, I > won't be able to determine what happens when transfers are slowed down... > Have you considered the possibility it's not a tcp issue at all, maybe a nic driver? -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:29:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA40106568F; Thu, 18 Feb 2010 16:29:34 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 284BD8FC21; Thu, 18 Feb 2010 16:29:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Ni9Fs-0004BK-RF>; Thu, 18 Feb 2010 17:29:32 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Ni9Fs-0007wa-P8>; Thu, 18 Feb 2010 17:29:32 +0100 Message-ID: <4B7D6B4D.9060604@zedat.fu-berlin.de> Date: Thu, 18 Feb 2010 16:31:09 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100217 Thunderbird/3.0.1 MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4B701269.9070703@zedat.fu-berlin.de> <20100208172033.112629f7@ernst.jennejohn.org> <4B706038.3030603@zedat.fu-berlin.de> <4B712DCE.7030500@zedat.fu-berlin.de> <20100209135402.02976be2@ernst.jennejohn.org> In-Reply-To: <20100209135402.02976be2@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:29:35 -0000 On 02/09/10 12:54, Gary Jennejohn wrote: > On Tue, 09 Feb 2010 09:41:34 +0000 > "O. Hartmann" wrote: > > [snip maybe too much] > >> On 02/08/10 21:42, Eitan Adler wrote: >> >>> you need to load the sem module (kldload sem). >>> >>> >> SysV smaphore (or sem?) are built into my kernel by default. The >> error/system message when crashing is >> >> socket(): Protocol not supported >> Illegal instruction (core dumped) >> >> and a core is dumped. >> >> > So, have you looked at the core dump with gdb to see where it appears > to be crashing? > > Could it be IPv6 related? Do you have IPv6 in the kernel and enabled? > I do. > > You could try adding these options to MOZ_OPTIONS in the Makefile > --enable-debug[=DBG] Enable building with developer debug info > --enable-debug-modules Enable/disable debug info for specific modules > --enable-debugger-info-modules > Enable/disable debugger info for specific modules > > --- > Gary Jennejohn > So, I did. I recompiled firefox 3.6 with the above debugging switches in /etc/make.conf. Additionally, I recompiled firefox3 port via 'portmaster -df', hoping this recompiles a possibly faulty lib. But this does not have any effect. Then I recompiled twice all my ports installed (approx. 909 ports, and preventing comments on that: yes, I once deleted and reinstalled everything, but after 'paraview' and a lot of Qt4-stuff installed, the number of ports tend to be that high!). This didn't show any effect. Inspecting the core dump doesn't show my anything unusual except the last line. A 'bt' shows 'infinite' numbers scrolling down the screen, so I gav up, due to my limited abilities in debugging and understanding what's going on. Firefox 3.5.7 still works on this specific box. On my private box at home, UP machine, same OS revision ( 8.0-STABLE FreeBSD 8.0-STABLE #0 r204007: Wed Feb 17 17:34:25 CET 2010), Firefox 3.6 works well. Thunderbird 3.0.1 also crashes spontanously since 3.0.1 got installed, 3.0.0 worked well. Maybe this issues are somehow related. Firefox 3.6 can be triggered to crash activating any pulldown menus, like 'Edit'. When not pressing any button except 'forward', 'backward', I can surf. But when pressing any button from Add ons or the 'Menu' or even popups, Firefox dies with a core. I feel a little bit helpless in this matter ... Below the gdb output. Thanks, Oliver ------- GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) quit ohartmann: gdb /usr/local/lib/firefox3/firefox-bin firefox-bin.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `firefox-bin'. Program terminated with signal 4, Illegal instruction. Reading symbols from /usr/local/lib/firefox3/libxul.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libxul.so Reading symbols from /usr/local/lib/firefox3/libmozjs.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libmozjs.so Reading symbols from /usr/local/lib/firefox3/libxpcom.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libxpcom.so Reading symbols from /usr/local/lib/libplds4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libplds4.so.1 Reading symbols from /usr/local/lib/libplc4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libplc4.so.1 Reading symbols from /usr/local/lib/libnspr4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libnspr4.so.1 Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libatk-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.0 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libgdk_pixbuf-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.0 Reading symbols from /usr/local/lib/libgio-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.0 Reading symbols from /usr/local/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXinerama.so.1 Reading symbols from /usr/local/lib/libXi.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXi.so.6 Reading symbols from /usr/local/lib/libXrandr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/libXcomposite.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcomposite.so.1 Reading symbols from /usr/local/lib/libXdamage.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdamage.so.1 Reading symbols from /usr/local/lib/libpangoft2-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.0 Reading symbols from /usr/local/lib/libpango-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.0 Reading symbols from /usr/local/lib/libfreetype.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libfontconfig.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfontconfig.so.1 Reading symbols from /usr/local/lib/libgobject-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /usr/local/lib/libcairo.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcairo.so.2 Reading symbols from /usr/local/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /lib/libz.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.5 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/local/lib/firefox3/libsqlite3.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libsqlite3.so Reading symbols from /usr/local/lib/firefox3/libsmime3.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libsmime3.so Reading symbols from /usr/local/lib/firefox3/libssl3.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libssl3.so Reading symbols from /usr/local/lib/firefox3/libnss3.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libnss3.so Reading symbols from /usr/local/lib/firefox3/libnssutil3.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libnssutil3.so Reading symbols from /usr/local/lib/libdbus-glib-1.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-glib-1.so.2 Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/lib/libXt.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXt.so.6 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libpixman-1.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpixman-1.so.9 Reading symbols from /usr/local/lib/libglitz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libglitz.so.1 Reading symbols from /usr/local/lib/libpng.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpng.so.5 Reading symbols from /usr/local/lib/libxcb-render-util.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-render-util.so.0 Reading symbols from /usr/local/lib/libxcb-render.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-render.so.0 Reading symbols from /usr/local/lib/libxcb.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/local/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/local/lib/libpthread-stubs.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpthread-stubs.so.0 Reading symbols from /usr/lib/librpcsvc.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librpcsvc.so.5 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/libicui18n.so.38...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicui18n.so.38 Reading symbols from /usr/local/lib/libintl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/local/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSM.so.6 Reading symbols from /usr/local/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libICE.so.6 Reading symbols from /usr/local/lib/libicuuc.so.38...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicuuc.so.38 Reading symbols from /usr/local/lib/libicudata.so.38...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicudata.so.38 Reading symbols from /usr/local/lib/nss_ldap.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss_ldap.so.1 Reading symbols from /usr/local/lib/libldap-2.4.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libldap-2.4.so.7 Reading symbols from /usr/local/lib/liblber-2.4.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/liblber-2.4.so.7 Reading symbols from /usr/local/lib/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libsasl2.so.2 Reading symbols from /usr/lib/libkrb5.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.10 Reading symbols from /usr/lib/libcom_err.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcom_err.so.5 Reading symbols from /usr/lib/libgssapi_krb5.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.10 Reading symbols from /usr/lib/libssl.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /usr/lib/libgssapi.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi.so.10 Reading symbols from /usr/lib/libhx509.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libhx509.so.10 Reading symbols from /usr/lib/libroken.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libroken.so.10 Reading symbols from /usr/lib/libasn1.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libasn1.so.10 Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /usr/local/lib/libgnomeui-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomeui-2.so.0 Reading symbols from /usr/local/lib/libbonoboui-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonoboui-2.so.0 Reading symbols from /usr/local/lib/libgnomecanvas-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/local/lib/libgailutil.so.18...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgailutil.so.18 Reading symbols from /usr/local/lib/libgnome-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnome-2.so.0 Reading symbols from /usr/local/lib/libesd.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libesd.so.2 Reading symbols from /usr/local/lib/libaudiofile.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libaudiofile.so.0 Reading symbols from /usr/local/lib/libart_lgpl_2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libart_lgpl_2.so.5 Reading symbols from /usr/local/lib/libbonobo-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonobo-2.so.0 Reading symbols from /usr/local/lib/libbonobo-activation.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonobo-activation.so.4 Reading symbols from /usr/local/lib/libORBitCosNaming-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libORBitCosNaming-2.so.0 Reading symbols from /usr/local/lib/libgnomevfs-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomevfs-2.so.0 Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/local/lib/libavahi-glib.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libavahi-glib.so.1 Reading symbols from /usr/local/lib/libavahi-client.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libavahi-client.so.3 Reading symbols from /usr/local/lib/libavahi-common.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libavahi-common.so.3 Reading symbols from /lib/libssp.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libssp.so.0 Reading symbols from /lib/libutil.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.8 Reading symbols from /usr/local/lib/libgconf-2.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgconf-2.so.4 Reading symbols from /usr/local/lib/libORBit-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libORBit-2.so.0 Reading symbols from /usr/local/lib/libgnome-keyring.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnome-keyring.so.0 Reading symbols from /usr/local/lib/libpopt.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpopt.so.0 Reading symbols from /usr/local/lib/firefox3/components/libbrowserdirprovider.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/components/libbrowserdirprovider.so Reading symbols from /usr/local/lib/firefox3/components/libdbusservice.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/components/libdbusservice.so Reading symbols from /usr/local/lib/firefox3/components/libimgicon.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/components/libimgicon.so Reading symbols from /usr/local/lib/pango/1.6.0/modules/pango-basic-fc.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/pango/1.6.0/modules/pango-basic-fc.so Reading symbols from /usr/local/lib/firefox3/components/libbrowsercomps.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/components/libbrowsercomps.so Reading symbols from /usr/local/lib/firefox3/components/libnkgnomevfs.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/components/libnkgnomevfs.so Reading symbols from /usr/local/lib/firefox3/libsoftokn3.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libsoftokn3.so Reading symbols from /usr/local/lib/firefox3/libnssdbm3.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libnssdbm3.so Reading symbols from /usr/local/lib/firefox3/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libfreebl3.so Reading symbols from /usr/local/lib/firefox3/libnssckbi.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/libnssckbi.so Reading symbols from /usr/local/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so Reading symbols from /usr/local/lib/libXss.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXss.so.1 Reading symbols from /usr/local/lib/firefox3/components/libmozgnome.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox3/components/libmozgnome.so Reading symbols from /usr/local/lib/libnotify.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libnotify.so.1 Reading symbols from /usr/local/lib/libcanberra.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcanberra.so.0 Reading symbols from /usr/local/lib/libvorbisfile.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvorbisfile.so.6 Reading symbols from /usr/local/lib/libvorbis.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvorbis.so.4 Reading symbols from /usr/local/lib/libogg.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libogg.so.6 Reading symbols from /usr/local/lib/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libltdl.so.7 Reading symbols from /usr/local/lib/libpulse.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpulse.so.0 Reading symbols from /usr/local/lib/libpulsecommon-0.9.21.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpulsecommon-0.9.21.so Reading symbols from /usr/local/lib/libcanberra-0.22/libcanberra-pulse.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcanberra-0.22/libcanberra-pulse.so Reading symbols from /usr/local/lib/libXtst.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXtst.so.6 Reading symbols from /usr/lib/libwrap.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libwrap.so.6 Reading symbols from /usr/local/lib/libsndfile.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libsndfile.so.1 Reading symbols from /usr/local/lib/libFLAC.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libFLAC.so.10 Reading symbols from /usr/local/lib/libvorbisenc.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvorbisenc.so.2 Reading symbols from /usr/local/lib/libgdbm.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgdbm.so.3 Reading symbols from /usr/local/lib/libexecinfo.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexecinfo.so.1 Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800507819 in _rtld_error () from /libexec/ld-elf.so.1 [New Thread 80ddec540 (LWP 100783)] [New Thread 80d752ec0 (LWP 100781)] [New Thread 80c056940 (LWP 100780)] [New Thread 80ddec1c0 (LWP 100779)] [New Thread 80ca30680 (LWP 100776)] [New Thread 80c051700 (LWP 100770)] [New Thread 807b73c00 (LWP 100683)] [New Thread 80c051a80 (LWP 100682)] [New Thread 807a0a740 (LWP 100681)] [New Thread 807b72a80 (LWP 100680)] [New Thread 807b72c40 (LWP 100679)] [New Thread 807b72e00 (LWP 100678)] [New Thread 807a041c0 (LWP 100760)] From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:38:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDC9B1065670 for ; Thu, 18 Feb 2010 16:38:49 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 355638FC08 for ; Thu, 18 Feb 2010 16:38:48 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1IGclKW039922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 17:38:48 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7D6D17.5080109@omnilan.de> Date: Thu, 18 Feb 2010 17:38:47 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Adam Vande More References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> <4B7D6635.20605@sasktel.net> <4B7D69A5.4010506@omnilan.de> <6201873e1002180828y406dca32k30ef64c05d1f7640@mail.gmail.com> In-Reply-To: <6201873e1002180828y406dca32k30ef64c05d1f7640@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig18566BD8309451D042D5E535" Cc: Patrick Mahan , freebsd-stable@freebsd.org, Stephen Hurd Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:38:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig18566BD8309451D042D5E535 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Adam Vande More schrieb am 18.02.2010 17:28 (localtime): > On Thu, Feb 18, 2010 at 10:24 AM, Harald Schmalzbauer=20 > > wrote: >=20 > The problem is not with the windows box, these transfer rates are > sensible. The problem is with two RELENG_8 machines. >=20 > I'm doing this whole thing because I observed slowdowns under 20MB/= s > and I try to reproduce and investigate this. But first I have to ge= t > the idea right... If I don't understamd things going on when > transfers make sense, I won't be able to determine what happens whe= n > transfers are slowed down... >=20 >=20 > Have you considered the possibility it's not a tcp issue at all, maybe = a=20 > nic driver? I did, but then the transfers to the windows box were also affected I gue= ss. And to answer the iperf wondering of Patrick: ------------------------------------------------------------ Client connecting to banana, TCP port 2121 TCP window size: 4.00 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.147.249 port 65230 connected with 192.168.147.11=20 port 2121 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.07 GBytes 918 Mbits/sec Though I have no idea what this tells me. Never used iperf before... Thanks, -Harry --------------enig18566BD8309451D042D5E535 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt9bRcACgkQLDqVQ9VXb8gZxwCfdtMmof4G3tA+tYILQqCHk2OZ Xg8Ani0pzk5zU7D6Fee8Ineg/lXdRo5r =+BjT -----END PGP SIGNATURE----- --------------enig18566BD8309451D042D5E535-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:40:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AF4F106566B; Thu, 18 Feb 2010 16:40:57 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC538FC15; Thu, 18 Feb 2010 16:40:55 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Ni9Qt-000652-3d>; Thu, 18 Feb 2010 17:40:55 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Ni9Qt-00009x-0J>; Thu, 18 Feb 2010 17:40:55 +0100 Message-ID: <4B7D6DF7.1040902@zedat.fu-berlin.de> Date: Thu, 18 Feb 2010 16:42:31 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100217 Thunderbird/3.0.1 MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4B701269.9070703@zedat.fu-berlin.de> <20100208172033.112629f7@ernst.jennejohn.org> <4B706038.3030603@zedat.fu-berlin.de> <4B712DCE.7030500@zedat.fu-berlin.de> <20100209135402.02976be2@ernst.jennejohn.org> <4B7D6B4D.9060604@zedat.fu-berlin.de> In-Reply-To: <4B7D6B4D.9060604@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:40:57 -0000 On 02/18/10 16:31, O. Hartmann wrote: > On 02/09/10 12:54, Gary Jennejohn wrote: >> On Tue, 09 Feb 2010 09:41:34 +0000 >> "O. Hartmann" wrote: >> >> [snip maybe too much] >>> On 02/08/10 21:42, Eitan Adler wrote: >>>> you need to load the sem module (kldload sem). >>>> >>> SysV smaphore (or sem?) are built into my kernel by default. The >>> error/system message when crashing is >>> >>> socket(): Protocol not supported >>> Illegal instruction (core dumped) >>> >>> and a core is dumped. >>> >> So, have you looked at the core dump with gdb to see where it appears >> to be crashing? >> >> Could it be IPv6 related? Do you have IPv6 in the kernel and enabled? >> I do. >> >> You could try adding these options to MOZ_OPTIONS in the Makefile >> --enable-debug[=DBG] Enable building with developer debug info >> --enable-debug-modules Enable/disable debug info for specific >> modules >> --enable-debugger-info-modules >> Enable/disable debugger info for specific >> modules >> >> --- >> Gary Jennejohn > > So, I did. I recompiled firefox 3.6 with the above debugging switches > in /etc/make.conf. > > Additionally, I recompiled firefox3 port via 'portmaster -df', hoping > this recompiles a possibly faulty lib. But this does not have any > effect. Then I recompiled twice all my ports installed (approx. 909 > ports, and preventing comments on that: yes, I once deleted and > reinstalled everything, but after 'paraview' and a lot of Qt4-stuff > installed, the number of ports tend to be that high!). > This didn't show any effect. > Inspecting the core dump doesn't show my anything unusual except the > last line. A 'bt' shows 'infinite' numbers scrolling down the screen, > so I gav up, due to my limited abilities in debugging and > understanding what's going on. > > Firefox 3.5.7 still works on this specific box. On my private box at > home, UP machine, same OS revision ( 8.0-STABLE FreeBSD 8.0-STABLE #0 > r204007: Wed Feb 17 17:34:25 CET 2010), Firefox 3.6 works well. > > Thunderbird 3.0.1 also crashes spontanously since 3.0.1 got installed, > 3.0.0 worked well. Maybe this issues are somehow related. Firefox 3.6 > can be triggered to crash activating any pulldown menus, like 'Edit'. > When not pressing any button except 'forward', 'backward', I can surf. > But when pressing any button from Add ons or the 'Menu' or even > popups, Firefox dies with a core. > > I feel a little bit helpless in this matter ... > > Below the gdb output. > > Thanks, > Oliver > ------- > > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging > symbols found)... > (gdb) quit > ohartmann: gdb /usr/local/lib/firefox3/firefox-bin firefox-bin.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging > symbols found)... > Core was generated by `firefox-bin'. > Program terminated with signal 4, Illegal instruction. > Reading symbols from /usr/local/lib/firefox3/libxul.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libxul.so > Reading symbols from /usr/local/lib/firefox3/libmozjs.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libmozjs.so > Reading symbols from /usr/local/lib/firefox3/libxpcom.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libxpcom.so > Reading symbols from /usr/local/lib/libplds4.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libplds4.so.1 > Reading symbols from /usr/local/lib/libplc4.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libplc4.so.1 > Reading symbols from /usr/local/lib/libnspr4.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libnspr4.so.1 > Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.0 > Reading symbols from /usr/local/lib/libatk-1.0.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libatk-1.0.so.0 > Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.0 > Reading symbols from /usr/local/lib/libgdk_pixbuf-2.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgdk_pixbuf-2.0.so.0 > Reading symbols from /usr/local/lib/libpangocairo-1.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.0 > Reading symbols from /usr/local/lib/libgio-2.0.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libgio-2.0.so.0 > Reading symbols from /usr/local/lib/libXext.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXext.so.6 > Reading symbols from /usr/local/lib/libXrender.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXrender.so.1 > Reading symbols from /usr/local/lib/libXinerama.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXinerama.so.1 > Reading symbols from /usr/local/lib/libXi.so.6...(no debugging symbols > found)...done. > Loaded symbols for /usr/local/lib/libXi.so.6 > Reading symbols from /usr/local/lib/libXrandr.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXrandr.so.2 > Reading symbols from /usr/local/lib/libXcursor.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXcursor.so.1 > Reading symbols from /usr/local/lib/libXcomposite.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXcomposite.so.1 > Reading symbols from /usr/local/lib/libXdamage.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXdamage.so.1 > Reading symbols from /usr/local/lib/libpangoft2-1.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.0 > Reading symbols from /usr/local/lib/libpango-1.0.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libpango-1.0.so.0 > Reading symbols from /usr/local/lib/libfreetype.so.9...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libfreetype.so.9 > Reading symbols from /usr/local/lib/libfontconfig.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libfontconfig.so.1 > Reading symbols from /usr/local/lib/libgobject-2.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgobject-2.0.so.0 > Reading symbols from /usr/local/lib/libgmodule-2.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgmodule-2.0.so.0 > Reading symbols from /usr/local/lib/libglib-2.0.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libglib-2.0.so.0 > Reading symbols from /usr/local/lib/libXfixes.so.3...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXfixes.so.3 > Reading symbols from /usr/local/lib/libcairo.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libcairo.so.2 > Reading symbols from /usr/local/lib/libX11.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libX11.so.6 > Reading symbols from /lib/libz.so.5...(no debugging symbols > found)...done. > Loaded symbols for /lib/libz.so.5 > Reading symbols from /lib/libm.so.5...(no debugging symbols > found)...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libiconv.so.3 > Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libstdc++.so.6 > Reading symbols from /lib/libc.so.7...(no debugging symbols > found)...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols > found)...done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libthr.so.3...(no debugging symbols > found)...done. > Loaded symbols for /lib/libthr.so.3 > Reading symbols from /usr/local/lib/firefox3/libsqlite3.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libsqlite3.so > Reading symbols from /usr/local/lib/firefox3/libsmime3.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libsmime3.so > Reading symbols from /usr/local/lib/firefox3/libssl3.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libssl3.so > Reading symbols from /usr/local/lib/firefox3/libnss3.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libnss3.so > Reading symbols from /usr/local/lib/firefox3/libnssutil3.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libnssutil3.so > Reading symbols from /usr/local/lib/libdbus-glib-1.so.2...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libdbus-glib-1.so.2 > Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libdbus-1.so.3 > Reading symbols from /usr/local/lib/libXt.so.6...(no debugging symbols > found)...done. > Loaded symbols for /usr/local/lib/libXt.so.6 > Reading symbols from /usr/local/lib/libgthread-2.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 > Reading symbols from /usr/local/lib/libpixman-1.so.9...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libpixman-1.so.9 > Reading symbols from /usr/local/lib/libglitz.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libglitz.so.1 > Reading symbols from /usr/local/lib/libpng.so.5...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libpng.so.5 > Reading symbols from /usr/local/lib/libxcb-render-util.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libxcb-render-util.so.0 > Reading symbols from /usr/local/lib/libxcb-render.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libxcb-render.so.0 > Reading symbols from /usr/local/lib/libxcb.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libxcb.so.2 > Reading symbols from /usr/local/lib/libXau.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXau.so.6 > Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXdmcp.so.6 > Reading symbols from /usr/local/lib/libpthread-stubs.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libpthread-stubs.so.0 > Reading symbols from /usr/lib/librpcsvc.so.5...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/librpcsvc.so.5 > Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libexpat.so.6 > Reading symbols from /usr/local/lib/libicui18n.so.38...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libicui18n.so.38 > Reading symbols from /usr/local/lib/libintl.so.8...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libintl.so.8 > Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libpcre.so.0 > Reading symbols from /usr/local/lib/libSM.so.6...(no debugging symbols > found)...done. > Loaded symbols for /usr/local/lib/libSM.so.6 > Reading symbols from /usr/local/lib/libICE.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libICE.so.6 > Reading symbols from /usr/local/lib/libicuuc.so.38...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libicuuc.so.38 > Reading symbols from /usr/local/lib/libicudata.so.38...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libicudata.so.38 > Reading symbols from /usr/local/lib/nss_ldap.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/nss_ldap.so.1 > Reading symbols from /usr/local/lib/libldap-2.4.so.7...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libldap-2.4.so.7 > Reading symbols from /usr/local/lib/liblber-2.4.so.7...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/liblber-2.4.so.7 > Reading symbols from /usr/local/lib/libsasl2.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libsasl2.so.2 > Reading symbols from /usr/lib/libkrb5.so.10...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libkrb5.so.10 > Reading symbols from /usr/lib/libcom_err.so.5...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libcom_err.so.5 > Reading symbols from /usr/lib/libgssapi_krb5.so.10...(no debugging > symbols found)...done. > Loaded symbols for /usr/lib/libgssapi_krb5.so.10 > Reading symbols from /usr/lib/libssl.so.6...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libssl.so.6 > Reading symbols from /lib/libcrypto.so.6...(no debugging symbols > found)...done. > Loaded symbols for /lib/libcrypto.so.6 > Reading symbols from /usr/lib/libgssapi.so.10...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libgssapi.so.10 > Reading symbols from /usr/lib/libhx509.so.10...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libhx509.so.10 > Reading symbols from /usr/lib/libroken.so.10...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libroken.so.10 > Reading symbols from /usr/lib/libasn1.so.10...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libasn1.so.10 > Reading symbols from /lib/libcrypt.so.5...(no debugging symbols > found)...done. > Loaded symbols for /lib/libcrypt.so.5 > Reading symbols from /usr/local/lib/libgnomeui-2.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libgnomeui-2.so.0 > Reading symbols from /usr/local/lib/libbonoboui-2.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libbonoboui-2.so.0 > Reading symbols from /usr/local/lib/libgnomecanvas-2.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgnomecanvas-2.so.0 > Reading symbols from /usr/local/lib/libgailutil.so.18...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libgailutil.so.18 > Reading symbols from /usr/local/lib/libgnome-2.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libgnome-2.so.0 > Reading symbols from /usr/local/lib/libesd.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libesd.so.2 > Reading symbols from /usr/local/lib/libaudiofile.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libaudiofile.so.0 > Reading symbols from /usr/local/lib/libart_lgpl_2.so.5...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libart_lgpl_2.so.5 > Reading symbols from /usr/local/lib/libbonobo-2.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libbonobo-2.so.0 > Reading symbols from /usr/local/lib/libbonobo-activation.so.4...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libbonobo-activation.so.4 > Reading symbols from /usr/local/lib/libORBitCosNaming-2.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libORBitCosNaming-2.so.0 > Reading symbols from /usr/local/lib/libgnomevfs-2.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libgnomevfs-2.so.0 > Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libxml2.so.5 > Reading symbols from /usr/local/lib/libavahi-glib.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libavahi-glib.so.1 > Reading symbols from /usr/local/lib/libavahi-client.so.3...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libavahi-client.so.3 > Reading symbols from /usr/local/lib/libavahi-common.so.3...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libavahi-common.so.3 > Reading symbols from /lib/libssp.so.0...(no debugging symbols > found)...done. > Loaded symbols for /lib/libssp.so.0 > Reading symbols from /lib/libutil.so.8...(no debugging symbols > found)...done. > Loaded symbols for /lib/libutil.so.8 > Reading symbols from /usr/local/lib/libgconf-2.so.4...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libgconf-2.so.4 > Reading symbols from /usr/local/lib/libORBit-2.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libORBit-2.so.0 > Reading symbols from /usr/local/lib/libgnome-keyring.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgnome-keyring.so.0 > Reading symbols from /usr/local/lib/libpopt.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libpopt.so.0 > Reading symbols from > /usr/local/lib/firefox3/components/libbrowserdirprovider.so...(no > debugging symbols found)...done. > Loaded symbols for > /usr/local/lib/firefox3/components/libbrowserdirprovider.so > Reading symbols from > /usr/local/lib/firefox3/components/libdbusservice.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/components/libdbusservice.so > Reading symbols from > /usr/local/lib/firefox3/components/libimgicon.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/components/libimgicon.so > Reading symbols from > /usr/local/lib/pango/1.6.0/modules/pango-basic-fc.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/pango/1.6.0/modules/pango-basic-fc.so > Reading symbols from > /usr/local/lib/firefox3/components/libbrowsercomps.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/components/libbrowsercomps.so > Reading symbols from > /usr/local/lib/firefox3/components/libnkgnomevfs.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/components/libnkgnomevfs.so > Reading symbols from /usr/local/lib/firefox3/libsoftokn3.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libsoftokn3.so > Reading symbols from /usr/local/lib/firefox3/libnssdbm3.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libnssdbm3.so > Reading symbols from /usr/local/lib/firefox3/libfreebl3.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libfreebl3.so > Reading symbols from /usr/local/lib/firefox3/libnssckbi.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/libnssckbi.so > Reading symbols from > /usr/local/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so...(no > debugging symbols found)...done. > Loaded symbols for > /usr/local/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so > Reading symbols from /usr/local/lib/libXss.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXss.so.1 > Reading symbols from > /usr/local/lib/firefox3/components/libmozgnome.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/firefox3/components/libmozgnome.so > Reading symbols from /usr/local/lib/libnotify.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libnotify.so.1 > Reading symbols from /usr/local/lib/libcanberra.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libcanberra.so.0 > Reading symbols from /usr/local/lib/libvorbisfile.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libvorbisfile.so.6 > Reading symbols from /usr/local/lib/libvorbis.so.4...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libvorbis.so.4 > Reading symbols from /usr/local/lib/libogg.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libogg.so.6 > Reading symbols from /usr/local/lib/libltdl.so.7...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libltdl.so.7 > Reading symbols from /usr/local/lib/libpulse.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libpulse.so.0 > Reading symbols from /usr/local/lib/libpulsecommon-0.9.21.so...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libpulsecommon-0.9.21.so > Reading symbols from > /usr/local/lib/libcanberra-0.22/libcanberra-pulse.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libcanberra-0.22/libcanberra-pulse.so > Reading symbols from /usr/local/lib/libXtst.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libXtst.so.6 > Reading symbols from /usr/lib/libwrap.so.6...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libwrap.so.6 > Reading symbols from /usr/local/lib/libsndfile.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libsndfile.so.1 > Reading symbols from /usr/local/lib/libFLAC.so.10...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libFLAC.so.10 > Reading symbols from /usr/local/lib/libvorbisenc.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libvorbisenc.so.2 > Reading symbols from /usr/local/lib/libgdbm.so.3...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libgdbm.so.3 > Reading symbols from /usr/local/lib/libexecinfo.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libexecinfo.so.1 > Reading symbols from /usr/lib/librt.so.1...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/librt.so.1 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols > found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x0000000800507819 in _rtld_error () from /libexec/ld-elf.so.1 > [New Thread 80ddec540 (LWP 100783)] > [New Thread 80d752ec0 (LWP 100781)] > [New Thread 80c056940 (LWP 100780)] > [New Thread 80ddec1c0 (LWP 100779)] > [New Thread 80ca30680 (LWP 100776)] > [New Thread 80c051700 (LWP 100770)] > [New Thread 807b73c00 (LWP 100683)] > [New Thread 80c051a80 (LWP 100682)] > [New Thread 807a0a740 (LWP 100681)] > [New Thread 807b72a80 (LWP 100680)] > [New Thread 807b72c40 (LWP 100679)] > [New Thread 807b72e00 (LWP 100678)] > [New Thread 807a041c0 (LWP 100760)] Addendum: This is the backtrace I tried ... after endless numbers of the same type as of the first issued line, there showed up a memory error. #0 0x0000000800507819 in _rtld_error () from /libexec/ld-elf.so.1 #1 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #2 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #3 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #4 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #5 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #6 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #7 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #8 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #9 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #10 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #11 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #12 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #13 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #14 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #15 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #16 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #17 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #18 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #19 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #20 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #21 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #22 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #23 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #24 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #25 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #26 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #27 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #28 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #29 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #30 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #31 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #32 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #33 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #34 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #35 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #36 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #37 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #38 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #39 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #40 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #41 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #42 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #43 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #44 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #45 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #46 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #47 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 #48 0x000000080050789b in _rtld_error () from /libexec/ld-elf.so.1 [...] #38329 0x0000000000000037 in ?? () Cannot access memory at address 0x800000000000 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:52:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91684106568B for ; Thu, 18 Feb 2010 16:52:41 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id B84C38FC08 for ; Thu, 18 Feb 2010 16:52:39 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1IGqc1F040102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 17:52:38 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7D7055.3060601@omnilan.de> Date: Thu, 18 Feb 2010 17:52:37 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Stephen Hurd References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> <4B7D6635.20605@sasktel.net> <4B7D6857.80902@sasktel.net> In-Reply-To: <4B7D6857.80902@sasktel.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig414F8604E9429B62B04040D6" Cc: freebsd-stable@freebsd.org, Patrick Mahan Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:52:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig414F8604E9429B62B04040D6 Content-Type: multipart/mixed; boundary="------------040808050401050801030609" This is a multi-part message in MIME format. --------------040808050401050801030609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stephen Hurd schrieb am 18.02.2010 17:18 (localtime): =2E.. > one retransmit per five packets). Is this what you're seeing? If you = > have a capture you could share covering a few seconds, I could take a=20 > look and provide a better opinion. Thanks for your help, here's a small snippet of the iperf session. There = are hundreds od duplicate ACKs. I'm not sure how to understand that.=20 Like mentioned, I have to refresh some TCP basics before I can do=20 usefull tests. But perhaps you can confirm that this behaviour is intendend, or where=20 the problem could be... Thanks, -Harry --------------040808050401050801030609 Content-Type: application/octet-stream; name="iperf.pcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="iperf.pcap" 1MOyoQIABAAAAAAAAAAAAGAAAAABAAAA3G19SyOCCQBKAAAASgAAAAAMKQF33AAVF8olAQgA RQAAPLmAQABABtjlwKiTC8Cok/mDoAhJs1SaWgAAAACgAv//qIQAAAIEBbQBAwMJBAIICgFk QR0AAAAA3G19SxaDCQA+AAAAPgAAAAAVF8olAQAMKQF33AgARQAAMEkHAABABolrwKiT+cCo kwsISYOgM+FtYbNUmltwEv//YN4AAAIEBbQEAgAA3G19Sx+DCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLmBQABABtj4wKiTC8Cok/mDoAhJs1SaWzPhbWJQEP//qHAAANxtfUspgwkA TgAAAE4AAAAADCkBd9wAFRfKJQEIAEUAAEC5gkAAQAbY38CokwvAqJP5g6AISbNUmlsz4W1i UBj//6iIAAAAAAAAAAAAAQAACEkAAAAAAAAAAP///BjcbX1LPYMJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcuYNAAEAG00LAqJMLwKiT+YOgCEmzVJpzM+FtYlAQ//+uJAAAAAAAAAAA AAEAAAhJAAAAAAAAAAD///wYNDU2Nzg5MDEyMzQ1Njc4OTAx3G19S0CDCQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LmEQABABtNBwKiTC8Cok/mDoAhJs1SgJzPhbWJQEP//riQAADAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMdxtfUtCgwkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy5hUAAQAbTQMCokwvAqJP5g6AISbNUpdsz4W1iUBD//64k AAAwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDHcbX1LRYMJAGAA AADSBQAAAAwpAXfcABUXyiUBCABFAAXEuYZAAEAG01fAqJMLwKiT+YOgCEmzVKuPM+FtYlAQ //+uDAAAMDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19S0uD CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLmHQABABtjywKiTC8Cok/mDoAhJs1SxKzPh bWJQEP//qHAAANxtfUtQgwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5iEAAQAbY8cCo kwvAqJP5g6AISbNUsSsz4W1iUBD//6hwAADcbX1LVYMJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAouYlAAEAG2PDAqJMLwKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19S1yDCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLmKQABABtjvwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP// qHAAANxtfUtigwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5i0AAQAbY7sCokwvAqJP5 g6AISbNUsSsz4W1iUBD//6hwAADcbX1LZ4MJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo uYxAAEAG2O3AqJMLwKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19S22DCQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLmOQABABtjrwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//qHAAANxt fUtxgwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5j0AAQAbY6sCokwvAqJP5g6AISbNU sSsz4W1iUBD//6hwAADcbX1LdoMJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouZBAAEAG 2OnAqJMLwKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19S3qDCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLmRQABABtjowKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//qHAAANxtfUt/gwkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5kkAAQAbY58CokwvAqJP5g6AISbNUsSsz4W1i UBD//6hwAADcbX1LhIMJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouZNAAEAG2ObAqJML wKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19S4qDCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLmUQABABtjlwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//qHAAANxtfUuPgwkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi5lUAAQAbY5MCokwvAqJP5g6AISbNUsSsz4W1iUBD//6hw AADcbX1LlIMJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouZZAAEAG2OPAqJMLwKiT+YOg CEmzVLErM+FtYlAQ//+ocAAA3G19S52DCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLmX QABABtjiwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//qHAAANxtfUuegwkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi5mEAAQAbY4cCokwvAqJP5g6AISbNUsSsz4W1iUBD//6hwAADcbX1L ooMJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouZlAAEAG2ODAqJMLwKiT+YOgCEmzVLEr M+FtYlAQ//+ocAAA3G19S6eDCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLmaQABABtjf wKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//qHAAANxtfUusgwkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi5m0AAQAbY3sCokwvAqJP5g6AISbNUsSsz4W1iUBD//6hwAADcbX1LsoMJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAouZxAAEAG2N3AqJMLwKiT+YOgCEmzVLErM+FtYlAQ //+ocAAA3G19S7eDCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLmdQABABtjcwKiTC8Co k/mDoAhJs1SxKzPhbWJQEP//qHAAANxtfUu8gwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi5nkAAQAbY28CokwvAqJP5g6AISbNUsSsz4W1iUBD//6hwAADcbX1LwYMJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAouZ9AAEAG2NrAqJMLwKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA 3G19S8aDCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLmgQABABtjZwKiTC8Cok/mDoAhJ s1SxKzPhbWJQEP//qHAAANxtfUvLgwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5oUAA QAbY2MCokwvAqJP5g6AISbNUsSsz4W1iUBD//6hwAADcbX1L0YMJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAouaJAAEAG2NfAqJMLwKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19S9aD CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLmjQABABtjWwKiTC8Cok/mDoAhJs1SxKzPh bWJQEP//qHAAANxtfUvbgwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5pEAAQAbY1cCo kwvAqJP5g6AISbNUsSsz4W1iUBD//6hwAADcbX1L4IMJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAouaVAAEAG2NTAqJMLwKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19S+WDCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLmmQABABtjTwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP// qHAAANxtfUvqgwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5p0AAQAbY0sCokwvAqJP5 g6AISbNUsSsz4W1iUBD//6hwAADcbX1L74MJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo uahAAEAG2NHAqJMLwKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19S/SDCQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLmpQABABtjQwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//qHAAANxt fUv5gwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5qkAAQAbYz8CokwvAqJP5g6AISbNU sSsz4W1iUBD//6hwAADcbX1L/4MJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouatAAEAG 2M7AqJMLwKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19SwSECQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLmsQABABtjNwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//qHAAANxtfUsJhAkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5rUAAQAbYzMCokwvAqJP5g6AISbNUsSsz4W1i UBD//6hwAADcbX1LDoQJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoua5AAEAG2MvAqJML wKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19SxSECQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLmvQABABtjKwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//qHAAANxtfUsXhAkAPAAAADwA AAAAFRfKJQEADCkBd9wIAEUAAChJCAAAQAaJcsCok/nAqJMLCEmDoDPhbWKzVKAnUBD//4bV AAAAAAAAAADcbX1LGoQJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoubBAAEAG2MnAqJML wKiT+YOgCEmzVLErM+FtYlAQ//+ocAAA3G19Sx+ECQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3LmxQABABtMUwKiTC8Cok/mDoAhJs1SxKzPhbWJQEP//riQAADY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2N9xtfUsihAkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy5skAAQAbTE8CokwvAqJP5g6AISbNUtt8z4W1iUBD//64kAAA2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1NjfcbX1LJIQJAE4AAABOAAAAAAwpAXfc ABUXyiUBCABFAABAubNAAEAG2K7AqJMLwKiT+YOgCEmzVLyTM+FtYlAQ//+oiAAANDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY33G19SyaECQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEkJ AABABolxwKiT+cCokwsISYOgM+FtYrNUq49QEP//e20AAAAAAAAAANxtfUsohAkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi5tEAAQAbYxcCokwvAqJP5g6AISbNUvKsz4W1iUBD//6hw AADcbX1LK4QJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcubVAAEAG0xDAqJMLwKiT+YOg CEmzVLyrM+FtYlAQ//+uJAAAODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg53G19Sy6ECQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3Lm2QABABtMPwKiTC8Co k/mDoAhJs1TCXzPhbWJQEP//riQAADg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OdxtfUswhAkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy5t0AAQAbTDsCo kwvAqJP5g6AISbNUyBMz4W1iUBD//64kAAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODncbX1LN4QJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoubhAAEAG 2MHAqJMLwKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA3G19SziECQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLm5QABABtjAwKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUs7hAkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5ukAAQAbYv8CokwvAqJP5g6AISbNUzccz4W1i UBD//6hwAADcbX1LQIQJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoubtAAEAG2L7AqJML wKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA3G19S0aECQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLm8QABABti9wKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUtLhAkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi5vUAAQAbYvMCokwvAqJP5g6AISbNUzccz4W1iUBD//6hw AADcbX1LUIQJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoub5AAEAG2LvAqJMLwKiT+YOg CEmzVM3HM+FtYlAQ//+ocAAA3G19S1WECQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLm/ QABABti6wKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUtahAkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi5wEAAQAbYucCokwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1L X4QJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoucFAAEAG2LjAqJMLwKiT+YOgCEmzVM3H M+FtYlAQ//+ocAAA3G19S2SECQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLnCQABABti3 wKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUtqhAkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi5w0AAQAbYtsCokwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1Lb4QJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAoucRAAEAG2LXAqJMLwKiT+YOgCEmzVM3HM+FtYlAQ //+ocAAA3G19S3SECQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLnFQABABti0wKiTC8Co k/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUt5hAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi5xkAAQAbYs8CokwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1LfYQJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAoucdAAEAG2LLAqJMLwKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA 3G19S4KECQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLnIQABABtixwKiTC8Cok/mDoAhJ s1TNxzPhbWJQEP//qHAAANxtfUuHhAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5yUAA QAbYsMCokwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1LjIQJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAoucpAAEAG2K/AqJMLwKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA3G19S5GE CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLnLQABABtiuwKiTC8Cok/mDoAhJs1TNxzPh bWJQEP//qHAAANxtfUuXhAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5zEAAQAbYrcCo kwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1Lm4QJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAouc1AAEAG2KzAqJMLwKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA3G19S6CECQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLnOQABABtirwKiTC8Cok/mDoAhJs1TNxzPhbWJQEP// qHAAANxtfUulhAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5z0AAQAbYqsCokwvAqJP5 g6AISbNUzccz4W1iUBD//6hwAADcbX1LqoQJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo udBAAEAG2KnAqJMLwKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA3G19S6+ECQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLnRQABABtiowKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxt fUu0hAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi50kAAQAbYp8CokwvAqJP5g6AISbNU zccz4W1iUBD//6hwAADcbX1LuYQJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoudNAAEAG 2KbAqJMLwKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA3G19S76ECQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLnUQABABtilwKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUvDhAkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi51UAAQAbYpMCokwvAqJP5g6AISbNUzccz4W1i UBD//6hwAADcbX1LyIQJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoudZAAEAG2KPAqJML wKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA3G19S82ECQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLnXQABABtiiwKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUvShAkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi52EAAQAbYocCokwvAqJP5g6AISbNUzccz4W1iUBD//6hw AADcbX1L14QJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoudlAAEAG2KDAqJMLwKiT+YOg CEmzVM3HM+FtYlAQ//+ocAAA3G19S9yECQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLna QABABtifwKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUvhhAkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi520AAQAbYnsCokwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1L 5oQJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoudxAAEAG2J3AqJMLwKiT+YOgCEmzVM3H M+FtYlAQ//+ocAAA3G19S+uECQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLndQABABtic wKiTC8Cok/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUvwhAkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi53kAAQAbYm8CokwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1L9YQJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAoud9AAEAG2JrAqJMLwKiT+YOgCEmzVM3HM+FtYlAQ //+ocAAA3G19S/qECQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLngQABABtiZwKiTC8Co k/mDoAhJs1TNxzPhbWJQEP//qHAAANxtfUv/hAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi54UAAQAbYmMCokwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1LBIUJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAoueJAAEAG2JfAqJMLwKiT+YOgCEmzVM3HM+FtYlAQ//+ocAAA 3G19SwmFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLnjQABABtiWwKiTC8Cok/mDoAhJ s1TNxzPhbWJQEP//qHAAANxtfUsOhQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi55EAA QAbYlcCokwvAqJP5g6AISbNUzccz4W1iUBD//6hwAADcbX1LEIUJADwAAAA8AAAAABUXyiUB AAwpAXfcCABFAAAoSQoAAEAGiXDAqJP5wKiTCwhJg6Az4W1is1S231AQ//9wHQAAAAAAAAAA 3G19SxSFCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LnlQABABtLgwKiTC8Cok/mDoAhJ s1TNxzPhbWJQEP//riQAADg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OdxtfUsXhQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy55kAAQAbS38CokwvAqJP5 g6AISbNU03sz4W1iUBD//64kAAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODncbX1LGYUJAGAAAADSBQAAAAwpAXfcABUXyiUBCABFAAXEuedAAEAG0vbAqJML wKiT+YOgCEmzVNkvM+FtYlAQ//+uDAAAODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg53G19SxuFCQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEkLAABABolv wKiT+cCokwsISYOgM+FtYrNUvKtQEP//alEAAAAAAAAAANxtfUsdhQkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi56EAAQAbYkcCokwvAqJP5g6AISbNU3ssz4W1iUBD//6hwAADcbX1L IIUJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuelAAEAG0tzAqJMLwKiT+YOgCEmzVN7L M+FtYlAQ//+uJAAAMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz 3G19SyKFCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LnqQABABtLbwKiTC8Cok/mDoAhJ s1TkfzPhbWJQEP//riQAADIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyM9xtfUslhQkATgAAAE4AAAAADCkBd9wAFRfKJQEIAEUAAEC560AAQAbYdsCokwvAqJP5 g6AISbNU6jMz4W1iUBD//6iIAAAyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDXcbX1LJ4UJADwA AAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSQwAAEAGiW7AqJP5wKiTCwhJg6Az4W1is1TIE1AQ //9e6QAAAAAAAAAA3G19SyiFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLnsQABABtiN wKiTC8Cok/mDoAhJs1TqSzPhbWJQEP//qHAAANxtfUsshQkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy57UAAQAbS2MCokwvAqJP5g6AISbNU6ksz4W1iUBD//64kAAA2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1NjfcbX1LLoUJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcue5AAEAG0tfAqJMLwKiT+YOgCEmzVO//M+FtYlAQ//+uJAAANjc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY33G19SzCFCQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LnvQABABtLWwKiTC8Cok/mDoAhJs1T1szPhbWJQEP//riQAADY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2N9xtfUs3hQkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi58EAAQAbYicCokwvAqJP5g6AISbNU+2cz4W1iUBD//6hw AADcbX1LOYUJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoufFAAEAG2IjAqJMLwKiT+YOg CEmzVPtnM+FtYlAQ//+ocAAA3G19SzuFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLny QABABtiHwKiTC8Cok/mDoAhJs1T7ZzPhbWJQEP//qHAAANxtfUtBhQkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi580AAQAbYhsCokwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1L RoUJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoufRAAEAG2IXAqJMLwKiT+YOgCEmzVPtn M+FtYlAQ//+ocAAA3G19S0uFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLn1QABABtiE wKiTC8Cok/mDoAhJs1T7ZzPhbWJQEP//qHAAANxtfUtQhQkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi59kAAQAbYg8CokwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1LVYUJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAoufdAAEAG2ILAqJMLwKiT+YOgCEmzVPtnM+FtYlAQ //+ocAAA3G19S1qFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLn4QABABtiBwKiTC8Co k/mDoAhJs1T7ZzPhbWJQEP//qHAAANxtfUtghQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi5+UAAQAbYgMCokwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1LZIUJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAoufpAAEAG2H/AqJMLwKiT+YOgCEmzVPtnM+FtYlAQ//+ocAAA 3G19S2qFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLn7QABABth+wKiTC8Cok/mDoAhJ s1T7ZzPhbWJQEP//qHAAANxtfUtvhQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5/EAA QAbYfcCokwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1LdIUJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAouf1AAEAG2HzAqJMLwKiT+YOgCEmzVPtnM+FtYlAQ//+ocAAA3G19S3mF CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLn+QABABth7wKiTC8Cok/mDoAhJs1T7ZzPh bWJQEP//qHAAANxtfUt+hQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi5/0AAQAbYesCo kwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1LhIUJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAougBAAEAG2HnAqJMLwKiT+YOgCEmzVPtnM+FtYlAQ//+ocAAA3G19S4mFCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLoBQABABth4wKiTC8Cok/mDoAhJs1T7ZzPhbWJQEP// qHAAANxtfUuPhQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6AkAAQAbYd8CokwvAqJP5 g6AISbNU+2cz4W1iUBD//6hwAADcbX1LkoUJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo ugNAAEAG2HbAqJMLwKiT+YOgCEmzVPtnM+FtYlAQ//+ocAAA3G19S5iFCQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLoEQABABth1wKiTC8Cok/mDoAhJs1T7ZzPhbWJQEP//qHAAANxt fUudhQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6BUAAQAbYdMCokwvAqJP5g6AISbNU +2cz4W1iUBD//6hwAADcbX1LooUJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAougZAAEAG 2HPAqJMLwKiT+YOgCEmzVPtnM+FtYlAQ//+ocAAA3G19S6eFCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLoHQABABthywKiTC8Cok/mDoAhJs1T7ZzPhbWJQEP//qHAAANxtfUushQkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6CEAAQAbYccCokwvAqJP5g6AISbNU+2cz4W1i UBD//6hwAADcbX1LsYUJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouglAAEAG2HDAqJML wKiT+YOgCEmzVPtnM+FtYlAQ//+ocAAA3G19S7aFCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLoKQABABthvwKiTC8Cok/mDoAhJs1T7ZzPhbWJQEP//qHAAANxtfUu7hQkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi6C0AAQAbYbsCokwvAqJP5g6AISbNU+2cz4W1iUBD//6hw AADcbX1LwIUJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAougxAAEAG2G3AqJMLwKiT+YOg CEmzVPtnM+FtYlAQ//+ocAAA3G19S8WFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLoN QABABthswKiTC8Cok/mDoAhJs1T7ZzPhbWJQEP//qHAAANxtfUvKhQkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi6DkAAQAbYa8CokwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1L z4UJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoug9AAEAG2GrAqJMLwKiT+YOgCEmzVPtn M+FtYlAQ//+ocAAA3G19S9SFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLoQQABABthp wKiTC8Cok/mDoAhJs1T7ZzPhbWJQEP//qHAAANxtfUvZhQkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi6EUAAQAbYaMCokwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1L34UJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAouhJAAEAG2GfAqJMLwKiT+YOgCEmzVPtnM+FtYlAQ //+ocAAA3G19S+SFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLoTQABABthmwKiTC8Co k/mDoAhJs1T7ZzPhbWJQEP//qHAAANxtfUvphQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi6FEAAQAbYZcCokwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1L7oUJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAouhVAAEAG2GTAqJMLwKiT+YOgCEmzVPtnM+FtYlAQ//+ocAAA 3G19S/OFCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLoWQABABthjwKiTC8Cok/mDoAhJ s1T7ZzPhbWJQEP//qHAAANxtfUv4hQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6F0AA QAbYYsCokwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1L/oUJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAouhhAAEAG2GHAqJMLwKiT+YOgCEmzVPtnM+FtYlAQ//+ocAAA3G19SwOG CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLoZQABABthgwKiTC8Cok/mDoAhJs1T7ZzPh bWJQEP//qHAAANxtfUsIhgkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6GkAAQAbYX8Co kwvAqJP5g6AISbNU+2cz4W1iUBD//6hwAADcbX1LCYYJADwAAAA8AAAAABUXyiUBAAwpAXfc CABFAAAoSQ0AAEAGiW3AqJP5wKiTCwhJg6Az4W1is1TTe1AQ//9TgQAAAAAAAAAA3G19Sw6G CQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LobQABABtKqwKiTC8Cok/mDoAhJs1T7ZzPh bWJQEP//riQAADQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0Ndxt fUsQhgkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6HEAAQAbSqcCokwvAqJP5g6AISbNV ARsz4W1iUBD//64kAAA0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDXcbX1LE4YJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuh1AAEAG0qjAqJMLwKiT+YOg CEmzVQbPM+FtYlAQ//+uJAAANDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ13G19SxWGCQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEkOAABABolswKiT+cCo kwsISYOgM+FtYrNU3stQEP//SDEAAAAAAAAAANxtfUsWhgkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi6HkAAQAbYW8CokwvAqJP5g6AISbNVDIMz4W1iUBD//6hwAADcbX1LGoYJAGAA AADqBQAAAAwpAXfcABUXyiUBCABFAAXcuh9AAEAG0qbAqJMLwKiT+YOgCEmzVQyDM+FtYlAQ //+uJAAANDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ13G19SxyG CQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LogQABABtKlwKiTC8Cok/mDoAhJs1USNzPh bWJQEP//riQAADQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0Ndxt fUsfhgkAYAAAANIFAAAADCkBd9wAFRfKJQEIAEUABcS6IUAAQAbSvMCokwvAqJP5g6AISbNV F+sz4W1iUBD//64MAAA0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDXcbX1LIYYJADwAAAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSQ8AAEAGiWvAqJP5wKiTCwhJ g6Az4W1is1TqM1AQ//88yQAAAAAAAAAA3G19SyKGCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLoiQABABthXwKiTC8Cok/mDoAhJs1UdhzPhbWJQEP//qHAAANxtfUsmhgkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy6I0AAQAbSosCokwvAqJP5g6AISbNVHYcz4W1iUBD//64k AAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1LKIYJAGAA AADqBQAAAAwpAXfcABUXyiUBCABFAAXcuiRAAEAG0qHAqJMLwKiT+YOgCEmzVSM7M+FtYlAQ //+uJAAAODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg53G19SyuG CQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LolQABABtKgwKiTC8Cok/mDoAhJs1Uo7zPh bWJQEP//riQAADg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4Odxt fUsthgkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJEAAAQAaJasCok/nAqJMLCEmDoDPh bWKzVO//UBD//zb9AAAAAAAAAADcbX1LLoYJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo uiZAAEAG2FPAqJMLwKiT+YOgCEmzVS6jM+FtYlAQ//+ocAAA3G19SzKGCQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LonQABABtKewKiTC8Cok/mDoAhJs1UuozPhbWJQEP//riQAADg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OdxtfUs1hgkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy6KEAAQAbSncCokwvAqJP5g6AISbNVNFcz4W1iUBD//64k AAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1LN4YJAE4A AABOAAAAAAwpAXfcABUXyiUBCABFAABAuilAAEAG2DjAqJMLwKiT+YOgCEmzVToLM+FtYlAQ //+oiAAAODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19Sz6GCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLoqQABABthPwKiTC8Cok/mDoAhJs1U6IzPhbWJQEP//qHAAANxtfUtAhgkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6K0AAQAbYTsCokwvAqJP5g6AISbNVOiMz4W1i UBD//6hwAADcbX1LQYYJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouixAAEAG2E3AqJML wKiT+YOgCEmzVTojM+FtYlAQ//+ocAAA3G19S0WGCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLotQABABthMwKiTC8Cok/mDoAhJs1U6IzPhbWJQEP//qHAAANxtfUtKhgkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi6LkAAQAbYS8CokwvAqJP5g6AISbNVOiMz4W1iUBD//6hw AADcbX1LUIYJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoui9AAEAG2ErAqJMLwKiT+YOg CEmzVTojM+FtYlAQ//+ocAAA3G19S1WGCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLow QABABthJwKiTC8Cok/mDoAhJs1U6IzPhbWJQEP//qHAAANxtfUtahgkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi6MUAAQAbYSMCokwvAqJP5g6AISbNVOiMz4W1iUBD//6hwAADcbX1L X4YJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoujJAAEAG2EfAqJMLwKiT+YOgCEmzVToj M+FtYlAQ//+ocAAA3G19S2SGCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLozQABABthG wKiTC8Cok/mDoAhJs1U6IzPhbWJQEP//qHAAANxtfUtphgkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi6NEAAQAbYRcCokwvAqJP5g6AISbNVOiMz4W1iUBD//6hwAADcbX1LboYJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAoujVAAEAG2ETAqJMLwKiT+YOgCEmzVTojM+FtYlAQ //+ocAAA3G19S3OGCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLo2QABABthDwKiTC8Co k/mDoAhJs1U6IzPhbWJQEP//qHAAANxtfUt4hgkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi6N0AAQAbYQsCokwvAqJP5g6AISbNVOiMz4W1iUBD//6hwAADcbX1LfoYJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAoujhAAEAG2EHAqJMLwKiT+YOgCEmzVTojM+FtYlAQ//+ocAAA 3G19S4OGCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLo5QABABthAwKiTC8Cok/mDoAhJ s1U6IzPhbWJQEP//qHAAANxtfUuHhgkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJEQAA QAaJacCok/nAqJMLCEmDoDPhbWKzVPtnUBD//yuVAAAAAAAAAADcbX1LiYYJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAoujpAAEAG2D/AqJMLwKiT+YOgCEmzVTojM+FtYlAQ//+ocAAA 3G19S42GCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3Lo7QABABtKKwKiTC8Cok/mDoAhJ s1U6IzPhbWJQEP//riQAADIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyM9xtfUuPhgkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6PEAAQAbSicCokwvAqJP5 g6AISbNVP9cz4W1iUBD//64kAAAwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDHcbX1LkoYJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuj1AAEAG0ojAqJML wKiT+YOgCEmzVUWLM+FtYlAQ//+uJAAAMDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAx3G19S5aGCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLo+QABABtg7 wKiTC8Cok/mDoAhJs1VLPzPhbWJQEP//qHAAANxtfUuYhgkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi6P0AAQAbYOsCokwvAqJP5g6AISbNVSz8z4W1iUBD//6hwAADcbX1LnYYJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAoukBAAEAG2DnAqJMLwKiT+YOgCEmzVUs/M+FtYlAQ //+ocAAA3G19S6OGCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLpBQABABtg4wKiTC8Co k/mDoAhJs1VLPzPhbWJQEP//qHAAANxtfUuohgkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi6QkAAQAbYN8CokwvAqJP5g6AISbNVSz8z4W1iUBD//6hwAADcbX1LrYYJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAoukNAAEAG2DbAqJMLwKiT+YOgCEmzVUs/M+FtYlAQ//+ocAAA 3G19S7KGCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLpEQABABtg1wKiTC8Cok/mDoAhJ s1VLPzPhbWJQEP//qHAAANxtfUu3hgkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6RUAA QAbYNMCokwvAqJP5g6AISbNVSz8z4W1iUBD//6hwAADcbX1LvIYJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAoukZAAEAG2DPAqJMLwKiT+YOgCEmzVUs/M+FtYlAQ//+ocAAA3G19S8GG CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLpHQABABtgywKiTC8Cok/mDoAhJs1VLPzPh bWJQEP//qHAAANxtfUvGhgkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6SEAAQAbYMcCo kwvAqJP5g6AISbNVSz8z4W1iUBD//6hwAADcbX1Ly4YJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAouklAAEAG2DDAqJMLwKiT+YOgCEmzVUs/M+FtYlAQ//+ocAAA3G19S9CGCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLpKQABABtgvwKiTC8Cok/mDoAhJs1VLPzPhbWJQEP// qHAAANxtfUvWhgkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6S0AAQAbYLsCokwvAqJP5 g6AISbNVSz8z4W1iUBD//6hwAADcbX1L24YJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo ukxAAEAG2C3AqJMLwKiT+YOgCEmzVUs/M+FtYlAQ//+ocAAA3G19S+CGCQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLpNQABABtgswKiTC8Cok/mDoAhJs1VLPzPhbWJQEP//qHAAANxt fUvlhgkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6TkAAQAbYK8CokwvAqJP5g6AISbNV Sz8z4W1iUBD//6hwAADcbX1L6oYJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouk9AAEAG 2CrAqJMLwKiT+YOgCEmzVUs/M+FtYlAQ//+ocAAA3G19S/CGCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLpQQABABtgpwKiTC8Cok/mDoAhJs1VLPzPhbWJQEP//qHAAANxtfUv0hgkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6UUAAQAbYKMCokwvAqJP5g6AISbNVSz8z4W1i UBD//6hwAADcbX1L+oYJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoulJAAEAG2CfAqJML wKiT+YOgCEmzVUs/M+FtYlAQ//+ocAAA3G19S/+GCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLpTQABABtgmwKiTC8Cok/mDoAhJs1VLPzPhbWJQEP//qHAAANxtfUsEhwkAPAAAADwA AAAAFRfKJQEADCkBd9wIAEUAAChJEgAAQAaJaMCok/nAqJMLCEmDoDPhbWKzVQbPUBD//yAt AAAAAAAAAADcbX1LBYcJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoulRAAEAG2CXAqJML wKiT+YOgCEmzVUs/M+FtYlAQ//+ocAAA3G19SwmHCQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3LpVQABABtJwwKiTC8Cok/mDoAhJs1VLPzPhbWJQEP//riQAADAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMdxtfUsLhwkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy6VkAAQAbSb8CokwvAqJP5g6AISbNVUPMz4W1iUBD//64kAAAwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDHcbX1LDocJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXculdAAEAG0m7AqJMLwKiT+YOgCEmzVVanM+FtYlAQ//+uJAAAMDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19SxCHCQA8AAAAPAAAAAAV F8olAQAMKQF33AgARQAAKEkTAABABolnwKiT+cCokwsISYOgM+FtYrNVEjdQEP//FMUAAAAA AAAAANxtfUsRhwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6WEAAQAbYIcCokwvAqJP5 g6AISbNVXFsz4W1iUBD//6hwAADcbX1LFYcJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc ullAAEAG0mzAqJMLwKiT+YOgCEmzVVxbM+FtYlAQ//+uJAAAODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg53G19SxeHCQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3LpaQABABtJrwKiTC8Cok/mDoAhJs1ViDzPhbWJQEP//riQAADg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OdxtfUsZhwkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy6W0AAQAbSasCokwvAqJP5g6AISbNVZ8Mz4W1iUBD//64kAAA4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1LG4cJADwAAAA8AAAAABUXyiUB AAwpAXfcCABFAAAoSRQAAEAGiWbAqJP5wKiTCwhJg6Az4W1is1Udh1AQ//8JdQAAAAAAAAAA 3G19Sx2HCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLpcQABABtgdwKiTC8Cok/mDoAhJ s1VtdzPhbWJQEP//qHAAANxtfUsghwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6XUAA QAbSaMCokwvAqJP5g6AISbNVbXcz4W1iUBD//64kAAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1LI4cJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc ul5AAEAG0mfAqJMLwKiT+YOgCEmzVXMrM+FtYlAQ//+uJAAAODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg53G19SyWHCQBgAAAA0gUAAAAMKQF33AAVF8olAQgA RQAFxLpfQABABtJ+wKiTC8Cok/mDoAhJs1V43zPhbWJQEP//rgwAADg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OdxtfUsnhwkAPAAAADwAAAAAFRfKJQEADCkB d9wIAEUAAChJFQAAQAaJZcCok/nAqJMLCEmDoDPhbWKzVSjvUBD///4MAAAAAAAAAADcbX1L KIcJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoumBAAEAG2BnAqJMLwKiT+YOgCEmzVX57 M+FtYlAQ//+ocAAA3G19SyyHCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LphQABABtJk wKiTC8Cok/mDoAhJs1V+ezPhbWJQEP//riQAADIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyM9xtfUsuhwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6YkAA QAbSY8CokwvAqJP5g6AISbNVhC8z4W1iUBD//64kAAAyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1Njc4OTAxMjPcbX1LMIcJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc umNAAEAG0mLAqJMLwKiT+YOgCEmzVYnjM+FtYlAQ//+uJAAAMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz3G19SzOHCQA8AAAAPAAAAAAVF8olAQAMKQF33AgA RQAAKEkWAABABolkwKiT+cCokwsISYOgM+FtYrNVNFdQEP//8qQAAAAAAAAAANxtfUs0hwkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6ZEAAQAbYFcCokwvAqJP5g6AISbNVj5cz4W1i UBD//6hwAADcbX1LOIcJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcumVAAEAG0mDAqJML wKiT+YOgCEmzVY+XM+FtYlAQ//+uJAAAMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIz3G19SzqHCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LpmQABABtJf wKiTC8Cok/mDoAhJs1WVSzPhbWJQEP//riQAADIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyM9xtfUs8hwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6Z0AA QAbSXsCokwvAqJP5g6AISbNVmv8z4W1iUBD//64kAAAwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDHcbX1LPocJADwAAAA8AAAAABUXyiUBAAwpAXfcCABFAAAo SRcAAEAGiWPAqJP5wKiTCwhJg6Az4W1is1U6I1AQ///s2AAAAAAAAAAA3G19S0CHCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLpoQABABtgRwKiTC8Cok/mDoAhJs1WgszPhbWJQEP// qHAAANxtfUtDhwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6aUAAQAbSXMCokwvAqJP5 g6AISbNVoLMz4W1iUBD//64kAAAwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDHcbX1LRYcJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcumpAAEAG0lvAqJML wKiT+YOgCEmzVaZnM+FtYlAQ//+uJAAAMDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAx3G19S0iHCQBOAAAATgAAAAAMKQF33AAVF8olAQgARQAAQLprQABABtf2 wKiTC8Cok/mDoAhJs1WsGzPhbWJQEP//qIgAADAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyM9xt fUtRhwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6bEAAQAbYDcCokwvAqJP5g6AISbNV rDMz4W1iUBD//6hwAADcbX1LU4cJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoum1AAEAG 2AzAqJMLwKiT+YOgCEmzVawzM+FtYlAQ//+ocAAA3G19S1SHCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLpuQABABtgLwKiTC8Cok/mDoAhJs1WsMzPhbWJQEP//qHAAANxtfUtWhwkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6b0AAQAbYCsCokwvAqJP5g6AISbNVrDMz4W1i UBD//6hwAADcbX1LW4cJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAounBAAEAG2AnAqJML wKiT+YOgCEmzVawzM+FtYlAQ//+ocAAA3G19S2CHCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLpxQABABtgIwKiTC8Cok/mDoAhJs1WsMzPhbWJQEP//qHAAANxtfUtlhwkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi6ckAAQAbYB8CokwvAqJP5g6AISbNVrDMz4W1iUBD//6hw AADcbX1LaocJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAounNAAEAG2AbAqJMLwKiT+YOg CEmzVawzM+FtYlAQ//+ocAAA3G19S2+HCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLp0 QABABtgFwKiTC8Cok/mDoAhJs1WsMzPhbWJQEP//qHAAANxtfUtzhwkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi6dUAAQAbYBMCokwvAqJP5g6AISbNVrDMz4W1iUBD//6hwAADcbX1L eIcJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAounZAAEAG2APAqJMLwKiT+YOgCEmzVawz M+FtYlAQ//+ocAAA3G19S32HCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLp3QABABtgC wKiTC8Cok/mDoAhJs1WsMzPhbWJQEP//qHAAANxtfUuAhwkAPAAAADwAAAAAFRfKJQEADCkB d9wIAEUAAChJGAAAQAaJYsCok/nAqJMLCEmDoDPhbWKzVUWLUBD//+FwAAAAAAAAAADcbX1L gocJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAounhAAEAG2AHAqJMLwKiT+YOgCEmzVawz M+FtYlAQ//+ocAAA3G19S4aHCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3Lp5QABABtJM wKiTC8Cok/mDoAhJs1WsMzPhbWJQEP//riQAADQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NdxtfUuIhwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6ekAA QAbSS8CokwvAqJP5g6AISbNVsecz4W1iUBD//64kAAA0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDXcbX1Li4cJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc untAAEAG0krAqJMLwKiT+YOgCEmzVbebM+FtYlAQ//+uJAAANDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ13G19S46HCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLp8QABABtf9wKiTC8Cok/mDoAhJs1W9TzPhbWJQEP//qHAAANxtfUuRhwkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi6fUAAQAbX/MCokwvAqJP5g6AISbNVvU8z4W1iUBD//6hw AADcbX1LlocJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoun5AAEAG1/vAqJMLwKiT+YOg CEmzVb1PM+FtYlAQ//+ocAAA3G19S5uHCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLp/ QABABtf6wKiTC8Cok/mDoAhJs1W9TzPhbWJQEP//qHAAANxtfUughwkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi6gEAAQAbX+cCokwvAqJP5g6AISbNVvU8z4W1iUBD//6hwAADcbX1L pIcJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouoFAAEAG1/jAqJMLwKiT+YOgCEmzVb1P M+FtYlAQ//+ocAAA3G19S6mHCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLqCQABABtf3 wKiTC8Cok/mDoAhJs1W9TzPhbWJQEP//qHAAANxtfUuuhwkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi6g0AAQAbX9sCokwvAqJP5g6AISbNVvU8z4W1iUBD//6hwAADcbX1Ls4cJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAouoRAAEAG1/XAqJMLwKiT+YOgCEmzVb1PM+FtYlAQ //+ocAAA3G19S7iHCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLqFQABABtf0wKiTC8Co k/mDoAhJs1W9TzPhbWJQEP//qHAAANxtfUu8hwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi6hkAAQAbX88CokwvAqJP5g6AISbNVvU8z4W1iUBD//6hwAADcbX1LwYcJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAouodAAEAG1/LAqJMLwKiT+YOgCEmzVb1PM+FtYlAQ//+ocAAA 3G19S8eHCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLqIQABABtfxwKiTC8Cok/mDoAhJ s1W9TzPhbWJQEP//qHAAANxtfUvMhwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6iUAA QAbX8MCokwvAqJP5g6AISbNVvU8z4W1iUBD//6hwAADcbX1L0IcJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAouopAAEAG1+/AqJMLwKiT+YOgCEmzVb1PM+FtYlAQ//+ocAAA3G19S9WH CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLqLQABABtfuwKiTC8Cok/mDoAhJs1W9TzPh bWJQEP//qHAAANxtfUvahwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6jEAAQAbX7cCo kwvAqJP5g6AISbNVvU8z4W1iUBD//6hwAADcbX1L34cJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAouo1AAEAG1+zAqJMLwKiT+YOgCEmzVb1PM+FtYlAQ//+ocAAA3G19S+SHCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLqOQABABtfrwKiTC8Cok/mDoAhJs1W9TzPhbWJQEP// qHAAANxtfUvphwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6j0AAQAbX6sCokwvAqJP5 g6AISbNVvU8z4W1iUBD//6hwAADcbX1L7ocJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo upBAAEAG1+nAqJMLwKiT+YOgCEmzVb1PM+FtYlAQ//+ocAAA3G19S/KHCQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLqRQABABtfowKiTC8Cok/mDoAhJs1W9TzPhbWJQEP//qHAAANxt fUv3hwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6kkAAQAbX58CokwvAqJP5g6AISbNV vU8z4W1iUBD//6hwAADcbX1L/IcJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAoupNAAEAG 1+bAqJMLwKiT+YOgCEmzVb1PM+FtYlAQ//+ocAAA3G19S/2HCQA8AAAAPAAAAAAVF8olAQAM KQF33AgARQAAKEkZAABABolhwKiT+cCokwsISYOgM+FtYrNVUPNQEP//1ggAAAAAAAAAANxt fUsCiAkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6lEAAQAbSMcCokwvAqJP5g6AISbNV vU8z4W1iUBD//64kAAAyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjPcbX1LBIgJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcupVAAEAG0jDAqJMLwKiT+YOg CEmzVcMDM+FtYlAQ//+uJAAAMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIz3G19SwaICQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LqWQABABtIvwKiTC8Co k/mDoAhJs1XItzPhbWJQEP//riQAADIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyM9xtfUsIiAkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJGgAAQAaJYMCo k/nAqJMLCEmDoDPhbWKzVVxbUBD//8qgAAAAAAAAAADcbX1LCogJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAoupdAAEAG1+LAqJMLwKiT+YOgCEmzVc5rM+FtYlAQ//+ocAAA3G19Sw2I CQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LqYQABABtItwKiTC8Cok/mDoAhJs1XOazPh bWJQEP//riQAADIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyM9xt fUsQiAkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6mUAAQAbSLMCokwvAqJP5g6AISbNV 1B8z4W1iUBD//64kAAAyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjPcbX1LEogJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuppAAEAG0ivAqJMLwKiT+YOg CEmzVdnTM+FtYlAQ//+uJAAAMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIz3G19SxSICQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEkbAABABolfwKiT+cCo kwsISYOgM+FtYrNVZ8NQEP//vzgAAAAAAAAAANxtfUsViAkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi6m0AAQAbX3sCokwvAqJP5g6AISbNV34cz4W1iUBD//6hwAADcbX1LGYgJAGAA AADqBQAAAAwpAXfcABUXyiUBCABFAAXcupxAAEAG0inAqJMLwKiT+YOgCEmzVd+HM+FtYlAQ //+uJAAAMDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19SxuI CQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LqdQABABtIowKiTC8Cok/mDoAhJs1XlOzPh bWJQEP//riQAADAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMdxt fUsdiAkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6nkAAQAbSJ8CokwvAqJP5g6AISbNV 6u8z4W1iUBD//64kAAAwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDHcbX1LIIgJADwAAAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSRwAAEAGiV7AqJP5wKiTCwhJ g6Az4W1is1VzK1AQ//+z0AAAAAAAAAAA3G19SyGICQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLqfQABABtfawKiTC8Cok/mDoAhJs1XwozPhbWJQEP//qHAAANxtfUsliAkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy6oEAAQAbSJcCokwvAqJP5g6AISbNV8KMz4W1iUBD//64k AAAwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDHcbX1LJ4gJAGAA AADqBQAAAAwpAXfcABUXyiUBCABFAAXcuqFAAEAG0iTAqJMLwKiT+YOgCEmzVfZXM+FtYlAQ //+uJAAAMDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19SymI CQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LqiQABABtIjwKiTC8Cok/mDoAhJs1X8CzPh bWJQEP//riQAADg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4Odxt fUsriAkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJHQAAQAaJXcCok/nAqJMLCEmDoDPh bWKzVX57UBD//6iAAAAAAAAAAADcbX1LLIgJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo uqNAAEAG19bAqJMLwKiT+YOgCEmzVgG/M+FtYlAQ//+ocAAA3G19SzCICQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LqkQABABtIhwKiTC8Cok/mDoAhJs1YBvzPhbWJQEP//riQAADg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OdxtfUsyiAkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy6pUAAQAbSIMCokwvAqJP5g6AISbNWB3Mz4W1iUBD//64k AAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1LNYgJAGAA AADSBQAAAAwpAXfcABUXyiUBCABFAAXEuqZAAEAG0jfAqJMLwKiT+YOgCEmzVg0nM+FtYlAQ //+uDAAAODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg53G19SzeI CQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEkeAABABolcwKiT+cCokwsISYOgM+FtYrNV ieNQEP//nRgAAAAAAAAAANxtfUs4iAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6p0AA QAbX0sCokwvAqJP5g6AISbNWEsMz4W1iUBD//6hwAADcbX1LO4gJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcuqhAAEAG0h3AqJMLwKiT+YOgCEmzVhLDM+FtYlAQ//+uJAAANDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ13G19Sz6ICQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LqpQABABtIcwKiTC8Cok/mDoAhJs1YYdzPhbWJQEP//riQAADQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NdxtfUtAiAkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy6qkAAQAbSG8CokwvAqJP5g6AISbNWHisz4W1iUBD//64k AAAyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjPcbX1LQogJADwA AAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSR8AAEAGiVvAqJP5wKiTCwhJg6Az4W1is1WVS1AQ //+RsAAAAAAAAAAA3G19S0OICQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLqrQABABtfO wKiTC8Cok/mDoAhJs1Yj3zPhbWJQEP//qHAAANxtfUtHiAkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy6rEAAQAbSGcCokwvAqJP5g6AISbNWI98z4W1iUBD//64kAAAyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjPcbX1LSogJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcuq1AAEAG0hjAqJMLwKiT+YOgCEmzVimTM+FtYlAQ//+uJAAAMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz3G19S0yICQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LquQABABtIXwKiTC8Cok/mDoAhJs1YvRzPhbWJQEP//riQAADIz NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyM9xtfUtOiAkAPAAAADwA AAAAFRfKJQEADCkBd9wIAEUAAChJIAAAQAaJWsCok/nAqJMLCEmDoDPhbWKzVaCzUBD//4ZI AAAAAAAAAADcbX1LT4gJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouq9AAEAG18rAqJML wKiT+YOgCEmzVjT7M+FtYlAQ//+ocAAA3G19S1OICQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3LqwQABABtIVwKiTC8Cok/mDoAhJs1Y0+zPhbWJQEP//riQAADIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyM9xtfUtXiAkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy6sUAAQAbSFMCokwvAqJP5g6AISbNWOq8z4W1iUBD//64kAAAwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDHcbX1LWYgJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcurJAAEAG0hPAqJMLwKiT+YOgCEmzVkBjM+FtYlAQ//+uJAAAMDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19S1uICQA8AAAAPAAAAAAV F8olAQAMKQF33AgARQAAKEkhAABABolZwKiT+cCokwsISYOgM+FtYrNVrBtQEP//euAAAAAA AAAAANxtfUtdiAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6s0AAQAbXxsCokwvAqJP5 g6AISbNWRhcz4W1iUBD//6hwAADcbX1LYYgJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc urRAAEAG0hHAqJMLwKiT+YOgCEmzVkYXM+FtYlAQ//+uJAAAMDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19S2OICQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3Lq1QABABtIQwKiTC8Cok/mDoAhJs1ZLyzPhbWJQEP//riQAADAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMdxtfUtliAkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy6tkAAQAbSD8CokwvAqJP5g6AISbNWUX8z4W1iUBD//64kAAAwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDHcbX1Lb4gJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAourdAAEAG18LAqJMLwKiT+YOgCEmzVlczM+FtYlAQ//+ocAAA3G19S3CI CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLq4QABABtfBwKiTC8Cok/mDoAhJs1ZXMzPh bWJQEP//qHAAANxtfUtyiAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6uUAAQAbXwMCo kwvAqJP5g6AISbNWVzMz4W1iUBD//6hwAADcbX1LdYgJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAourpAAEAG17/AqJMLwKiT+YOgCEmzVlczM+FtYlAQ//+ocAAA3G19S3qICQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLq7QABABte+wKiTC8Cok/mDoAhJs1ZXMzPhbWJQEP// qHAAANxtfUuBiAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6vEAAQAbXvcCokwvAqJP5 g6AISbNWVzMz4W1iUBD//6hwAADcbX1LhogJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo ur1AAEAG17zAqJMLwKiT+YOgCEmzVlczM+FtYlAQ//+ocAAA3G19S42ICQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLq+QABABte7wKiTC8Cok/mDoAhJs1ZXMzPhbWJQEP//qHAAANxt fUuTiAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6v0AAQAbXusCokwvAqJP5g6AISbNW VzMz4W1iUBD//6hwAADcbX1LmYgJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAousBAAEAG 17nAqJMLwKiT+YOgCEmzVlczM+FtYlAQ//+ocAAA3G19S5+ICQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLrBQABABte4wKiTC8Cok/mDoAhJs1ZXMzPhbWJQEP//qHAAANxtfUuliAkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi6wkAAQAbXt8CokwvAqJP5g6AISbNWVzMz4W1i UBD//6hwAADcbX1LqogJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAousNAAEAG17bAqJML wKiT+YOgCEmzVlczM+FtYlAQ//+ocAAA3G19S7GICQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLrEQABABte1wKiTC8Cok/mDoAhJs1ZXMzPhbWJQEP//qHAAANxtfUu1iAkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi6xUAAQAbXtMCokwvAqJP5g6AISbNWVzMz4W1iUBD//6hw AADcbX1LuogJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAousZAAEAG17PAqJMLwKiT+YOg CEmzVlczM+FtYlAQ//+ocAAA3G19S7+ICQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLrH QABABteywKiTC8Cok/mDoAhJs1ZXMzPhbWJQEP//qHAAANxtfUvEiAkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi6yEAAQAbXscCokwvAqJP5g6AISbNWVzMz4W1iUBD//6hwAADcbX1L yogJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouslAAEAG17DAqJMLwKiT+YOgCEmzVlcz M+FtYlAQ//+ocAAA3G19S9CICQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLrKQABABtev wKiTC8Cok/mDoAhJs1ZXMzPhbWJQEP//qHAAANxtfUvViAkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi6y0AAQAbXrsCokwvAqJP5g6AISbNWVzMz4W1iUBD//6hwAADcbX1L3IgJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAousxAAEAG163AqJMLwKiT+YOgCEmzVlczM+FtYlAQ //+ocAAA3G19S+GICQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLrNQABABteswKiTC8Co k/mDoAhJs1ZXMzPhbWJQEP//qHAAANxtfUvniAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi6zkAAQAbXq8CokwvAqJP5g6AISbNWVzMz4W1iUBD//6hwAADcbX1L7IgJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAous9AAEAG16rAqJMLwKiT+YOgCEmzVlczM+FtYlAQ//+ocAAA 3G19S/GICQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLrQQABABtepwKiTC8Cok/mDoAhJ s1ZXMzPhbWJQEP//qHAAANxtfUv2iAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi60UAA QAbXqMCokwvAqJP5g6AISbNWVzMz4W1iUBD//6hwAADcbX1L+IgJADwAAAA8AAAAABUXyiUB AAwpAXfcCABFAAAoSSIAAEAGiVjAqJP5wKiTCwhJg6Az4W1is1Wx51AQ//91FAAAAAAAAAAA 3G19S/2ICQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LrSQABABtHzwKiTC8Cok/mDoAhJ s1ZXMzPhbWJQEP//riQAADAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMdxtfUsAiQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy600AAQAbR8sCokwvAqJP5 g6AISbNWXOcz4W1iUBD//64kAAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODncbX1LAokJAE4AAABOAAAAAAwpAXfcABUXyiUBCABFAABAutRAAEAG143AqJML wKiT+YOgCEmzVmKbM+FtYlAQ//+oiAAAODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19SwSJ CQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEkjAABABolXwKiT+cCokwsISYOgM+FtYrNV vU9QEP//aawAAAAAAAAAANxtfUsFiQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi61UAA QAbXpMCokwvAqJP5g6AISbNWYrMz4W1iUBD//6hwAADcbX1LCYkJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcutZAAEAG0e/AqJMLwKiT+YOgCEmzVmKzM+FtYlAQ//+uJAAAMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz3G19SwyJCQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LrXQABABtHuwKiTC8Cok/mDoAhJs1ZoZzPhbWJQEP//riQAADIz NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyM9xtfUsOiQkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy62EAAQAbR7cCokwvAqJP5g6AISbNWbhsz4W1iUBD//64k AAAyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjPcbX1LEIkJADwA AAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSSQAAEAGiVbAqJP5wKiTCwhJg6Az4W1is1XIt1AQ //9eRAAAAAAAAAAA3G19SxKJCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLrZQABABteg wKiTC8Cok/mDoAhJs1ZzzzPhbWJQEP//qHAAANxtfUsWiQkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy62kAAQAbR68CokwvAqJP5g6AISbNWc88z4W1iUBD//64kAAAyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjPcbX1LGIkJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcuttAAEAG0erAqJMLwKiT+YOgCEmzVnmDM+FtYlAQ//+uJAAAMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz3G19SxqJCQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LrcQABABtHpwKiTC8Cok/mDoAhJs1Z/NzPhbWJQEP//riQAADAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMdxtfUsciQkAPAAAADwA AAAAFRfKJQEADCkBd9wIAEUAAChJJQAAQAaJVcCok/nAqJMLCEmDoDPhbWKzVdQfUBD//1Lc AAAAAAAAAADcbX1LHokJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAout1AAEAG15zAqJML wKiT+YOgCEmzVoTrM+FtYlAQ//+ocAAA3G19SyKJCQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3LreQABABtHnwKiTC8Cok/mDoAhJs1aE6zPhbWJQEP//riQAADAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMdxtfUskiQkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy630AAQAbR5sCokwvAqJP5g6AISbNWip8z4W1iUBD//64kAAAwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDHcbX1LJ4kJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcuuBAAEAG0eXAqJMLwKiT+YOgCEmzVpBTM+FtYlAQ//+uJAAAMDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19SyiJCQA8AAAAPAAAAAAV F8olAQAMKQF33AgARQAAKEkmAABABolUwKiT+cCokwsISYOgM+FtYrNV34dQEP//R3QAAAAA AAAAANxtfUsqiQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi64UAAQAbXmMCokwvAqJP5 g6AISbNWlgcz4W1iUBD//6hwAADcbX1LLokJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc uuJAAEAG0ePAqJMLwKiT+YOgCEmzVpYHM+FtYlAQ//+uJAAAMDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx3G19SzGJCQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3LrjQABABtHiwKiTC8Cok/mDoAhJs1abuzPhbWJQEP//riQAADg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OdxtfUsziQkAYAAAAOoFAAAADCkBd9wAFRfK JQEIAEUABdy65EAAQAbR4cCokwvAqJP5g6AISbNWoW8z4W1iUBD//64kAAA4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1LNYkJADwAAAA8AAAAABUXyiUB AAwpAXfcCABFAAAoSScAAEAGiVPAqJP5wKiTCwhJg6Az4W1is1Xq71AQ//88DAAAAAAAAAAA 3G19SzaJCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLrlQABABteUwKiTC8Cok/mDoAhJ s1anIzPhbWJQEP//qHAAANxtfUs6iQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy65kAA QAbR38CokwvAqJP5g6AISbNWpyMz4W1iUBD//64kAAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1LPYkJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc uudAAEAG0d7AqJMLwKiT+YOgCEmzVqzXM+FtYlAQ//+uJAAAODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg53G19Sz+JCQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3LroQABABtHdwKiTC8Cok/mDoAhJs1ayizPhbWJQEP//riQAADg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OdxtfUtBiQkAPAAAADwAAAAAFRfKJQEADCkB d9wIAEUAAChJKAAAQAaJUsCok/nAqJMLCEmDoDPhbWKzVfZXUBD//zCkAAAAAAAAAADcbX1L QokJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouulAAEAG15DAqJMLwKiT+YOgCEmzVrg/ M+FtYlAQ//+ocAAA3G19S0aJCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LrqQABABtHb wKiTC8Cok/mDoAhJs1a4PzPhbWJQEP//riQAADg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1Njc4OdxtfUtJiQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy660AA QAbR2sCokwvAqJP5g6AISbNWvfMz4W1iUBD//64kAAA2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1NjfcbX1LS4kJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc uuxAAEAG0dnAqJMLwKiT+YOgCEmzVsOnM+FtYlAQ//+uJAAANjc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY33G19S02JCQA8AAAAPAAAAAAVF8olAQAMKQF33AgA RQAAKEkpAABABolRwKiT+cCokwsISYOgM+FtYrNWAb9QEP//JTwAAAAAAAAAANxtfUtOiQkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi67UAAQAbXjMCokwvAqJP5g6AISbNWyVsz4W1i UBD//6hwAADcbX1LUokJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuu5AAEAG0dfAqJML wKiT+YOgCEmzVslbM+FtYlAQ//+uJAAANjc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY33G19S1WJCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LrvQABABtHW wKiTC8Cok/mDoAhJs1bPDzPhbWJQEP//riQAADY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2N9xtfUtXiQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy68EAA QAbR1cCokwvAqJP5g6AISbNW1MMz4W1iUBD//64kAAA2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1NjfcbX1LWYkJADwAAAA8AAAAABUXyiUBAAwpAXfcCABFAAAo SSoAAEAGiVDAqJP5wKiTCwhJg6Az4W1is1YNJ1AQ//8Z1AAAAAAAAAAA3G19S1qJCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLrxQABABteIwKiTC8Cok/mDoAhJs1badzPhbWJQEP// qHAAANxtfUteiQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy68kAAQAbR08CokwvAqJP5 g6AISbNW2ncz4W1iUBD//64kAAAAAAABAAAISQAAAAAAAAAA///8GDQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDXcbX1LYIkJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuvNAAEAG0dLAqJML wKiT+YOgCEmzVuArM+FtYlAQ//+uJAAANDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ13G19S2KJCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3Lr0QABABtHR wKiTC8Cok/mDoAhJs1bl3zPhbWJQEP//riQAADQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NdxtfUtkiQkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJKwAA QAaJT8Cok/nAqJMLCEmDoDPhbWKzVhh3UBD//w6EAAAAAAAAAADcbX1LZokJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAouvVAAEAG14TAqJMLwKiT+YOgCEmzVuuTM+FtYlAQ//+ocAAA 3G19S2mJCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3Lr2QABABtHPwKiTC8Cok/mDoAhJ s1brkzPhbWJQEP//riQAADQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NdxtfUtriQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy690AAQAbRzsCokwvAqJP5 g6AISbNW8Ucz4W1iUBD//64kAAA0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDXcbX1LbYkJAGAAAADSBQAAAAwpAXfcABUXyiUBCABFAAXEuvhAAEAG0eXAqJML wKiT+YOgCEmzVvb7M+FtYlAQ//+uDAAANDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ13G19S2+JCQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEksAABABolO wKiT+cCokwsISYOgM+FtYrNWI99QEP//AxwAAAAAAAAAANxtfUtxiQkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi6+UAAQAbXgMCokwvAqJP5g6AISbNW/Jcz4W1iUBD//6hwAADcbX1L dIkJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuvpAAEAG0cvAqJMLwKiT+YOgCEmzVvyX M+FtYlAQ//+uJAAAODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 3G19S3eJCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3Lr7QABABtHKwKiTC8Cok/mDoAhJ s1cCSzPhbWJQEP//riQAADg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OdxtfUt5iQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy6/EAAQAbRycCokwvAqJP5 g6AISbNXB/8z4W1iUBD//64kAAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODncbX1Lf4kJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouv1AAEAG13zAqJML wKiT+YOgCEmzVw2zM+FtYlAQ//+ocAAA3G19S4GJCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLr+QABABtd7wKiTC8Cok/mDoAhJs1cNszPhbWJQEP//qHAAANxtfUuDiQkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi6/0AAQAbXesCokwvAqJP5g6AISbNXDbMz4W1iUBD//6hw AADcbX1LiYkJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouwBAAEAG13nAqJMLwKiT+YOg CEmzVw2zM+FtYlAQ//+ocAAA3G19S46JCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLsB QABABtd4wKiTC8Cok/mDoAhJs1cNszPhbWJQEP//qHAAANxtfUuSiQkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi7AkAAQAbXd8CokwvAqJP5g6AISbNXDbMz4W1iUBD//6hwAADcbX1L mIkJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouwNAAEAG13bAqJMLwKiT+YOgCEmzVw2z M+FtYlAQ//+ocAAA3G19S52JCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLsEQABABtd1 wKiTC8Cok/mDoAhJs1cNszPhbWJQEP//qHAAANxtfUuiiQkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi7BUAAQAbXdMCokwvAqJP5g6AISbNXDbMz4W1iUBD//6hwAADcbX1Lp4kJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAouwZAAEAG13PAqJMLwKiT+YOgCEmzVw2zM+FtYlAQ //+ocAAA3G19S6yJCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLsHQABABtdywKiTC8Co k/mDoAhJs1cNszPhbWJQEP//qHAAANxtfUuyiQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi7CEAAQAbXccCokwvAqJP5g6AISbNXDbMz4W1iUBD//6hwAADcbX1Lt4kJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAouwlAAEAG13DAqJMLwKiT+YOgCEmzVw2zM+FtYlAQ//+ocAAA 3G19S7yJCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLsKQABABtdvwKiTC8Cok/mDoAhJ s1cNszPhbWJQEP//qHAAANxtfUvAiQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7C0AA QAbXbsCokwvAqJP5g6AISbNXDbMz4W1iUBD//6hwAADcbX1LxYkJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAouwxAAEAG123AqJMLwKiT+YOgCEmzVw2zM+FtYlAQ//+ocAAA3G19S8mJ CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLsNQABABtdswKiTC8Cok/mDoAhJs1cNszPh bWJQEP//qHAAANxtfUvNiQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7DkAAQAbXa8Co kwvAqJP5g6AISbNXDbMz4W1iUBD//6hwAADcbX1L0YkJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAouw9AAEAG12rAqJMLwKiT+YOgCEmzVw2zM+FtYlAQ//+ocAAA3G19S9aJCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLsQQABABtdpwKiTC8Cok/mDoAhJs1cNszPhbWJQEP// qHAAANxtfUvaiQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7EUAAQAbXaMCokwvAqJP5 g6AISbNXDbMz4W1iUBD//6hwAADcbX1L3okJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo uxJAAEAG12fAqJMLwKiT+YOgCEmzVw2zM+FtYlAQ//+ocAAA3G19S+SJCQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLsTQABABtdmwKiTC8Cok/mDoAhJs1cNszPhbWJQEP//qHAAANxt fUvpiQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7FEAAQAbXZcCokwvAqJP5g6AISbNX DbMz4W1iUBD//6hwAADcbX1L7okJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouxVAAEAG 12TAqJMLwKiT+YOgCEmzVw2zM+FtYlAQ//+ocAAA3G19S/GJCQA8AAAAPAAAAAAVF8olAQAM KQF33AgARQAAKEktAABABolNwKiT+cCokwsISYOgM+FtYrNWL0dQEP//97MAAAAAAAAAANxt fUvziQkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7FkAAQAbXY8CokwvAqJP5g6AISbNX DbMz4W1iUBD//6hwAADcbX1L94kJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuxdAAEAG 0a7AqJMLwKiT+YOgCEmzVw2zM+FtYlAQ//+uJAAAODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDU2Nzg53G19S/qJCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LsY QABABtGtwKiTC8Cok/mDoAhJs1cTZzPhbWJQEP//riQAADg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OdxtfUv8iQkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUA Bdy7GUAAQAbRrMCokwvAqJP5g6AISbNXGRsz4W1iUBD//64kAAA4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1L/okJADwAAAA8AAAAABUXyiUBAAwpAXfc CABFAAAoSS4AAEAGiUzAqJP5wKiTCwhJg6Az4W1is1Y6r1AQ///sSwAAAAAAAAAA3G19S/+J CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLsaQABABtdfwKiTC8Cok/mDoAhJs1cezzPh bWJQEP//qHAAANxtfUsDigkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7G0AAQAbRqsCo kwvAqJP5g6AISbNXHs8z4W1iUBD//64kAAA2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1NjfcbX1LBYoJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuxxAAEAG 0anAqJMLwKiT+YOgCEmzVySDM+FtYlAQ//+uJAAANjc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY33G19SweKCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3Lsd QABABtGowKiTC8Cok/mDoAhJs1cqNzPhbWJQEP//riQAADY3ODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2N9xtfUsJigkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUA AChJLwAAQAaJS8Cok/nAqJMLCEmDoDPhbWKzVkYXUBD//+DjAAAAAAAAAADcbX1LCooJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAoux5AAEAG11vAqJMLwKiT+YOgCEmzVy/rM+FtYlAQ //+ocAAA3G19Sw6KCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LsfQABABtGmwKiTC8Co k/mDoAhJs1cv6zPhbWJQEP//riQAADY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2N9xtfUsQigkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7IEAAQAbRpcCo kwvAqJP5g6AISbNXNZ8z4W1iUBD//64kAAA2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz NDU2Nzg5MDEyMzQ1NjfcbX1LEooJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuyFAAEAG 0aTAqJMLwKiT+YOgCEmzVztTM+FtYlAQ//+uJAAANDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3 ODkwMTIzNDU2Nzg5MDEyMzQ13G19SxSKCQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEkw AABABolKwKiT+cCokwsISYOgM+FtYrNWUX9QEP//1XsAAAAAAAAAANxtfUsWigkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi7IkAAQAbXV8CokwvAqJP5g6AISbNXQQcz4W1iUBD//6hw AADcbX1LGYoJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuyNAAEAG0aLAqJMLwKiT+YOg CEmzV0EHM+FtYlAQ//+uJAAANDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ13G19SxyKCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LskQABABtGhwKiTC8Co k/mDoAhJs1dGuzPhbWJQEP//riQAADQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NdxtfUseigkAYAAAAEUFAAAADCkBd9wAFRfKJQEIAEUABTe7JUAAQAbSRcCo kwvAqJP5g6AISbNXTG8z4W1iUBD//61/AAA0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAx MjM0NTY3ODkwMTIzNDXcbX1LIYoJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouyZAAEAG 11PAqJMLwKiT+YOgCEmzV1F+M+FtYlAQ//+ocAAA3G19SySKCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLsnQABABtdSwKiTC8Cok/mDoAhJs1dRfjPhbWJQEP//qHAAANxtfUspigkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7KEAAQAbXUcCokwvAqJP5g6AISbNXUX4z4W1i UBD//6hwAADcbX1LL4oJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouylAAEAG11DAqJML wKiT+YOgCEmzV1F+M+FtYlAQ//+ocAAA3G19SzOKCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLsqQABABtdPwKiTC8Cok/mDoAhJs1dRfjPhbWJQEP//qHAAANxtfUs5igkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi7K0AAQAbXTsCokwvAqJP5g6AISbNXUX4z4W1iUBD//6hw AADcbX1LPooJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouyxAAEAG103AqJMLwKiT+YOg CEmzV1F+M+FtYlAQ//+ocAAA3G19S0OKCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLst QABABtdMwKiTC8Cok/mDoAhJs1dRfjPhbWJQEP//qHAAANxtfUtIigkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi7LkAAQAbXS8CokwvAqJP5g6AISbNXUX4z4W1iUBD//6hwAADcbX1L TYoJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAouy9AAEAG10rAqJMLwKiT+YOgCEmzV1F+ M+FtYlAQ//+ocAAA3G19S1KKCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLswQABABtdJ wKiTC8Cok/mDoAhJs1dRfjPhbWJQEP//qHAAANxtfUtXigkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi7MUAAQAbXSMCokwvAqJP5g6AISbNXUX4z4W1iUBD//6hwAADcbX1LXIoJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAouzJAAEAG10fAqJMLwKiT+YOgCEmzV1F+M+FtYlAQ //+ocAAA3G19S2OKCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLszQABABtdGwKiTC8Co k/mDoAhJs1dRfjPhbWJQEP//qHAAANxtfUtoigkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi7NEAAQAbXRcCokwvAqJP5g6AISbNXUX4z4W1iUBD//6hwAADcbX1LbooJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAouzVAAEAG10TAqJMLwKiT+YOgCEmzV1F+M+FtYlAQ//+ocAAA 3G19S2+KCQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEkxAABABolJwKiT+cCokwsISYOg M+FtYrNWXOdQEP//yhMAAAAAAAAAANxtfUt0igkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUA Bdy7NkAAQAbRj8CokwvAqJP5g6AISbNXUX4z4W1iUBD//64kAAA5MDEyMzQ1Njc4OTAxMjM0 NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTDcbX1Ld4oJAGAAAADqBQAAAAwpAXfcABUXyiUB CABFAAXcuzdAAEAG0Y7AqJMLwKiT+YOgCEmzV1cyM+FtYlAQ//+uJAAAOTAxMjM0NTY3ODkw MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw3G19S3mKCQA8AAAAPAAAAAAVF8olAQAM KQF33AgARQAAKEkyAABABolIwKiT+cCokwsISYOgM+FtYrNWYrNQEP//xEcAAAAAAAAAANxt fUt6igkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7OEAAQAbXQcCokwvAqJP5g6AISbNX XOYz4W1iUBD//6hwAADcbX1LfYoJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcuzlAAEAG 0YzAqJMLwKiT+YOgCEmzV1zmM+FtYlAQ//+uJAAANzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw MTIzNDU2Nzg5MDEyMzQ1Njc43G19S4CKCQBOAAAATgAAAAAMKQF33AAVF8olAQgARQAAQLs6 QABABtcnwKiTC8Cok/mDoAhJs1dimjPhbWJQEP//qIgAADc4OTAxMjM0NTY3ODkwMTIzNDU2 Nzg5MNxtfUuBigkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJMwAAQAaJR8Cok/nAqJML CEmDoDPhbWKzVm4bUBD//7jfAAAAAAAAAADcbX1Lg4oJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAouztAAEAG1z7AqJMLwKiT+YOgCEmzV2KyM+FtYlAQ//+ocAAA3G19S4eKCQBgAAAA 6gUAAAAMKQF33AAVF8olAQgARQAF3Ls8QABABtGJwKiTC8Cok/mDoAhJs1disjPhbWJQEP// riQAADEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMtxtfUuJigkA YAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7PUAAQAbRiMCokwvAqJP5g6AISbNXaGYz4W1i UBD//64kAAAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTLcbX1L i4oJADwAAAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSTQAAEAGiUbAqJP5wKiTCwhJg6Az4W1i s1Z5g1AQ//+tdwAAAAAAAAAA3G19S4yKCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLs+ QABABtc7wKiTC8Cok/mDoAhJs1duGjPhbWJQEP//qHAAANxtfUuPigkAYAAAAOoFAAAADCkB d9wAFRfKJQEIAEUABdy7P0AAQAbRhsCokwvAqJP5g6AISbNXbhoz4W1iUBD//64kAAAxMjM0 NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTLcbX1LkooJAGAAAADqBQAA AAwpAXfcABUXyiUBCABFAAXcu0BAAEAG0YXAqJMLwKiT+YOgCEmzV3POM+FtYlAQ//+uJAAA MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEy3G19S5SKCQA8AAAA PAAAAAAVF8olAQAMKQF33AgARQAAKEk1AABABolFwKiT+cCokwsISYOgM+FtYrNWhOtQEP// og8AAAAAAAAAANxtfUuVigkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7QUAAQAbXOMCo kwvAqJP5g6AISbNXeYIz4W1iUBD//6hwAADcbX1LmYoJAGAAAADqBQAAAAwpAXfcABUXyiUB CABFAAXcu0JAAEAG0YPAqJMLwKiT+YOgCEmzV3mCM+FtYlAQ//+uJAAAMTIzNDU2Nzg5MDEy MzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEy3G19S5uKCQBgAAAA6gUAAAAMKQF33AAV F8olAQgARQAF3LtDQABABtGCwKiTC8Cok/mDoAhJs1d/NjPhbWJQEP//riQAADkwMTIzNDU2 Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MNxtfUudigkAPAAAADwAAAAAFRfK JQEADCkBd9wIAEUAAChJNgAAQAaJRMCok/nAqJMLCEmDoDPhbWKzVpBTUBD//5anAAAAAAAA AADcbX1LnooJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou0RAAEAG1zXAqJMLwKiT+YOg CEmzV4TqM+FtYlAQ//+ocAAA3G19S6KKCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LtF QABABtGAwKiTC8Cok/mDoAhJs1eE6jPhbWJQEP//riQAADkwMTIzNDU2Nzg5MDEyMzQ1Njc4 OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MNxtfUukigkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUA Bdy7RkAAQAbRf8CokwvAqJP5g6AISbNXip4z4W1iUBD//64kAAA5MDEyMzQ1Njc4OTAxMjM0 NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTDcbX1LpooJADwAAAA8AAAAABUXyiUBAAwpAXfc CABFAAAoSTcAAEAGiUPAqJP5wKiTCwhJg6Az4W1is1abu1AQ//+LPwAAAAAAAAAA3G19S6eK CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLtHQABABtcywKiTC8Cok/mDoAhJs1eQUjPh bWJQEP//qHAAANxtfUurigkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7SEAAQAbRfcCo kwvAqJP5g6AISbNXkFIz4W1iUBD//64kAAA5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2 Nzg5MDEyMzQ1Njc4OTDcbX1LrYoJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcu0lAAEAG 0XzAqJMLwKiT+YOgCEmzV5YGM+FtYlAQ//+uJAAAOTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEy MzQ1Njc4OTAxMjM0NTY3ODkw3G19S6+KCQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKEk4 AABABolCwKiT+cCokwsISYOgM+FtYrNWpyNQEP//f9cAAAAAAAAAANxtfUuxigkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi7SkAAQAbXL8CokwvAqJP5g6AISbNXm7oz4W1iUBD//6hw AADcbX1LtIoJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcu0tAAEAG0XrAqJMLwKiT+YOg CEmzV5u6M+FtYlAQ//+uJAAANzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEy MzQ1Njc43G19S7aKCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LtMQABABtF5wKiTC8Co k/mDoAhJs1ehbjPhbWJQEP//riQAADc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4 OTAxMjM0NTY3ONxtfUu4igkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJOQAAQAaJQcCo k/nAqJMLCEmDoDPhbWKzVrKLUBD//3RvAAAAAAAAAADcbX1LuYoJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAou01AAEAG1yzAqJMLwKiT+YOgCEmzV6ciM+FtYlAQ//+ocAAA3G19S72K CQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LtOQABABtF3wKiTC8Cok/mDoAhJs1enIjPh bWJQEP//riQAADc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ONxt fUvAigkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7T0AAQAbRdsCokwvAqJP5g6AISbNX rNYz4W1iUBD//64kAAA3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2 NzjcbX1LwYoJADwAAAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSToAAEAGiUDAqJP5wKiTCwhJ g6Az4W1is1a981AQ//9pBwAAAAAAAAAA3G19S8OKCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLtQQABABtcpwKiTC8Cok/mDoAhJs1eyijPhbWJQEP//qHAAANxtfUvHigkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy7UUAAQAbRdMCokwvAqJP5g6AISbNXsooz4W1iUBD//64k AAA3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2NzjcbX1LyYoJAGAA AADqBQAAAAwpAXfcABUXyiUBCABFAAXcu1JAAEAG0XPAqJMLwKiT+YOgCEmzV7g+M+FtYlAQ //+uJAAANzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc43G19S86K CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLtTQABABtcmwKiTC8Cok/mDoAhJs1e98jPh bWJQEP//qHAAANxtfUvPigkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7VEAAQAbXJcCo kwvAqJP5g6AISbNXvfIz4W1iUBD//6hwAADcbX1L1YoJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAou1VAAEAG1yTAqJMLwKiT+YOgCEmzV73yM+FtYlAQ//+ocAAA3G19S9mKCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLtWQABABtcjwKiTC8Cok/mDoAhJs1e98jPhbWJQEP// qHAAANxtfUvfigkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7V0AAQAbXIsCokwvAqJP5 g6AISbNXvfIz4W1iUBD//6hwAADcbX1L5IoJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo u1hAAEAG1yHAqJMLwKiT+YOgCEmzV73yM+FtYlAQ//+ocAAA3G19S+mKCQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLtZQABABtcgwKiTC8Cok/mDoAhJs1e98jPhbWJQEP//qHAAANxt fUvvigkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7WkAAQAbXH8CokwvAqJP5g6AISbNX vfIz4W1iUBD//6hwAADcbX1L84oJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou1tAAEAG 1x7AqJMLwKiT+YOgCEmzV73yM+FtYlAQ//+ocAAA3G19S/iKCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLtcQABABtcdwKiTC8Cok/mDoAhJs1e98jPhbWJQEP//qHAAANxtfUv9igkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7XUAAQAbXHMCokwvAqJP5g6AISbNXvfIz4W1i UBD//6hwAADcbX1LAosJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou15AAEAG1xvAqJML wKiT+YOgCEmzV73yM+FtYlAQ//+ocAAA3G19SweLCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLtfQABABtcawKiTC8Cok/mDoAhJs1e98jPhbWJQEP//qHAAANxtfUsMiwkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi7YEAAQAbXGcCokwvAqJP5g6AISbNXvfIz4W1iUBD//6hw AADcbX1LEYsJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou2FAAEAG1xjAqJMLwKiT+YOg CEmzV73yM+FtYlAQ//+ocAAA3G19SxaLCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLti QABABtcXwKiTC8Cok/mDoAhJs1e98jPhbWJQEP//qHAAANxtfUsbiwkANgAAADYAAAAADCkB d9wAFRfKJQEIAEUAACi7Y0AAQAbXFsCokwvAqJP5g6AISbNXvfIz4W1iUBD//6hwAADcbX1L IYsJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou2RAAEAG1xXAqJMLwKiT+YOgCEmzV73y M+FtYlAQ//+ocAAA3G19SyaLCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLtlQABABtcU wKiTC8Cok/mDoAhJs1e98jPhbWJQEP//qHAAANxtfUsriwkANgAAADYAAAAADCkBd9wAFRfK JQEIAEUAACi7ZkAAQAbXE8CokwvAqJP5g6AISbNXvfIz4W1iUBD//6hwAADcbX1LMIsJADYA AAA2AAAAAAwpAXfcABUXyiUBCABFAAAou2dAAEAG1xLAqJMLwKiT+YOgCEmzV73yM+FtYlAQ //+ocAAA3G19SzWLCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLtoQABABtcRwKiTC8Co k/mDoAhJs1e98jPhbWJQEP//qHAAANxtfUs6iwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUA ACi7aUAAQAbXEMCokwvAqJP5g6AISbNXvfIz4W1iUBD//6hwAADcbX1LP4sJADYAAAA2AAAA AAwpAXfcABUXyiUBCABFAAAou2pAAEAG1w/AqJMLwKiT+YOgCEmzV73yM+FtYlAQ//+ocAAA 3G19S0SLCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLtrQABABtcOwKiTC8Cok/mDoAhJ s1e98jPhbWJQEP//qHAAANxtfUtJiwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7bEAA QAbXDcCokwvAqJP5g6AISbNXvfIz4W1iUBD//6hwAADcbX1LTosJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAou21AAEAG1wzAqJMLwKiT+YOgCEmzV73yM+FtYlAQ//+ocAAA3G19S1OL CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLtuQABABtcLwKiTC8Cok/mDoAhJs1e98jPh bWJQEP//qHAAANxtfUtYiwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7b0AAQAbXCsCo kwvAqJP5g6AISbNXvfIz4W1iUBD//6hwAADcbX1LXYsJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAou3BAAEAG1wnAqJMLwKiT+YOgCEmzV73yM+FtYlAQ//+ocAAA3G19S2KLCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLtxQABABtcIwKiTC8Cok/mDoAhJs1e98jPhbWJQEP// qHAAANxtfUtniwkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJOwAAQAaJP8Cok/nAqJML CEmDoDPhbWKzVslbUBD//12fAAAAAAAAAADcbX1LaYsJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAou3JAAEAG1wfAqJMLwKiT+YOgCEmzV73yM+FtYlAQ//+ocAAA3G19S22LCQBgAAAA 6gUAAAAMKQF33AAVF8olAQgARQAF3LtzQABABtFSwKiTC8Cok/mDoAhJs1e98jPhbWJQEP// riQAADU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1NtxtfUtviwkA YAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7dEAAQAbRUcCokwvAqJP5g6AISbNXw6Yz4W1i UBD//64kAAA1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTbcbX1L cYsJADwAAAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSTwAAEAGiT7AqJP5wKiTCwhJg6Az4W1i s1bUw1AQ//9SNwAAAAAAAAAA3G19S3KLCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLt1 QABABtcEwKiTC8Cok/mDoAhJs1fJWjPhbWJQEP//qHAAANxtfUt2iwkAYAAAAOoFAAAADCkB d9wAFRfKJQEIAEUABdy7dkAAQAbRT8CokwvAqJP5g6AISbNXyVoz4W1iUBD//64kAAA1Njc4 OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTbcbX1LeIsJAGAAAADqBQAA AAwpAXfcABUXyiUBCABFAAXcu3dAAEAG0U7AqJMLwKiT+YOgCEmzV88OM+FtYlAQ//+uJAAA NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU23G19S3qLCQA8AAAA PAAAAAAVF8olAQAMKQF33AgARQAAKEk9AABABok9wKiT+cCokwsISYOgM+FtYrNW4CtQEP// Rs8AAAAAAAAAANxtfUt8iwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7eEAAQAbXAcCo kwvAqJP5g6AISbNX1MIz4W1iUBD//6hwAADcbX1Lf4sJAGAAAADqBQAAAAwpAXfcABUXyiUB CABFAAXcu3lAAEAG0UzAqJMLwKiT+YOgCEmzV9TCM+FtYlAQ//+uJAAANTY3ODkwMTIzNDU2 Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU23G19S4GLCQBgAAAA6gUAAAAMKQF33AAV F8olAQgARQAF3Lt6QABABtFLwKiTC8Cok/mDoAhJs1fadjPhbWJQEP//riQAAAAAAAABAAAI SQAAAAAAAAAA///8GDQ1Njc4OTAxMjM0NTY3ODkwMTIzNNxtfUuDiwkAPAAAADwAAAAAFRfK JQEADCkBd9wIAEUAAChJPgAAQAaJPMCok/nAqJMLCEmDoDPhbWKzVuuTUBD//ztnAAAAAAAA AADcbX1LhYsJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou3tAAEAG1v7AqJMLwKiT+YOg CEmzV+AqM+FtYlAQ//+ocAAA3G19S4iLCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3Lt8 QABABtFJwKiTC8Cok/mDoAhJs1fgKjPhbWJQEP//riQAADM0NTY3ODkwMTIzNDU2Nzg5MDEy MzQ1Njc4OTAxMjM0NTY3ODkwMTIzNNxtfUuLiwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUA Bdy7fUAAQAbRSMCokwvAqJP5g6AISbNX5d4z4W1iUBD//64kAAAzNDU2Nzg5MDEyMzQ1Njc4 OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzTcbX1LjYsJADwAAAA8AAAAABUXyiUBAAwpAXfc CABFAAAoST8AAEAGiTvAqJP5wKiTCwhJg6Az4W1is1b2+1AQ//8v/wAAAAAAAAAA3G19S4+L CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLt+QABABtb7wKiTC8Cok/mDoAhJs1frkjPh bWJQEP//qHAAANxtfUuSiwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7f0AAQAbRRsCo kwvAqJP5g6AISbNX65Iz4W1iUBD//64kAAAzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw MTIzNDU2Nzg5MDEyMzTcbX1LlIsJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcu4BAAEAG 0UXAqJMLwKiT+YOgCEmzV/FGM+FtYlAQ//+uJAAAMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2 Nzg5MDEyMzQ1Njc4OTAxMjM03G19S5aLCQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKElA AABABok6wKiT+cCokwsISYOgM+FtYrNXAktQEP//JK8AAAAAAAAAANxtfUuXiwkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi7gUAAQAbW+MCokwvAqJP5g6AISbNX9voz4W1iUBD//6hw AADcbX1Lm4sJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcu4JAAEAG0UPAqJMLwKiT+YOg CEmzV/b6M+FtYlAQ//+uJAAAMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4 OTAxMjM03G19S52LCQBgAAAA0gUAAAAMKQF33AAVF8olAQgARQAFxLuDQABABtFawKiTC8Co k/mDoAhJs1f8rjPhbWJQEP//rgwAADEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEy MzQ1Njc4OTAxMtxtfUuiiwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7hEAAQAbW9cCo kwvAqJP5g6AISbNYAkoz4W1iUBD//6hwAADcbX1LpIsJADYAAAA2AAAAAAwpAXfcABUXyiUB CABFAAAou4VAAEAG1vTAqJMLwKiT+YOgCEmzWAJKM+FtYlAQ//+ocAAA3G19S6mLCQA2AAAA NgAAAAAMKQF33AAVF8olAQgARQAAKLuGQABABtbzwKiTC8Cok/mDoAhJs1gCSjPhbWJQEP// qHAAANxtfUuuiwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7h0AAQAbW8sCokwvAqJP5 g6AISbNYAkoz4W1iUBD//6hwAADcbX1LsosJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAo u4hAAEAG1vHAqJMLwKiT+YOgCEmzWAJKM+FtYlAQ//+ocAAA3G19S7aLCQA2AAAANgAAAAAM KQF33AAVF8olAQgARQAAKLuJQABABtbwwKiTC8Cok/mDoAhJs1gCSjPhbWJQEP//qHAAANxt fUu7iwkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7ikAAQAbW78CokwvAqJP5g6AISbNY Akoz4W1iUBD//6hwAADcbX1Lv4sJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou4tAAEAG 1u7AqJMLwKiT+YOgCEmzWAJKM+FtYlAQ//+ocAAA3G19S8SLCQA2AAAANgAAAAAMKQF33AAV F8olAQgARQAAKLuMQABABtbtwKiTC8Cok/mDoAhJs1gCSjPhbWJQEP//qHAAANxtfUvIiwkA NgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7jUAAQAbW7MCokwvAqJP5g6AISbNYAkoz4W1i UBD//6hwAADcbX1LzYsJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou45AAEAG1uvAqJML wKiT+YOgCEmzWAJKM+FtYlAQ//+ocAAA3G19S9KLCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLuPQABABtbqwKiTC8Cok/mDoAhJs1gCSjPhbWJQEP//qHAAANxtfUvXiwkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi7kEAAQAbW6cCokwvAqJP5g6AISbNYAkoz4W1iUBD//6hw AADcbX1L3IsJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou5FAAEAG1ujAqJMLwKiT+YOg CEmzWAJKM+FtYlAQ//+ocAAA3G19S+GLCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLuS QABABtbnwKiTC8Cok/mDoAhJs1gCSjPhbWJQEP//qHAAANxtfUvliwkAPAAAADwAAAAAFRfK JQEADCkBd9wIAEUAAChJQQAAQAaJOcCok/nAqJMLCEmDoDPhbWKzVw2zUBD//xlHAAAAAAAA AADcbX1L5osJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou5NAAEAG1ubAqJMLwKiT+YOg CEmzWAJKM+FtYlAQ//+ocAAA3G19S+qLCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LuU QABABtExwKiTC8Cok/mDoAhJs1gCSjPhbWJQEP//riQAADc4OTAxMjM0NTY3ODkwMTIzNDU2 Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ONxtfUvtiwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUA Bdy7lUAAQAbRMMCokwvAqJP5g6AISbNYB/4z4W1iUBD//64kAAA3ODkwMTIzNDU2Nzg5MDEy MzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2NzjcbX1L74sJADwAAAA8AAAAABUXyiUBAAwpAXfc CABFAAAoSUIAAEAGiTjAqJP5wKiTCwhJg6Az4W1is1cZG1AQ//8N3wAAAAAAAAAA3G19S/CL CQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLuWQABABtbjwKiTC8Cok/mDoAhJs1gNsjPh bWJQEP//qHAAANxtfUvziwkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7l0AAQAbRLsCo kwvAqJP5g6AISbNYDbIz4W1iUBD//64kAAA3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0 NTY3ODkwMTIzNDU2NzjcbX1L9osJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcu5hAAEAG 0S3AqJMLwKiT+YOgCEmzWBNmM+FtYlAQ//+uJAAANzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw MTIzNDU2Nzg5MDEyMzQ1Njc43G19S/iLCQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKElD AABABok3wKiT+cCokwsISYOgM+FtYrNXJINQEP//AncAAAAAAAAAANxtfUv5iwkANgAAADYA AAAADCkBd9wAFRfKJQEIAEUAACi7mUAAQAbW4MCokwvAqJP5g6AISbNYGRoz4W1iUBD//6hw AADcbX1L/YsJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXcu5pAAEAG0SvAqJMLwKiT+YOg CEmzWBkaM+FtYlAQ//+uJAAANzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEy MzQ1Njc43G19S/+LCQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LubQABABtEqwKiTC8Co k/mDoAhJs1gezjPhbWJQEP//riQAADU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2 Nzg5MDEyMzQ1NtxtfUsBjAkAPAAAADwAAAAAFRfKJQEADCkBd9wIAEUAAChJRAAAQAaJNsCo k/nAqJMLCEmDoDPhbWKzVy/rUBD///cOAAAAAAAAAADcbX1LAowJADYAAAA2AAAAAAwpAXfc ABUXyiUBCABFAAAou5xAAEAG1t3AqJMLwKiT+YOgCEmzWCSCM+FtYlAQ//+ocAAA3G19SwaM CQBgAAAA6gUAAAAMKQF33AAVF8olAQgARQAF3LudQABABtEowKiTC8Cok/mDoAhJs1gkgjPh bWJQEP//riQAADU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Ntxt fUsIjAkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7nkAAQAbRJ8CokwvAqJP5g6AISbNY KjYz4W1iUBD//64kAAA1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0 NTbcbX1LCowJADwAAAA8AAAAABUXyiUBAAwpAXfcCABFAAAoSUUAAEAGiTXAqJP5wKiTCwhJ g6Az4W1is1c7U1AQ///rpgAAAAAAAAAA3G19SwuMCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLufQABABtbawKiTC8Cok/mDoAhJs1gv6jPhbWJQEP//qHAAANxtfUsPjAkAYAAAAOoF AAAADCkBd9wAFRfKJQEIAEUABdy7oEAAQAbRJcCokwvAqJP5g6AISbNYL+oz4W1iUBD//64k AAA1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTbcbX1LEYwJAGAA AADqBQAAAAwpAXfcABUXyiUBCABFAAXcu6FAAEAG0STAqJMLwKiT+YOgCEmzWDWeM+FtYlAQ //+uJAAANTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU23G19SxOM CQA8AAAAPAAAAAAVF8olAQAMKQF33AgARQAAKElGAABABok0wKiT+cCokwsISYOgM+FtYrNX RrtQEP//4D4AAAAAAAAAANxtfUsUjAkANgAAADYAAAAADCkBd9wAFRfKJQEIAEUAACi7okAA QAbW18CokwvAqJP5g6AISbNYO1Iz4W1iUBD//6hwAADcbX1LGIwJAGAAAADqBQAAAAwpAXfc ABUXyiUBCABFAAXcu6NAAEAG0SLAqJMLwKiT+YOgCEmzWDtSM+FtYlAQ//+uJAAAMzQ1Njc4 OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM03G19SxqMCQBgAAAA6gUAAAAM KQF33AAVF8olAQgARQAF3LukQABABtEhwKiTC8Cok/mDoAhJs1hBBjPhbWJQEP//riQAADM0 NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNNxtfUscjAkAPAAAADwA AAAAFRfKJQEADCkBd9wIAEUAAChJRwAAQAaJM8Cok/nAqJMLCEmDoDPhbWKzV1F+UBD//9V7 AAAAAAAAAADcbX1LHYwJADYAAAA2AAAAAAwpAXfcABUXyiUBCABFAAAou6VAAEAG1tTAqJML wKiT+YOgCEmzWEa6M+FtYlAQ//+ocAAA3G19SyGMCQBgAAAA6gUAAAAMKQF33AAVF8olAQgA RQAF3LumQABABtEfwKiTC8Cok/mDoAhJs1hGujPhbWJQEP//riQAADM0NTY3ODkwMTIzNDU2 Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNNxtfUsjjAkAYAAAAEUFAAAADCkBd9wAFRfK JQEIAEUABTe7p0AAQAbRw8CokwvAqJP5g6AISbNYTG4z4W1iUBD//61/AAAzNDU2Nzg5MDEy MzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzTcbX1LJYwJADwAAAA8AAAAABUXyiUB AAwpAXfcCABFAAAoSUgAAEAGiTLAqJP5wKiTCwhJg6Az4W1is1dc5lAQ///KEwAAAAAAAAAA 3G19SyaMCQA2AAAANgAAAAAMKQF33AAVF8olAQgARQAAKLuoQABABtbRwKiTC8Cok/mDoAhJ s1hRfTPhbWJQEP//qHAAANxtfUsqjAkAYAAAAOoFAAAADCkBd9wAFRfKJQEIAEUABdy7qUAA QAbRHMCokwvAqJP5g6AISbNYUX0z4W1iUBD//64kAAA4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5 MDEyMzQ1Njc4OTAxMjM0NTY3ODncbX1LLIwJAGAAAADqBQAAAAwpAXfcABUXyiUBCABFAAXc u6pAAEAG0RvAqJMLwKiT+YOgCEmzWFcxM+FtYlAQ//+uJAAAODkwMTIzNDU2Nzg5MDEyMzQ1 Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg53G19SzCMCQA2AAAANgAAAAAMKQF33AAVF8olAQgA RQAAKLurQABABtbOwKiTC8Cok/mDoAhJs1hc5TPhbWJQEP//qHAAANxtfUszjAkANgAAADYA AAAADCkBd9w= --------------040808050401050801030609-- --------------enig414F8604E9429B62B04040D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt9cFYACgkQLDqVQ9VXb8jWPACgmynA2AdXBN+ljrTT0Rn/Tn6P 4msAn0/rQZc74iIQ1y+hi8iyB91flb6i =NM45 -----END PGP SIGNATURE----- --------------enig414F8604E9429B62B04040D6-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 17:13:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AC62106566B for ; Thu, 18 Feb 2010 17:13:01 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8C49A8FC0C for ; Thu, 18 Feb 2010 17:12:59 +0000 (UTC) Received: (qmail 16735 invoked from network); 18 Feb 2010 17:12:59 -0000 Received: from unknown (HELO ?10.0.0.158?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 18 Feb 2010 17:12:59 -0000 Message-ID: <4B7D74A7.6010006@acm.poly.edu> Date: Thu, 18 Feb 2010 12:11:03 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20091021) MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 17:13:01 -0000 Ahoy. I didn't get any replies to this on -net, so I thought I'd try here. I have an 8.0-RELEASE-p2/amd64 machine running a custom kernel (configuration file at http://acm.poly.edu/~spawk/ACM) and I am unable to use the NFS server module on it. After loading the nfssvc module, attempting to load the nfsserver module fails and the following appears in dmesg: Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create undefined Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type I see a reference to the problem at http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.html. Am I missing something or has it never gotten resolved? Thanks. -Boris From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 17:18:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE821065676 for ; Thu, 18 Feb 2010 17:18:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id D42468FC17 for ; Thu, 18 Feb 2010 17:18:41 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta09.emeryville.ca.mail.comcast.net with comcast id jSbC1d0080mlR8UA9VJi1P; Thu, 18 Feb 2010 17:18:42 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta11.emeryville.ca.mail.comcast.net with comcast id jVJh1d0093S48mS8XVJh4D; Thu, 18 Feb 2010 17:18:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 72CCE1E301A; Thu, 18 Feb 2010 09:18:40 -0800 (PST) Date: Thu, 18 Feb 2010 09:18:40 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100218171840.GA60610@icarus.home.lan> References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> <4B7D6635.20605@sasktel.net> <4B7D6857.80902@sasktel.net> <4B7D7055.3060601@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B7D7055.3060601@omnilan.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 17:18:42 -0000 On Thu, Feb 18, 2010 at 05:52:37PM +0100, Harald Schmalzbauer wrote: > Stephen Hurd schrieb am 18.02.2010 17:18 (localtime): > ... > >one retransmit per five packets). Is this what you're seeing? If > >you have a capture you could share covering a few seconds, I could > >take a look and provide a better opinion. > > Thanks for your help, here's a small snippet of the iperf session. > There are hundreds od duplicate ACKs. I'm not sure how to understand > that. Like mentioned, I have to refresh some TCP basics before I can > do usefull tests. > But perhaps you can confirm that this behaviour is intendend, or > where the problem could be... Could you please re-run this capture (you're presumably using tcpdump) with the "-s 0" flag set? Also, can you state which machine/OS type is associated with what IP address? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 18:57:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EBEC1065753; Thu, 18 Feb 2010 18:57:26 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f219.google.com (mail-gx0-f219.google.com [209.85.217.219]) by mx1.freebsd.org (Postfix) with ESMTP id DA1748FC15; Thu, 18 Feb 2010 18:57:25 +0000 (UTC) Received: by gxk19 with SMTP id 19so2466876gxk.3 for ; Thu, 18 Feb 2010 10:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gUH/lef99CJMq0Z5uyjZfOjrk8Xp1mSt+lsOs1dJJ2g=; b=nIg8Lxa6f8kV4B3CW6cotfKYe8dMoTWxAagYBUqxJYTfbo/prZpz4KHpW3SqsgDdl4 WPStfD3tZ9BM2dhRnN6YFUxp0gfsI9rJIJH1DKKawytF/Sameu2irInSlmSniVV/LGgo 8DaPtWT2yhYEQN7ZqqRoZmLn0rXILIExeoVjI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ibchLp6+PXEPmy4lhiZQEyRKdJyacbTuJO9NAEwXc0sBHplKmn9TcObQJvjpP866E+ uhr9frGPoqvwiEbjbYVkniJbtTDb9yCWf0jqF2nvucg7O3Hgk9YBRIf4IHdZZf1k2jTT 0adoPApGm/CKr88uwpCAzkV6vnp6wFm3cmZ/o= MIME-Version: 1.0 Received: by 10.150.4.26 with SMTP id 26mr14471055ybd.0.1266519445208; Thu, 18 Feb 2010 10:57:25 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2010 10:57:25 -0800 Message-ID: From: Matt Reimer To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-STABLE Mailing List , rnoland@freebsd.org Subject: Re: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 18:57:26 -0000 On Tue, Feb 16, 2010 at 12:38 AM, Dan Naumov wrote: > > I don't know, but I plan to test that scenario in a few days. > > > > Matt > > Please share the results when you're done, I am really curious :) > Booting from a stripe of two raidz vdevs works: FreeBSD/i386 boot Default: doom:/boot/zfsloader boot: status pool: doom config: NAME STATE doom ONLINE raidz1 ONLINE label/doom-0 ONLINE label/doom-1 ONLINE label/doom-2 ONLINE raidz1 ONLINE label/doom-3 ONLINE label/doom-4 ONLINE label/doom-5 ONLINE I'd guess a stripe of mirrors would work fine too. If I get a chance I'll test that combo. > If booting of a stripe of 3 mirrors should work assuming no BIOS bugs, > can you explain why is booting off simple stripes (of any number of > disks) currently unsupported? I haven't tested that myself, but > everywhere I look seems to indicate that booting off a simple stripe > doesn't work or is that "everywhere" also out of date after your > changes? :) It's probably unsupported in Solaris/OpenSolaris because of their bootloader. Our bootloader is completely different from theirs and so is not subject to those restrictions in the ZFS docs. The bottom line is that I think FreeBSD can boot from pretty much any configuration, except possibly from systems with huge numbers of disks. Matt From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 19:14:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0888106566C for ; Thu, 18 Feb 2010 19:14:05 +0000 (UTC) (envelope-from hurds@sasktel.net) Received: from neutron.sasknet.sk.ca (neutron.sasknet.sk.ca [142.165.20.180]) by mx1.freebsd.org (Postfix) with ESMTP id 6368F8FC1F for ; Thu, 18 Feb 2010 19:14:05 +0000 (UTC) Received: from pps.filterd (neutron [127.0.0.1]) by neutron.sasknet.sk.ca (8.14.3/8.14.3) with SMTP id o1IIwGDY025365 for ; Thu, 18 Feb 2010 13:00:25 -0600 Received: from bgmpomr1.sasknet.sk.ca (bgmpOMR1.sasknet.sk.ca [142.165.72.22]) by neutron.sasknet.sk.ca with ESMTP id m19ud5519-1 for ; Thu, 18 Feb 2010 13:00:25 -0600 Received: from sasktel.net ([192.168.234.97]) by bgmpomr1.sasknet.sk.ca (SaskTel eMessaging Service) with ESMTP id <0KY100HBDWSPK870@bgmpomr1.sasknet.sk.ca> for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 13:00:25 -0600 (CST) Received: from [192.168.234.25] (Forwarded-For: [216.31.211.11]) by cgmail1.sasknet.sk.ca (mshttpd); Thu, 18 Feb 2010 11:00:25 -0800 Date: Thu, 18 Feb 2010 11:00:25 -0800 From: Stephen Hurd To: Harald Schmalzbauer Message-id: <5c00c4d917943.4b7d1dc9@sasktel.net> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.20 (built Feb 27 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_kDTlApuHY4uYbHwcgladwg)" Content-language: en X-Accept-Language: en Priority: normal X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-18_14:2010-02-06, 2010-02-18, 2010-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002180143 Cc: Patrick Mahan , freebsd-stable@freebsd.org, Stephen Hurd Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 19:14:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_kDTlApuHY4uYbHwcgladwg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline All those duplicate ACKs look like a problme to me... I would be inclined to capture from the other end or from a monitor port on the switch to make sure those are actually hitting the wire. The only explination I can think of is that the system sending the duplicate ACKs is assuming that it's lost a segment for some reason and is trying to trigger fast recovery early. --Boundary_(ID_kDTlApuHY4uYbHwcgladwg) Content-type: multipart/mixed; boundary="Boundary_(ID_K7VhZx6vpNouByAbQ57Thg)" --Boundary_(ID_K7VhZx6vpNouByAbQ57Thg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Stephen Hurd schrieb am 18.02.2010 17:18 (localtime): ... > one retransmit per five packets). Is this what you're seeing? If you > have a capture you could share covering a few seconds, I could take a > look and provide a better opinion. Thanks for your help, here's a small snippet of the iperf session. There are hundreds od duplicate ACKs. I'm not sure how to understand that. Like mentioned, I have to refresh some TCP basics before I can do usefull tests. But perhaps you can confirm that this behaviour is intendend, or where the problem could be... Thanks, -Harry --Boundary_(ID_K7VhZx6vpNouByAbQ57Thg)-- --Boundary_(ID_kDTlApuHY4uYbHwcgladwg)-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 19:23:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2C701065676 for ; Thu, 18 Feb 2010 19:23:22 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id C39B18FC18 for ; Thu, 18 Feb 2010 19:23:22 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o1IJNKo6031149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 11:23:21 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id B34251CC09; Thu, 18 Feb 2010 11:23:20 -0800 (PST) To: Harald Schmalzbauer In-reply-to: Your message of "Thu, 18 Feb 2010 17:24:05 +0100." <4B7D69A5.4010506@omnilan.de> Date: Thu, 18 Feb 2010 11:23:20 -0800 From: "Kevin Oberman" Message-Id: <20100218192320.B34251CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-18_14:2010-02-06, 2010-02-18, 2010-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002180148 Cc: Patrick Mahan , freebsd-stable@freebsd.org, Stephen Hurd Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 19:23:23 -0000 > Date: Thu, 18 Feb 2010 17:24:05 +0100 > From: Harald Schmalzbauer > Sender: owner-freebsd-stable@freebsd.org > > Stephen Hurd schrieb am 18.02.2010 17:09 (localtime): > ... > > A TCP SHOULD implement a delayed ACK, but an ACK should not be > > excessively delayed; in particular, the delay MUST be less than 0.5 > > seconds, and in a stream of full-sized segments there SHOULD be an ACK > > for at least every second segment. > > That's why I asked for help understandig TCP. I'm surely wrong then. I > thought the ACK segment gets sent after the transfer of n segments > equals windows-size. I don't undesrtand that window size yet... I'm back > into my books I recommend "TCP/IP Illustrated, Volume 1: The Protocols" by the late Rich Stevens. ISBN-13: 978-0201633467. It is easily the best book on how TCP/IP should actually work, though it is 16 years old and a few bits are obsolete. It is still my standard reference, though, and the basics are very well presented and those have not changed much since window scaling and the book covers that. Use wireshark to look at the PCAP file. It can spot a variety of "interesting" issues. For far more detail, tcptrace in conjunction with xplot can really show what is happening, but it requires pretty good understanding of how TCP works to make any sense of the output. The window is used to allow for long RTT links and processing delays. A path from the west coast of the US to Amsterdam is about 160 ms. The window allows for many packets to be in flight and with a 3 Gbps flow, that is a LOT of data. While an ACK is sent every two packets of received data, the transmitting side does not wait for the ACKs. It reduces the transmit window by the amount of data sent, but keeps sending until the window is too for the next packet. It also keeps track of received ACKs and, if one odes not come back, will retransmit. If SACK is used, only the missing data is retransmitted. If SACK is not enabled, all of the data from the missing packet on is retransmitted. That is a VERY simple and incomplete explanation of what is happening with the window, but most of that is irrelevant in local transfers with reasonable window sizes. Since large windows can adversely impact local transfers, most modern TCP stacks auto-tune window size. As a result, local transfers should use a smaller window than long distance transfers. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 19:36:57 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 909841065696 for ; Thu, 18 Feb 2010 19:36:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB818FC17 for ; Thu, 18 Feb 2010 19:36:56 +0000 (UTC) Received: by vws14 with SMTP id 14so872986vws.13 for ; Thu, 18 Feb 2010 11:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=kzhXH2sr/8M2/valVOZ2RmrdMZZLP3kERL1VxxzEVOo=; b=ZFreQs2hSmylkTzsD627T2DRIShm5xq4JqdGYH8y/RBaeqK7HK/MfmRE1aCOinh04F gKyZb0plD4x6lHgrlIYlYwsR8Bu2xyIuCfY9s8Ws87KgOohsQgzErrX+MwhjAlu48NqZ u1BIHDGgkoqINi6EyjS9yzxJI72hukoD5axI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=CcKaQMo0u5i1sMJxOS+6SG0IKp4la4+XIvd2ZY3fk9cwr9yIKC9gpPwYtGFduRVIlE Od2o2IKjqsVAopild9zFrLKnEr41Ah7MxHPs5JFuM7HNRfgGlSBVi9Jtu6ZUpFqQEWpJ yKyDJFLZ/EkWCwJrN4GSiGK7KDUc+N23CG4Ak= Received: by 10.220.108.8 with SMTP id d8mr5765911vcp.210.1266521815348; Thu, 18 Feb 2010 11:36:55 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 25sm21669690vws.21.2010.02.18.11.36.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 11:36:53 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 18 Feb 2010 11:36:12 -0800 From: Pyun YongHyeon Date: Thu, 18 Feb 2010 11:36:12 -0800 To: Slawa Olhovchenkov Message-ID: <20100218193612.GB11675@michelle.cdnetworks.com> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100218143822.GA8380@zxy.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 19:36:57 -0000 On Thu, Feb 18, 2010 at 05:38:22PM +0300, Slawa Olhovchenkov wrote: > On Tue, Feb 16, 2010 at 09:57:19AM -0800, Pyun YongHyeon wrote: > > > On Sun, Feb 14, 2010 at 10:04:58AM -0800, Nick Rogers wrote: > > > I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone > > > shed light on the below error? I unfortunately cannot provide a proper crash > > > dump. The pointer addresses are always the same. The only other thing I've > > > noticed that may be related is a watchdog timeout on bge0 error before the > > > panic. Thanks. > > > > > > > Any chance to get backtrace from the crash? > > I got same trouble on the same platform (8.0-STABLE/amd64). > hw.bge.allow_asf=0 already > > I got 2 proper crash dump (first w/ net.inet.ip.forwarding=1 > and second w/ net.inet.ip.forwarding=0). > It looks like mbuf pointer was changed to NULL in the middle of IP forwarding and IP fragment stage. If bge(4) frees passed mbufs this may happen but I'm not sure this comes from bge(4). By chance, are you using polling(4) on bge(4)? Also show me the dmesg output(only bge(4) related one). > backtrace from the first crash: > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff802ea751 > stack pointer = 0x28:0xffffff80000ef930 > frame pointer = 0x28:0xffffff80000ef970 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq26: bge1) > panic: from debugger > cpuid = 0 > Uptime: 5h23m50s > Physical memory: 2039 MB > Dumping 1316 MB: 1301 1285 1269 1253 1237 1221 1205 1189 1173 1157 1141 1125 1109 1093 1077 1061 1045 1029 1013 997 981 965 949 933 917 901 885 869 853 837 821 805 789 773 757 741 725 709 693 677 661 645 629 613 597 581 565 549 533 517 501 485 469 453 437 421 405 389 373 357 341 325 309 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 > > Reading symbols from /boot/kernel/if_bge.ko...Reading symbols from /boot/kernel/if_bge.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_bge.ko > Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /boot/kernel/miibus.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/miibus.ko > Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ipfw.ko > Reading symbols from /boot/kernel/nfsserver.ko...Reading symbols from /boot/kernel/nfsserver.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/nfsserver.ko > Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kernel/krpc.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/krpc.ko > Reading symbols from /boot/kernel/nfssvc.ko...Reading symbols from /boot/kernel/nfssvc.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/nfssvc.ko > #0 doadump () at pcpu.h:223 > 223 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:223 > #1 0xffffffff802909b9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff80290e0c in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff801a5bc7 in db_panic (addr=Variable "addr" is not available. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xffffffff801a5fd1 in db_command (last_cmdp=0xffffffff806b1fa0, cmd_table=Variable "cmd_table" is not available. > ) at /usr/src/sys/ddb/db_command.c:445 > #5 0xffffffff801a6220 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #6 0xffffffff801a81e9 in db_trap (type=Variable "type" is not available. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 0xffffffff802c0995 in kdb_trap (type=12, code=0, tf=0xffffff80000ef880) at /usr/src/sys/kern/subr_kdb.c:535 > #8 0xffffffff8049ee0d in trap_fatal (frame=0xffffff80000ef880, eva=Variable "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:852 > #9 0xffffffff8049f1e4 in trap_pfault (frame=0xffffff80000ef880, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773 > #10 0xffffffff8049fa6a in trap (frame=0xffffff80000ef880) at /usr/src/sys/amd64/amd64/trap.c:499 > #11 0xffffffff80484ff3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 > #12 0xffffffff802ea751 in m_copydata (m=0x0, off=0, len=108, cp=0xffffff0027865194 "б\026zHqJВ\220ЦПЫСPo~@<22>Feb 17 15:10:2") > at /usr/src/sys/kern/uipc_mbuf.c:816 > #13 0xffffffff8035e72d in ip_forward (m=0xffffff0001530900, srcrt=Variable "srcrt" is not available. > ) at /usr/src/sys/netinet/ip_input.c:1444 > #14 0xffffffff8035fef7 in ip_input (m=0xffffff0001530900) at /usr/src/sys/netinet/ip_input.c:717 > #15 0xffffffff80342e9e in netisr_dispatch_src (proto=1, source=Variable "source" is not available. > ) at /usr/src/sys/net/netisr.c:917 > #16 0xffffffff8033fd5d in ether_demux (ifp=0xffffff0001412800, m=0xffffff0001530900) at /usr/src/sys/net/if_ethersubr.c:895 > #17 0xffffffff80340127 in ether_input (ifp=0xffffff0001412800, m=0xffffff0001530900) at /usr/src/sys/net/if_ethersubr.c:754 > #18 0xffffffff80838257 in bge_rxeof (sc=0xffffff800023b000, rx_prod=773, holdlck=1) at /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3392 > #19 0xffffffff8083a058 in bge_intr (xsc=Variable "xsc" is not available. > ) at /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3657 > #20 0xffffffff8026964d in intr_event_execute_handlers (p=Variable "p" is not available. > ) at /usr/src/sys/kern/kern_intr.c:1220 > #21 0xffffffff8026acfe in ithread_loop (arg=0xffffff0001430740) at /usr/src/sys/kern/kern_intr.c:1233 > #22 0xffffffff80267088 in fork_exit (callout=0xffffffff8026ac70 , arg=0xffffff0001430740, frame=0xffffff80000efc80) > at /usr/src/sys/kern/kern_fork.c:843 > #23 0xffffffff804854ce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000001 in ?? () > > backtrace from the second crash (ipforwardinf disabled): > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff802eb3b7 > stack pointer = 0x28:0xffffff80001c66e0 > frame pointer = 0x28:0xffffff80001c6740 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 732 (named) > panic: from debugger > cpuid = 0 > Uptime: 8h28m38s > Physical memory: 2039 MB > Dumping 1425 MB: 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 > > Reading symbols from /boot/kernel/if_bge.ko...Reading symbols from /boot/kernel/if_bge.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_bge.ko > Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /boot/kernel/miibus.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/miibus.ko > Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ipfw.ko > Reading symbols from /boot/kernel/nfsserver.ko...Reading symbols from /boot/kernel/nfsserver.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/nfsserver.ko > Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kernel/krpc.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/krpc.ko > Reading symbols from /boot/kernel/nfssvc.ko...Reading symbols from /boot/kernel/nfssvc.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/nfssvc.ko > #0 doadump () at pcpu.h:223 > 223 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:223 > #1 0xffffffff802909b9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff80290e0c in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff801a5bc7 in db_panic (addr=Variable "addr" is not available. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xffffffff801a5fd1 in db_command (last_cmdp=0xffffffff806b1fa0, cmd_table=Variable "cmd_table" is not available. > ) at /usr/src/sys/ddb/db_command.c:445 > #5 0xffffffff801a6220 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #6 0xffffffff801a81e9 in db_trap (type=Variable "type" is not available. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 0xffffffff802c0995 in kdb_trap (type=12, code=0, tf=0xffffff80001c6630) at /usr/src/sys/kern/subr_kdb.c:535 > #8 0xffffffff8049ee0d in trap_fatal (frame=0xffffff80001c6630, eva=Variable "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:852 > #9 0xffffffff8049f1e4 in trap_pfault (frame=0xffffff80001c6630, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773 > #10 0xffffffff8049fa6a in trap (frame=0xffffff80001c6630) at /usr/src/sys/amd64/amd64/trap.c:499 > #11 0xffffffff80484ff3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 > #12 0xffffffff802eb3b7 in m_copym (m=0x0, off0=1496, len=1496, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:541 > #13 0xffffffff80361041 in ip_fragment (ip=0xffffff004c748830, m_frag=0xffffff80001c6848, mtu=Variable "mtu" is not available. > ) at /usr/src/sys/netinet/ip_output.c:805 > #14 0xffffffff8036206e in ip_output (m=0xffffff0012d4ed00, opt=Variable "opt" is not available. > ) at /usr/src/sys/netinet/ip_output.c:636 > #15 0xffffffff803d8ac5 in udp_send (so=Variable "so" is not available. > ) at /usr/src/sys/netinet/udp_usrreq.c:1236 > #16 0xffffffff802f5a72 in sosend_dgram (so=0xffffff00018da000, addr=0xffffff00018ad120, uio=Variable "uio" is not available. > ) at /usr/src/sys/kern/uipc_socket.c:1069 > #17 0xffffffff802f9b75 in kern_sendit (td=0xffffff00015fd740, s=514, mp=0xffffff80001c6af0, flags=0, control=0x0, segflg=UIO_USERSPACE) > at /usr/src/sys/kern/uipc_syscalls.c:784 > #18 0xffffffff802f9dbc in sendit (td=0xffffff00015fd740, s=514, mp=0xffffff80001c6af0, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:720 > #19 0xffffffff802f9e47 in sendmsg (td=0xffffff00015fd740, uap=0xffffff80001c6bf0) at /usr/src/sys/kern/uipc_syscalls.c:917 > #20 0xffffffff8049f3f7 in syscall (frame=0xffffff80001c6c80) at /usr/src/sys/amd64/amd64/trap.c:1025 > #21 0xffffffff804852d1 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 > #22 0x0000000800c82c6c in ?? () > Previous frame inner to this frame (corrupt stack?) > > > -- > Slawa Olhovchenkov From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 19:46:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EEE5106566B for ; Thu, 18 Feb 2010 19:46:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 239E48FC16 for ; Thu, 18 Feb 2010 19:46:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANInfUuDaFvI/2dsb2JhbACbCHS9M4RnBIMVgniIFw X-IronPort-AV: E=Sophos;i="4.49,498,1262581200"; d="scan'208";a="66049031" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 18 Feb 2010 14:46:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 4D0A89400F2; Thu, 18 Feb 2010 14:46:19 -0500 (EST) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqyXMCpOhjrZ; Thu, 18 Feb 2010 14:46:18 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 15818940073; Thu, 18 Feb 2010 14:46:18 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1IJvv723503; Thu, 18 Feb 2010 14:57:57 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 18 Feb 2010 14:57:57 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Boris Kochergin In-Reply-To: <4B7D74A7.6010006@acm.poly.edu> Message-ID: References: <4B7D74A7.6010006@acm.poly.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-STABLE Mailing List Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 19:46:20 -0000 On Thu, 18 Feb 2010, Boris Kochergin wrote: > Ahoy. I didn't get any replies to this on -net, so I thought I'd try here. I > have an 8.0-RELEASE-p2/amd64 machine running a custom kernel (configuration > file at http://acm.poly.edu/~spawk/ACM) and I am unable to use the NFS server > module on it. After loading the nfssvc module, attempting to load the > nfsserver module fails and the following appears in dmesg: > > Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create undefined > Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type > > I see a reference to the problem at > http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.html. Am > I missing something or has it never gotten resolved? Thanks. > I don't know diddly about the module loading stuff, but you could try this patch. (svcpool_create() is a part of the krpc, which is listed as a module that nfsserver depends on) rick --- untested patch for nfs_srvsubs.c --- --- nfsserver/nfs_srvsubs.c.sav 2010-02-18 14:41:52.000000000 -0500 +++ nfsserver/nfs_srvsubs.c 2010-02-18 14:42:12.000000000 -0500 @@ -554,7 +554,7 @@ nfsrv_modevent, NULL, }; -DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_ANY); +DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_FIRST); /* So that loader and kldload(2) can find us, wherever we are.. */ MODULE_VERSION(nfsserver, 1); From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 20:02:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 207BB106566B for ; Thu, 18 Feb 2010 20:02:29 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id DE8258FC1A for ; Thu, 18 Feb 2010 20:02:28 +0000 (UTC) Received: (qmail 20547 invoked from network); 18 Feb 2010 20:02:25 -0000 Received: from unknown (HELO ?10.0.0.158?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 18 Feb 2010 20:02:24 -0000 Message-ID: <4B7D9C5C.1090909@acm.poly.edu> Date: Thu, 18 Feb 2010 15:00:28 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20091021) MIME-Version: 1.0 To: Rick Macklem References: <4B7D74A7.6010006@acm.poly.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 20:02:29 -0000 Rick Macklem wrote: > > > On Thu, 18 Feb 2010, Boris Kochergin wrote: > >> Ahoy. I didn't get any replies to this on -net, so I thought I'd try >> here. I have an 8.0-RELEASE-p2/amd64 machine running a custom kernel >> (configuration file at http://acm.poly.edu/~spawk/ACM) and I am >> unable to use the NFS server module on it. After loading the nfssvc >> module, attempting to load the nfsserver module fails and the >> following appears in dmesg: >> >> Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create >> undefined >> Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type >> >> I see a reference to the problem at >> http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.html. >> Am I missing something or has it never gotten resolved? Thanks. >> > I don't know diddly about the module loading stuff, but you could try > this patch. (svcpool_create() is a part of the krpc, which is listed > as a module that nfsserver depends on) > > rick > --- untested patch for nfs_srvsubs.c --- > --- nfsserver/nfs_srvsubs.c.sav 2010-02-18 14:41:52.000000000 -0500 > +++ nfsserver/nfs_srvsubs.c 2010-02-18 14:42:12.000000000 -0500 > @@ -554,7 +554,7 @@ > nfsrv_modevent, > NULL, > }; > -DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_ANY); > +DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_FIRST); > > /* So that loader and kldload(2) can find us, wherever we are.. */ > MODULE_VERSION(nfsserver, 1); Thanks for the patch, but the problem persists with it, I'm afraid. -Boris From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 20:55:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E1C31065672 for ; Thu, 18 Feb 2010 20:55:06 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id C98AA8FC13 for ; Thu, 18 Feb 2010 20:55:05 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1IKsx52014226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 07:55:00 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1IKsxL2078678; Fri, 19 Feb 2010 07:54:59 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1IKswKk078677; Fri, 19 Feb 2010 07:54:58 +1100 (EST) (envelope-from peter) Date: Fri, 19 Feb 2010 07:54:58 +1100 From: Peter Jeremy To: Torfinn Ingolfsen Message-ID: <20100218205458.GA78560@server.vk2pj.dyndns.org> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 20:55:06 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-17 20:03:22 +0100, Torfinn Ingolfsen wrote: >On Wed, 17 Feb 2010 19:49:27 +0100 >Torfinn Ingolfsen wrote: > >> Unfortunately, it isn't enough to keep the machine in sync all the time. >> But it is better than HPET so I'll keep it. Did you delete /etc/ntp.drift between timecounter changes? >This thread is interesting: >http://lkml.indiana.edu/hypermail/linux/kernel/0903.1/01356.html > >Is there a way in FreeBSD to perform adjustmenst like adjtimex? There's ntptime(8) but it doesn't have a "self-calibrate mode". Based on the messages log you gave, and assuming the ntpd PLL is sane, your acpi-safe clock is about 2500ppm slow (the steps reflect about 2000ppm and the ntpd PLL should be compensating for a further 500ppm) - this is really bad, even for consumer-grade stuff. Are you running non-standard clock speeds or multipliers? If there's nothing obvious, I'd follow John Hay's suggesion and force set either your TSC or ACPI frequency in sysctl.conf (you can't override the HPET frequency). Take either the TSC or ACPI frequency reported by "sysctl machdep", reduce it by 2500ppm and set that in /etc/sysctl.conf. Assuming a "standard" (3.58MHz) ACPI, the latter would look like: machdep.acpi_timer_freq=3D3570596 kern.timecounter.hardware=3DACPI-safe The stop ntpd, delete /var/db/ntp.drift and either reboot or manually set the above sysctl's and restart ntpd. [I think I've got the adjustment direction correct in the above, if I've stuffed up, you need to adjust in the other direction] --=20 Peter Jeremy --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt9qSIACgkQ/opHv/APuIfINwCeKIjjiAPpk4Wgf0t3N4eGY81V w0YAnR4765IlxPBHMURVL0KBOVMneHeP =uB4/ -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 21:24:30 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DEF91065676 for ; Thu, 18 Feb 2010 21:24:30 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 0057D8FC0A for ; Thu, 18 Feb 2010 21:24:29 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NiDrI-0007nK-N2; Fri, 19 Feb 2010 00:24:28 +0300 Date: Fri, 19 Feb 2010 00:24:28 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100218212428.GJ55307@zxy.spb.ru> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100218193612.GB11675@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 21:24:30 -0000 On Thu, Feb 18, 2010 at 11:36:12AM -0800, Pyun YongHyeon wrote: > On Thu, Feb 18, 2010 at 05:38:22PM +0300, Slawa Olhovchenkov wrote: > > On Tue, Feb 16, 2010 at 09:57:19AM -0800, Pyun YongHyeon wrote: > > > > > On Sun, Feb 14, 2010 at 10:04:58AM -0800, Nick Rogers wrote: > > > > I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone > > > > shed light on the below error? I unfortunately cannot provide a proper crash > > > > dump. The pointer addresses are always the same. The only other thing I've > > > > noticed that may be related is a watchdog timeout on bge0 error before the > > > > panic. Thanks. > > > > > > > > > > Any chance to get backtrace from the crash? > > > > I got same trouble on the same platform (8.0-STABLE/amd64). > > hw.bge.allow_asf=0 already > > > > I got 2 proper crash dump (first w/ net.inet.ip.forwarding=1 > > and second w/ net.inet.ip.forwarding=0). > > > > It looks like mbuf pointer was changed to NULL in the middle of IP > forwarding and IP fragment stage. If bge(4) frees passed mbufs this > may happen but I'm not sure this comes from bge(4). > By chance, are you using polling(4) on bge(4)? Also show me the I am not using polling. > dmesg output(only bge(4) related one). dmesg from boot: bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:14:c2:3d:e5:52 bge0: [ITHREAD] bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:14:c2:3d:e5:51 bge1: [ITHREAD] bge1: link state changed to UP bge0: link state changed to UP Nothing in dmesg before trap. -- Slawa Olhovchenkov From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 21:32:58 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0425510656A3 for ; Thu, 18 Feb 2010 21:32:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 354EA8FC14 for ; Thu, 18 Feb 2010 21:32:56 +0000 (UTC) Received: by vws14 with SMTP id 14so916974vws.13 for ; Thu, 18 Feb 2010 13:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Vjzb3yCa1aRYdJrqYYBoBYrmfZ29eMYYAOEdXkGflZQ=; b=xbJl1FbZn5OIgoxaZbx1EnbaBvC5J4Ik5dF+hoXC/RUIJkndFCNXMbO8bOnnc+WWl8 0ayHdej+ksYm3WeSIe62nAXpp5vWLxfsKwQ7mbClgrcqYjMim3sEnDHRGKBYdBjYt9ue dUJ3aMdEVl1r2fxxYGwU6R4Sg/bU035+gCsT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ICjr62CeIzwLLM1bKMrECGUVOpRvx3LSdSDA2A6HuWZET2GdxO7k9qZdrOJyd4mLB1 8Hvk8jOcr3RmgYsQl4Er+E/G5JjAa/lysiHcSczEj+f3gYY0KdatyQ4LECbr04l82SlA Aoj/ibDzwFAe85jMyEbn3uk+IwRpKIqM/SZhU= Received: by 10.220.107.228 with SMTP id c36mr5984607vcp.165.1266528776220; Thu, 18 Feb 2010 13:32:56 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 42sm30617164vws.8.2010.02.18.13.32.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 13:32:54 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 18 Feb 2010 13:32:13 -0800 From: Pyun YongHyeon Date: Thu, 18 Feb 2010 13:32:13 -0800 To: Slawa Olhovchenkov Message-ID: <20100218213213.GD11675@michelle.cdnetworks.com> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100218212428.GJ55307@zxy.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 21:32:58 -0000 On Fri, Feb 19, 2010 at 12:24:28AM +0300, Slawa Olhovchenkov wrote: > On Thu, Feb 18, 2010 at 11:36:12AM -0800, Pyun YongHyeon wrote: > > > On Thu, Feb 18, 2010 at 05:38:22PM +0300, Slawa Olhovchenkov wrote: > > > On Tue, Feb 16, 2010 at 09:57:19AM -0800, Pyun YongHyeon wrote: > > > > > > > On Sun, Feb 14, 2010 at 10:04:58AM -0800, Nick Rogers wrote: > > > > > I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone > > > > > shed light on the below error? I unfortunately cannot provide a proper crash > > > > > dump. The pointer addresses are always the same. The only other thing I've > > > > > noticed that may be related is a watchdog timeout on bge0 error before the > > > > > panic. Thanks. > > > > > > > > > > > > > Any chance to get backtrace from the crash? > > > > > > I got same trouble on the same platform (8.0-STABLE/amd64). > > > hw.bge.allow_asf=0 already > > > > > > I got 2 proper crash dump (first w/ net.inet.ip.forwarding=1 > > > and second w/ net.inet.ip.forwarding=0). > > > > > > > It looks like mbuf pointer was changed to NULL in the middle of IP > > forwarding and IP fragment stage. If bge(4) frees passed mbufs this > > may happen but I'm not sure this comes from bge(4). > > By chance, are you using polling(4) on bge(4)? Also show me the > > I am not using polling. > Ok. > > dmesg output(only bge(4) related one). > > dmesg from boot: > > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge0: Ethernet address: 00:14:c2:3d:e5:52 > bge0: [ITHREAD] > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge1: Ethernet address: 00:14:c2:3d:e5:51 > bge1: [ITHREAD] > bge1: link state changed to UP > bge0: link state changed to UP > > Nothing in dmesg before trap. > Is this PCI-X controller? It would be even better if you can post bge(4) related dmesg output of verbosed boot and the output of "pciconf -lcv". From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 21:41:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC131065694 for ; Thu, 18 Feb 2010 21:41:45 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id B8D9F8FC16 for ; Thu, 18 Feb 2010 21:41:44 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1ILfesC043901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 22:41:40 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7DB408.9010706@omnilan.de> Date: Thu, 18 Feb 2010 22:41:28 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Kevin Oberman References: <20100218192320.B34251CC09@ptavv.es.net> In-Reply-To: <20100218192320.B34251CC09@ptavv.es.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEDFBD674DA051D5C5011184D" Cc: Patrick Mahan , freebsd-stable@freebsd.org, Stephen Hurd Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 21:41:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEDFBD674DA051D5C5011184D Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Kevin Oberman schrieb am 18.02.2010 20:23 (localtime): =2E.. > window allows for many packets to be in flight and with a 3 Gbps flow, > that is a LOT of data. While an ACK is sent every two packets of > received data, the transmitting side does not wait for the ACKs. It =2E.. > That is a VERY simple and incomplete explanation of what is happening > with the window, but most of that is irrelevant in local transfers with= Thanks a lot, then I understood it at least half correct ;) My=20 missunderstanding was that I thought the receiver would reduce ACKs...=20 Now I know more :) But unfortunately that makes it more mysterious where the throughput=20 problem lies... Thanks to everyone so far, -Harry --------------enigEDFBD674DA051D5C5011184D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt9tBQACgkQLDqVQ9VXb8i3YwCggQEo/kEyKDdb3TxU7hTzhQfm i2gAoKs+4d2XbG3NtN1b9rgu6zJVC7vD =2Ckw -----END PGP SIGNATURE----- --------------enigEDFBD674DA051D5C5011184D-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 21:41:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6731E1065696 for ; Thu, 18 Feb 2010 21:41:45 +0000 (UTC) (envelope-from scott+lists.freebsd@fishballoon.org) Received: from queueout03-winn.ispmail.ntl.com (queueout03-winn.ispmail.ntl.com [81.103.221.33]) by mx1.freebsd.org (Postfix) with ESMTP id E7DC98FC17 for ; Thu, 18 Feb 2010 21:41:44 +0000 (UTC) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100218212648.UUGK4474.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Thu, 18 Feb 2010 21:26:48 +0000 Received: from llama.fishballoon.org ([86.26.7.178]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100218212647.FTYC21638.aamtaout02-winn.ispmail.ntl.com@llama.fishballoon.org>; Thu, 18 Feb 2010 21:26:47 +0000 Received: from phasmid.fishballoon.org ([192.168.0.199]:50801) by llama.fishballoon.org with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NiDtS-000EhM-AN; Thu, 18 Feb 2010 21:26:42 +0000 Received: by phasmid.fishballoon.org (Postfix, from userid 1000) id F261B162429F; Thu, 18 Feb 2010 21:26:41 +0000 (GMT) From: Scott Mitchell To: freebsd-stable@freebsd.org Date: Thu, 18 Feb 2010 21:26:41 +0000 User-Agent: KMail/1.9.10 References: <20091208174145.GA14312@mr-happy.com> In-Reply-To: <20091208174145.GA14312@mr-happy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201002182126.41632.scott+lists.freebsd@fishballoon.org> X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=neHVhDx0SRvTBu1eHFkA:9 a=o6t_yY5Ce0-fwCuPNS4A:7 a=Y7TJE5Z-IrHFrI2Dc6xdgF4hUqQA:4 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Jeff Blank Subject: Re: Dell PowerEdge Virtual Media X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 21:41:45 -0000 On Tuesday 08 December 2009 17:41:45 Jeff Blank wrote: > Hi, > > I'm having a little trouble using the "virtual media" function of > Dell's PowerEdge R-series (R710 in this case) iDRAC6 under FreeBSD > (7.1, 8.0). This is presented as /dev/cd0, a USB/"SCSI" device, I > guess. This is in the dmesg buffer when I boot up the existing 7.1 > installation with the virtual optical drive mapped to the 8.0-RELEASE > amd64 DVD image: > > umass0: > on uhub6 [...] > cd0 at umass-sim0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 40.000MB/s transfers > cd0: cd present [1058105 x 2048 byte records] > GEOM_LABEL: Label for provider cd0 is iso9660/FreeBSD_Install. > > However, > # mount -t cd9660 /dev/cd0 /mnt > mount_cd9660: /dev/cd0: Invalid argument I see exactly the same problem, also on an R710 (very annoying - I had to walk all the way down the corridor to install 8.0 on it :-) Messing around with it a bit more post-install, I did discover one interesting thing: (501) ~ $ sudo mount_cd9660 -v /dev/cd0 /mnt Password: using starting sector 512 mount_cd9660: /dev/cd0: Invalid argument (502) ~ $ sudo mount_cd9660 -s0v /dev/cd0 (503) ~ $ ls /mnt 8.0-RELEASE/ README.TXT dev/ packages/ sys@ COPYRIGHT RELNOTES.HTM docbook.css proc/ tmp/ ERRATA.HTM RELNOTES.TXT etc/ rescue/ usr/ ERRATA.TXT bin/ lib/ root/ var/ HARDWARE.HTM boot/ libexec/ rr_moved/ HARDWARE.TXT boot.catalog media/ sbin/ README.HTM cdrom.inf mnt/ stand@ So it appears to work if I force the starting sector to be zero. I see the same result with an RHEL5 DVD image: (504) ~ $ sudo umount /mnt (505) ~ $ sudo mount_cd9660 -v /dev/cd0 /mnt using starting sector 512 mount_cd9660: /dev/cd0: Invalid argument (506) ~ $ sudo mount_cd9660 -s0 /dev/cd0 /mnt (507) ~ $ ls /mnt Cluster/ RELEASE-NOTES-U2-de.html ClusterStorage/ RELEASE-NOTES-U2-en.html EULA RELEASE-NOTES-U2-es.html GPL RELEASE-NOTES-U2-fr.html README-as.html RELEASE-NOTES-U2-gu.html README-bn.html RELEASE-NOTES-U2-hi.html README-de.html RELEASE-NOTES-U2-it.html README-en RELEASE-NOTES-U2-ja.html [...] RELEASE-NOTES-U1-ta.html Server/ RELEASE-NOTES-U1-te.html TRANS.TBL RELEASE-NOTES-U1-zh_CN.html VT/ RELEASE-NOTES-U1-zh_TW.html eula.en_US RELEASE-NOTES-U2-as.html images/ RELEASE-NOTES-U2-bn.html isolinux/ (508) ~ $ sudo umount /mnt Also the same result with a CD (as opposed to DVD) image. I've no idea if the problem lies in the virtual media driver or in FreeBSD, but maybe someone who understands these things would like to investigate? This machine is going into production in a couple of weeks time. I can run reasonable experiments on it until then, time permitting. Thanks, Scott From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 21:50:42 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 518DA1065672 for ; Thu, 18 Feb 2010 21:50:42 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6288FC13 for ; Thu, 18 Feb 2010 21:50:41 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NiEGd-000889-VS; Fri, 19 Feb 2010 00:50:39 +0300 Date: Fri, 19 Feb 2010 00:50:39 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100218215039.GK55307@zxy.spb.ru> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100218213213.GD11675@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 21:50:42 -0000 On Thu, Feb 18, 2010 at 01:32:13PM -0800, Pyun YongHyeon wrote: > > > dmesg output(only bge(4) related one). > > > > dmesg from boot: > > > > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > > miibus0: on bge0 > > brgphy0: PHY 1 on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > bge0: Ethernet address: 00:14:c2:3d:e5:52 > > bge0: [ITHREAD] > > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > > miibus1: on bge1 > > brgphy1: PHY 1 on miibus1 > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > bge1: Ethernet address: 00:14:c2:3d:e5:51 > > bge1: [ITHREAD] > > bge1: link state changed to UP > > bge0: link state changed to UP > > > > Nothing in dmesg before trap. > > > > Is this PCI-X controller? It would be even better if you can post This integrated controller (HP DL360-G4) > bge(4) related dmesg output of verbosed boot and the output of Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8088e000. Preloaded elf obj module "/boot/kernel/if_bge.ko" at 0xffffffff8088e1d0. Preloaded elf obj module "/boot/kernel/miibus.ko" at 0xffffffff8088e7f8. pci0:2:2:0: bad VPD cksum, remain 19 bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfdf70000 bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0019, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:14:c2:3d:e5:52 ioapic1: routing intpin 1 (PCI IRQ 25) to lapic 0 vector 50 bge0: [MPSAFE] bge0: [ITHREAD] pci0:2:2:1: bad VPD cksum, remain 19 bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfdf60000 bge1: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: OUI 0x000818, model 0x0019, rev. 0 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: bpf attached bge1: Ethernet address: 00:14:c2:3d:e5:51 ioapic1: routing intpin 2 (PCI IRQ 26) to lapic 0 vector 51 bge1: [MPSAFE] bge1: [ITHREAD] bge1: link UP bge1: link state changed to UP > "pciconf -lcv". hostb0@pci0:0:0:0: class=0x060000 card=0x32000e11 chip=0x35908086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'E7520 Server Memory Controller Hub' class = bridge subclass = HOST-PCI cap 09[40] = vendor (length 5) Intel cap 4 version 1 pcib1@pci0:0:2:0: class=0x060400 card=0x00000000 chip=0x35958086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCIe Port A0' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[64] = PCI-Express 1 root port max data 256(256) link x0(x8) pcib2@pci0:0:4:0: class=0x060400 card=0x00000000 chip=0x35978086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCIe Port B0' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[64] = PCI-Express 1 root port max data 256(256) link x8(x8) pcib5@pci0:0:6:0: class=0x060400 card=0x00000000 chip=0x35998086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCIe Port C0' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[64] = PCI-Express 1 root port max data 256(256) link x0(x8) pcib6@pci0:0:28:0: class=0x060400 card=0x00000000 chip=0x25ae8086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = 'Hub Interface to PCI-X Bridge (6300ESB)' class = bridge subclass = PCI-PCI cap 07[50] = PCI-X 64-bit bridge none0@pci0:0:29:0: class=0x0c0300 card=0x32010e11 chip=0x25a98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'USB 1.1 UHCI Controller *1 (6300ESB)' class = serial bus subclass = USB none1@pci0:0:29:1: class=0x0c0300 card=0x32010e11 chip=0x25aa8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'USB 1.1 UHCI Controller *2 (6300ESB)' class = serial bus subclass = USB none2@pci0:0:29:4: class=0x088000 card=0x32010e11 chip=0x25ab8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Watchdog Timer (6300ESB)' class = base peripheral ioapic0@pci0:0:29:5: class=0x080020 card=0x32010e11 chip=0x25ac8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '6300ESB I/O Advanced Programmable Interrupt Controller' class = base peripheral subclass = interrupt controller cap 07[50] = PCI-X 64-bit supports 512 burst read, 1 split transaction none3@pci0:0:29:7: class=0x0c0320 card=0x32010e11 chip=0x25ad8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'USB 2.0 EHCI Controller (6300ESB)' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0x80 in map 0x14 pcib7@pci0:0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x0a hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x25a18086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '6300ESB LPC Inteface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x32010e11 chip=0x25a28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'IDE Controller (6300ESB)' class = mass storage subclass = ATA pcib3@pci0:6:0:0: class=0x060400 card=0x00000000 chip=0x03298086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express-to-PCI Express Bridge A (6700PXH)' class = bridge subclass = PCI-PCI cap 10[44] = PCI-Express 1 PCI bridge max data 256(256) link x8(x8) cap 05[5c] = MSI supports 1 message, 64 bit cap 01[6c] = powerspec 2 supports D0 D3 current D0 cap 07[d8] = PCI-X bridge pcib4@pci0:6:0:2: class=0x060400 card=0x00000000 chip=0x032a8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express-to-PCI Express Bridge B (6700PXH)' class = bridge subclass = PCI-PCI cap 10[44] = PCI-Express 1 PCI bridge max data 256(256) link x8(x8) cap 05[5c] = MSI supports 1 message, 64 bit cap 01[6c] = powerspec 2 supports D0 D3 current D0 cap 07[d8] = PCI-X bridge ciss0@pci0:2:1:0: class=0x010400 card=0x40910e11 chip=0x00460e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Smart Array 64xx/6i Controller' class = mass storage subclass = RAID cap 01[d0] = powerspec 2 supports D0 D1 D3 current D0 cap 07[dc] = PCI-X 64-bit supports 133MHz, 2048 burst read, 8 split transactions cap 03[f0] = VPD bge0@pci0:2:2:0: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit bge1@pci0:2:2:1: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit vgapci0@pci0:1:3:0: class=0x030000 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)' class = display subclass = VGA cap 01[5c] = powerspec 2 supports D0 D1 D2 D3 current D0 none4@pci0:1:4:0: class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Integrated Lights Out Processor (iLo)' class = base peripheral cap 01[f0] = powerspec 2 supports D0 D3 current D0 none5@pci0:1:4:2: class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Integrated Lights Out Processor (iLo)' class = base peripheral cap 01[f0] = powerspec 2 supports D0 D3 current D0 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 21:54:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9876F1065679 for ; Thu, 18 Feb 2010 21:54:17 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 707208FC0C for ; Thu, 18 Feb 2010 21:54:17 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1NiEK8-000L9F-42; Thu, 18 Feb 2010 16:54:16 -0500 Date: Thu, 18 Feb 2010 16:54:16 -0500 From: Gary Palmer To: Scott Mitchell Message-ID: <20100218215416.GB39863@in-addr.com> References: <20091208174145.GA14312@mr-happy.com> <201002182126.41632.scott+lists.freebsd@fishballoon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002182126.41632.scott+lists.freebsd@fishballoon.org> Cc: Jeff Blank , freebsd-stable@freebsd.org Subject: Re: Dell PowerEdge Virtual Media X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 21:54:17 -0000 On Thu, Feb 18, 2010 at 09:26:41PM +0000, Scott Mitchell wrote: > So it appears to work if I force the starting sector to be zero. I see the > same result with an RHEL5 DVD image: > > (504) ~ $ sudo umount /mnt > (505) ~ $ sudo mount_cd9660 -v /dev/cd0 /mnt > using starting sector 512 > mount_cd9660: /dev/cd0: Invalid argument > (506) ~ $ sudo mount_cd9660 -s0 /dev/cd0 /mnt Hi, I'm no expert at this code, but it might be interesting to see the results of cdcontrol -v info The code in mount_cd9660 in 7.x reads the CD/DVD table of contents to figure out where the data segment starts. The only thing I can guess is that the TOC data is getting munged somehow. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 22:07:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2DA41065692; Thu, 18 Feb 2010 22:07:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5C18E8FC14; Thu, 18 Feb 2010 22:07:24 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1IM7FBd048682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 00:07:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o1IM7FmM042794; Fri, 19 Feb 2010 00:07:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o1IM7EPZ042793; Fri, 19 Feb 2010 00:07:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Feb 2010 00:07:14 +0200 From: Kostik Belousov To: Boris Kochergin Message-ID: <20100218220714.GU50403@deviant.kiev.zoral.com.ua> References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TOcFo/l1T3s1H/TJ" Content-Disposition: inline In-Reply-To: <4B7D9C5C.1090909@acm.poly.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: marius@freebsd.org, Rick Macklem , FreeBSD-STABLE Mailing List Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 22:07:26 -0000 --TOcFo/l1T3s1H/TJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 18, 2010 at 03:00:28PM -0500, Boris Kochergin wrote: > Rick Macklem wrote: > > > > > >On Thu, 18 Feb 2010, Boris Kochergin wrote: > > > >>Ahoy. I didn't get any replies to this on -net, so I thought I'd try=20 > >>here. I have an 8.0-RELEASE-p2/amd64 machine running a custom kernel=20 > >>(configuration file at http://acm.poly.edu/~spawk/ACM) and I am=20 > >>unable to use the NFS server module on it. After loading the nfssvc=20 > >>module, attempting to load the nfsserver module fails and the=20 > >>following appears in dmesg: > >> > >>Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create=20 > >>undefined > >>Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type > >> > >>I see a reference to the problem at=20 > >>http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.htm= l.=20 > >>Am I missing something or has it never gotten resolved? Thanks. > >> > >I don't know diddly about the module loading stuff, but you could try > >this patch. (svcpool_create() is a part of the krpc, which is listed > >as a module that nfsserver depends on) > > > >rick > >--- untested patch for nfs_srvsubs.c --- > >--- nfsserver/nfs_srvsubs.c.sav 2010-02-18 14:41:52.000000000 -0500 > >+++ nfsserver/nfs_srvsubs.c 2010-02-18 14:42:12.000000000 -0500 > >@@ -554,7 +554,7 @@ > > nfsrv_modevent, > > NULL, > > }; > >-DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_ANY); > >+DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_FIRST); > > > > /* So that loader and kldload(2) can find us, wherever we are.. */ > > MODULE_VERSION(nfsserver, 1); > Thanks for the patch, but the problem persists with it, I'm afraid. I think this is changed in HEAD, and part of the changes are already in stable/8, which is different from 8.0 too. Anyway, for HEAD nfsserver we need 1. nfscommon 2. nfs_common. Also, nfs_common module is not attached to the build. The patch below gives up on nfs_common, puts that parts into nfscommon, and corrects dependencies for nfsserver and nfsclient. With the patch, I can export and mount nfs filesystem on the HEAD again, with all nfs* stuff loaded as modules. If following this route, sys/modules/nfs_comm= on can be removed. I did not looked into fs/nfs* modules. diff --git a/sys/modules/nfscommon/Makefile b/sys/modules/nfscommon/Makefile index a3d75a7..df8702c 100644 --- a/sys/modules/nfscommon/Makefile +++ b/sys/modules/nfscommon/Makefile @@ -1,8 +1,9 @@ # $FreeBSD$ =20 -.PATH: ${.CURDIR}/../../fs/nfs=20 +.PATH: ${.CURDIR}/../../fs/nfs ${.CURDIR}/../../nfs KMOD=3D nfscommon SRCS=3D vnode_if.h \ + nfs_common.c \ nfs_commonacl.c \ nfs_commonkrpc.c \ nfs_commonport.c \ diff --git a/sys/nfsclient/nfs_vfsops.c b/sys/nfsclient/nfs_vfsops.c index a8f32da..61cd7b8 100644 --- a/sys/nfsclient/nfs_vfsops.c +++ b/sys/nfsclient/nfs_vfsops.c @@ -147,7 +147,7 @@ MODULE_DEPEND(nfs, krpc, 1, 1, 1); #ifdef KGSSAPI MODULE_DEPEND(nfs, kgssapi, 1, 1, 1); #endif -MODULE_DEPEND(nfs, nfs_common, 1, 1, 1); +MODULE_DEPEND(nfs, nfscommon, 1, 1, 1); =20 static struct nfs_rpcops nfs_rpcops =3D { nfs_readrpc, diff --git a/sys/nfsserver/nfs_srvsubs.c b/sys/nfsserver/nfs_srvsubs.c index d84261e..f76c983 100644 --- a/sys/nfsserver/nfs_srvsubs.c +++ b/sys/nfsserver/nfs_srvsubs.c @@ -560,7 +560,7 @@ DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI= _ORDER_ANY); MODULE_VERSION(nfsserver, 1); MODULE_DEPEND(nfsserver, nfssvc, 1, 1, 1); MODULE_DEPEND(nfsserver, krpc, 1, 1, 1); -MODULE_DEPEND(nfsserver, nfs_common, 1, 1, 1); +MODULE_DEPEND(nfsserver, nfscommon, 1, 1, 1); =20 /* * Set up nameidata for a lookup() call and do it. --TOcFo/l1T3s1H/TJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkt9uhIACgkQC3+MBN1Mb4jRIQCggHO1Y2F9o6J7hmp4IdRT48AK sWoAoMmKyQnja16w7JPzmQIGvUbpiz4W =zr+x -----END PGP SIGNATURE----- --TOcFo/l1T3s1H/TJ-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 22:12:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AA7B1065676 for ; Thu, 18 Feb 2010 22:12:25 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 437CC8FC12 for ; Thu, 18 Feb 2010 22:12:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY200GDO5OOP9D0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 23:12:24 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY2006845ONI8F0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 23:12:24 +0100 (CET) Date: Thu, 18 Feb 2010 23:12:23 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100218205458.GA78560@server.vk2pj.dyndns.org> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 22:12:25 -0000 On Fri, 19 Feb 2010 07:54:58 +1100 Peter Jeremy wrote: > On 2010-Feb-17 20:03:22 +0100, Torfinn Ingolfsen wrote: > Did you delete /etc/ntp.drift between timecounter changes? I sure did, I used the instructions given. > There's ntptime(8) but it doesn't have a "self-calibrate mode". Ok, good to know. > Based on the messages log you gave, and assuming the ntpd PLL is sane, > your acpi-safe clock is about 2500ppm slow (the steps reflect about > 2000ppm and the ntpd PLL should be compensating for a further 500ppm) > - this is really bad, even for consumer-grade stuff. Are you running > non-standard clock speeds or multipliers? No, everything at default values here (ie. I haven't changed anything in either BIOS or FreeBSD), except from changing timer from HPET to ACPI-safe. > If there's nothing obvious, I'd follow John Hay's suggesion and > force set either your TSC or ACPI frequency in sysctl.conf (you > can't override the HPET frequency). > > Take either the TSC or ACPI frequency reported by "sysctl machdep", > reduce it by 2500ppm and set that in /etc/sysctl.conf. Assuming > a "standard" (3.58MHz) ACPI, the latter would look like: > > machdep.acpi_timer_freq=3570596 This one is root@kg-f2# sysctl machdep.acpi_timer_freq machdep.acpi_timer_freq: 3579545 So I should change that to 3577045, right? Like so: root@kg-f2# sysctl machdep.acpi_timer_freq=3579545 machdep.acpi_timer_freq: 3579545 -> 3579545 and I put it into /etc/sysctl.conf as well (in case the machine reboots again). > kern.timecounter.hardware=ACPI-safe Yes, this is already in /etc/sysctl.conf > The stop ntpd, delete /var/db/ntp.drift and either reboot or > manually set the above sysctl's and restart ntpd. Done. We'll see if it works or not. > [I think I've got the adjustment direction correct in the above, if > I've stuffed up, you need to adjust in the other direction] Ok. Thanks to all for helping out. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 22:25:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 215C01065693 for ; Thu, 18 Feb 2010 22:25:53 +0000 (UTC) (envelope-from scott+lists.freebsd@fishballoon.org) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4EEA68FC08 for ; Thu, 18 Feb 2010 22:25:51 +0000 (UTC) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100218222547.XDKC10950.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Thu, 18 Feb 2010 22:25:47 +0000 Received: from llama.fishballoon.org ([86.26.7.178]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100218222547.QLAE13254.aamtaout01-winn.ispmail.ntl.com@llama.fishballoon.org>; Thu, 18 Feb 2010 22:25:47 +0000 Received: from phasmid.fishballoon.org ([192.168.0.199]:41346) by llama.fishballoon.org with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NiEob-000Ens-2F; Thu, 18 Feb 2010 22:25:45 +0000 Received: by phasmid.fishballoon.org (Postfix, from userid 1000) id B8526162429F; Thu, 18 Feb 2010 22:25:44 +0000 (GMT) From: Scott Mitchell To: freebsd-stable@freebsd.org Date: Thu, 18 Feb 2010 22:25:44 +0000 User-Agent: KMail/1.9.10 References: <20091208174145.GA14312@mr-happy.com> <201002182126.41632.scott+lists.freebsd@fishballoon.org> <20100218215416.GB39863@in-addr.com> In-Reply-To: <20100218215416.GB39863@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201002182225.44433.scott+lists.freebsd@fishballoon.org> X-Cloudmark-Analysis: v=1.1 cv=ZtHxNT4mZm3rCuM0SmWmgWxeBwJsziC8EqOrwwVkrhA= c=1 sm=0 a=DRQelB6j_xIpfQUA_-UA:9 a=4Te0Tydnr1JZCUYur_8A:7 a=SWl5ru6ADVpJwaG-EEOwvKrOuhQA:4 a=AZYOg8T3qaiHbcP7:21 a=9ho9djijxANf8CiP:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Jeff Blank Subject: Re: Dell PowerEdge Virtual Media X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 22:25:53 -0000 On Thursday 18 February 2010 21:54:16 Gary Palmer wrote: > Hi, > > I'm no expert at this code, but it might be interesting to see the > results of > > cdcontrol -v info > > The code in mount_cd9660 in 7.x reads the CD/DVD table of contents > to figure out where the data segment starts. The only thing I can > guess is that the TOC data is getting munged somehow. > > Regards, > > Gary Hi Gary, Good call! On the R710 (running 8.0) with the FreeBSD/amd64 8.0-R DVD image in the virtual drive: (501) ~ $ sudo cdcontrol -v info Password: Starting track = 1, ending track = 1, TOC size = 4608 bytes track start duration block length type ------------------------------------------------- 1 0:08.62 144:07.29 512 -662 data 0 0:00.00 - -150 - - On a different machine (running 6.4) with a real DVD burned from the same image in the drive: (501) ~ $ sudo cdcontrol -v info Password: Starting track = 1, ending track = 1, TOC size = 18 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 235:08.05 0 1058105 data 170 235:10.05 - 1058105 - - Something definitely not right there. I can try with the same DVD in the internal drive on the R710 tomorrow, just in case that makes any difference. Best regards, Scott From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 23:03:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB206106566B; Thu, 18 Feb 2010 23:03:42 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 90ED48FC1A; Thu, 18 Feb 2010 23:03:42 +0000 (UTC) Received: by yxe1 with SMTP id 1so1269565yxe.3 for ; Thu, 18 Feb 2010 15:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=s58000jgt6Xc1jDTMsoddsCRerPyYGMrqetnNMNbWf4=; b=QUW4DaJ8iXp4Qaa4Zyx1JJHLs2kwgDUGtpAMGqkaxkkjfOlaxsGVF1dc2m8jcpqAGJ m2rw/ZIJYaQ7tSqUYqNEZa/gVRttnht+8DIB7tcfZG/skhPYzszqmMNK+qA0SQs5mrQn +bg6ro+vGIS1tUMbhdQQNqVT/uC0EhS01ySy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UxnEe8X9i6jTAyngz7qBc3hE9ErvHAk5GexsiFsyi5kFpbLiWuWehSb3MZvTkC/+T/ mVzGjjg+b4a8VkqX6rnDvSB36wIGej/hp/3iHAMzlx2wpN6ZIWq+7q7Cij08Bhuur6bG R+0O3VZzAMr1od8tnwhXqgKKelluRfpY4tSEY= MIME-Version: 1.0 Received: by 10.151.5.6 with SMTP id h6mr482834ybi.199.1266534221825; Thu, 18 Feb 2010 15:03:41 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2010 15:03:41 -0800 Message-ID: From: Matt Reimer To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-STABLE Mailing List , rnoland@freebsd.org Subject: Re: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 23:03:43 -0000 On Thu, Feb 18, 2010 at 10:57 AM, Matt Reimer wrote: > On Tue, Feb 16, 2010 at 12:38 AM, Dan Naumov wrote: > >> > I don't know, but I plan to test that scenario in a few days. >> > >> > Matt >> >> Please share the results when you're done, I am really curious :) >> > > Booting from a stripe of two raidz vdevs works: > > FreeBSD/i386 boot > Default: doom:/boot/zfsloader > boot: status > pool: doom > config: > > NAME STATE > doom ONLINE > raidz1 ONLINE > label/doom-0 ONLINE > label/doom-1 ONLINE > label/doom-2 ONLINE > raidz1 ONLINE > label/doom-3 ONLINE > label/doom-4 ONLINE > label/doom-5 ONLINE > > I'd guess a stripe of mirrors would work fine too. If I get a chance I'll > test that combo. > A stripe of three-way mirrors works: FreeBSD/i386 boot Default: mithril:/boot/zfsloader boot: status pool: mithril config: NAME STATE mithril ONLINE mirror ONLINE label/mithril-0 ONLINE label/mithril-1 ONLINE label/mithril-2 ONLINE mirror ONLINE label/mithril-3 ONLINE label/mithril-4 ONLINE label/mithril-5 ONLINE Matt From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 23:32:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C99FC106566B for ; Thu, 18 Feb 2010 23:32:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id AD7888FC13 for ; Thu, 18 Feb 2010 23:32:55 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta05.emeryville.ca.mail.comcast.net with comcast id jaBe1d0071zF43QA5bYwcy; Thu, 18 Feb 2010 23:32:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta24.emeryville.ca.mail.comcast.net with comcast id jbad1d0053S48mS8kbad8X; Thu, 18 Feb 2010 23:34:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 366271E301A; Thu, 18 Feb 2010 15:32:54 -0800 (PST) Date: Thu, 18 Feb 2010 15:32:54 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100218233254.GA68902@icarus.home.lan> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100218215039.GK55307@zxy.spb.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 23:32:55 -0000 On Fri, Feb 19, 2010 at 12:50:39AM +0300, Slawa Olhovchenkov wrote: > On Thu, Feb 18, 2010 at 01:32:13PM -0800, Pyun YongHyeon wrote: > > > > > dmesg output(only bge(4) related one). > > > > > > dmesg from boot: > > > > > > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > > > miibus0: on bge0 > > > brgphy0: PHY 1 on miibus0 > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > bge0: Ethernet address: 00:14:c2:3d:e5:52 > > > bge0: [ITHREAD] > > > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > > > miibus1: on bge1 > > > brgphy1: PHY 1 on miibus1 > > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > bge1: Ethernet address: 00:14:c2:3d:e5:51 > > > bge1: [ITHREAD] > > > bge1: link state changed to UP > > > bge0: link state changed to UP > > > > > > Nothing in dmesg before trap. > > > > > > > Is this PCI-X controller? It would be even better if you can post > > This integrated controller (HP DL360-G4) > > > bge(4) related dmesg output of verbosed boot and the output of > > ... > pci0:2:2:0: bad VPD cksum, remain 19 > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfdf70000 > bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X > ... > pci0:2:2:1: bad VPD cksum, remain 19 > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfdf60000 > bge1: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X Are the "bad VPD checksum" messages somehow responsible for this? They're both related to the bge(4) interfaces: > bge0@pci0:2:2:0: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 > bge1@pci0:2:2:1: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 23:38:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D1B106566B for ; Thu, 18 Feb 2010 23:38:46 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 616048FC08 for ; Thu, 18 Feb 2010 23:38:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY20018H9OLI200@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 19 Feb 2010 00:38:45 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY200C3X9OKKTC0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 19 Feb 2010 00:38:45 +0100 (CET) Date: Fri, 19 Feb 2010 00:38:44 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 23:38:46 -0000 On Thu, 18 Feb 2010 23:12:23 +0100 Torfinn Ingolfsen wrote: > So I should change that to 3577045, right? > Like so: > root@kg-f2# sysctl machdep.acpi_timer_freq=3579545 > machdep.acpi_timer_freq: 3579545 -> 3579545 Eh... I just realized that I did it wrong. well, that's what cut and paste will do to you, if you don't pay attention. ;) Ok, I will try to do it right now: root@kg-f2# sysctl machdep.acpi_timer_freq=3577045 machdep.acpi_timer_freq: 3579545 -> 3577045 root@kg-f2# /etc/rc.d/ntpd stop Stopping ntpd. root@kg-f2# ll /var/db/ntp* -rw-r--r-- 1 root wheel 8 Feb 13 20:27 /var/db/ntpd.drift root@kg-f2# rm /var/db/ntpd.drift root@kg-f2# ll /var/db/ntp* ls: /var/db/ntp*: No such file or directory root@kg-f2# /etc/rc.d/ntpd start Starting ntpd. and fixing it in /etc/sysctl.conf too. Done. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 00:19:55 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F60E106566B for ; Fri, 19 Feb 2010 00:19:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 92D328FC1D for ; Fri, 19 Feb 2010 00:19:54 +0000 (UTC) Received: by vws14 with SMTP id 14so971270vws.13 for ; Thu, 18 Feb 2010 16:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=l3z2MUTB0ybKGzquV36rgJDu2vtXWaUTwv8wU7ADpVo=; b=JzTRw5JxEAGEpXONHzgCGdGf7jxPG0MOupUpmerY/qmEPRmFNEu/toBO2b6Bo/p3V0 AUvy/LklDMybSz4jlAot0JHm6qTq+xlTDGrRXKPj2bJwAmSQOW0qfvn5vjqIUpckNoLS 2DDZ2mm5/s/TFxjRZ9lBgirRdylAQI3ZxbJcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Vp8By6YVswiFibQYkfS6vMd0UQF44veW5dTjlzL570G6ZYFgviHkr+q/S8PZ52kNTM xFdqQkZPceWPpTFeh2UDyeoB8CVmRYJIWeERG1wkS9CzMwl9dlxRvj0ue0Y1aRlre1Tc 1J5FuTL/4DM+ceyjbbr5Il1SBRi2ApTtP8UeY= Received: by 10.220.72.10 with SMTP id k10mr3605139vcj.82.1266538793705; Thu, 18 Feb 2010 16:19:53 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 41sm31755473vws.10.2010.02.18.16.19.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 16:19:52 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 18 Feb 2010 16:19:13 -0800 From: Pyun YongHyeon Date: Thu, 18 Feb 2010 16:19:13 -0800 To: Slawa Olhovchenkov Message-ID: <20100219001913.GE11675@michelle.cdnetworks.com> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="U+BazGySraz5kW0T" Content-Disposition: inline In-Reply-To: <20100218215039.GK55307@zxy.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 00:19:55 -0000 --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 19, 2010 at 12:50:39AM +0300, Slawa Olhovchenkov wrote: > On Thu, Feb 18, 2010 at 01:32:13PM -0800, Pyun YongHyeon wrote: > > > > > dmesg output(only bge(4) related one). > > > > > > dmesg from boot: > > > > > > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > > > miibus0: on bge0 > > > brgphy0: PHY 1 on miibus0 > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > bge0: Ethernet address: 00:14:c2:3d:e5:52 > > > bge0: [ITHREAD] > > > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > > > miibus1: on bge1 > > > brgphy1: PHY 1 on miibus1 > > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > bge1: Ethernet address: 00:14:c2:3d:e5:51 > > > bge1: [ITHREAD] > > > bge1: link state changed to UP > > > bge0: link state changed to UP > > > > > > Nothing in dmesg before trap. > > > > > > > Is this PCI-X controller? It would be even better if you can post > > This integrated controller (HP DL360-G4) > > > bge(4) related dmesg output of verbosed boot and the output of > > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8088e000. > Preloaded elf obj module "/boot/kernel/if_bge.ko" at 0xffffffff8088e1d0. > Preloaded elf obj module "/boot/kernel/miibus.ko" at 0xffffffff8088e7f8. > pci0:2:2:0: bad VPD cksum, remain 19 > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfdf70000 > bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: OUI 0x000818, model 0x0019, rev. 0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge0: bpf attached > bge0: Ethernet address: 00:14:c2:3d:e5:52 > ioapic1: routing intpin 1 (PCI IRQ 25) to lapic 0 vector 50 > bge0: [MPSAFE] > bge0: [ITHREAD] > pci0:2:2:1: bad VPD cksum, remain 19 > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfdf60000 > bge1: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: OUI 0x000818, model 0x0019, rev. 0 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge1: bpf attached > bge1: Ethernet address: 00:14:c2:3d:e5:51 > ioapic1: routing intpin 2 (PCI IRQ 26) to lapic 0 vector 51 > bge1: [MPSAFE] > bge1: [ITHREAD] > bge1: link UP > bge1: link state changed to UP > > > > "pciconf -lcv". > [...] > bge0@pci0:2:2:0: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' > class = network > subclass = ethernet > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction > cap 01[48] = powerspec 2 supports D0 D3 current D0 > cap 03[50] = VPD > cap 05[58] = MSI supports 8 messages, 64 bit > bge1@pci0:2:2:1: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' > class = network > subclass = ethernet > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction > cap 01[48] = powerspec 2 supports D0 D3 current D0 > cap 03[50] = VPD > cap 05[58] = MSI supports 8 messages, 64 bit I'm still not sure whether the panic is related with bge(4) but there are a couple of missing workaround for PCIX BCM5704 silicon bug in bge(4). Did you also see the panic before updating to stable/8? Anyway, try attached patch and let me know how it works. --U+BazGySraz5kW0T Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.5704.diff" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 204011) +++ sys/dev/bge/if_bge.c (working copy) @@ -1342,6 +1342,7 @@ bge_chipinit(struct bge_softc *sc) { uint32_t dma_rw_ctl; + uint16_t val; int i; /* Set endianness before we access any non-PCI registers. */ @@ -1362,6 +1363,17 @@ i < BGE_STATUS_BLOCK_END + 1; i += sizeof(uint32_t)) BGE_MEMWIN_WRITE(sc, i, 0); + if (sc->bge_chiprev == BGE_CHIPREV_5704_BX) { + /* + * Fix data corruption casued by non-qword write with WB. + * Fix master abort in PCI mode. + * Fix PCI latency timer. + */ + val = pci_read_config(sc->bge_dev, BGE_PCI_MSI_DATA + 2, 2); + val |= (1 << 10) | (1 << 12) | (1 << 13); + pci_write_config(sc->bge_dev, BGE_PCI_MSI_DATA + 2, val, 2); + } + /* * Set up the PCI DMA control register. */ @@ -3157,6 +3169,26 @@ pci_write_config(dev, BGE_PCI_CMD, command, 4); write_op(sc, BGE_MISC_CFG, BGE_32BITTIME_66MHZ); + /* + * Disable PCIX relaxed ordering to ensure status block update + * comes first than packet buffer DMA. Otherwise driver may + * read stale status block. + */ + if (sc->bge_flags & BGE_FLAG_PCIX) { + devctl = pci_read_config(dev, + sc->bge_pcixcap + PCIXR_COMMAND, 2); + devctl &= ~PCIXM_COMMAND_ERO; + if (sc->bge_asicrev == BGE_ASICREV_BCM5703) { + devctl &= ~PCIXM_COMMAND_MAX_READ; + devctl |= PCIXM_COMMAND_MAX_READ_2048; + } else if (sc->bge_asicrev == BGE_ASICREV_BCM5704) { + devctl &= ~(PCIXM_COMMAND_MAX_SPLITS | + PCIXM_COMMAND_MAX_READ); + devctl |= PCIXM_COMMAND_MAX_READ_2048; + } + pci_write_config(dev, sc->bge_pcixcap + PCIXR_COMMAND, + devctl, 2); + } /* Re-enable MSI, if neccesary, and enable the memory arbiter. */ if (BGE_IS_5714_FAMILY(sc)) { /* This chip disables MSI on reset. */ --U+BazGySraz5kW0T-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 00:36:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84E891065672; Fri, 19 Feb 2010 00:36:57 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f219.google.com (mail-gx0-f219.google.com [209.85.217.219]) by mx1.freebsd.org (Postfix) with ESMTP id 291628FC19; Fri, 19 Feb 2010 00:36:56 +0000 (UTC) Received: by gxk19 with SMTP id 19so2780922gxk.3 for ; Thu, 18 Feb 2010 16:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KLStzow1hhfLq6Y61nz/S+RKCc2kfu9F842S72U3BU0=; b=KtmfRvXFiKlqueHxHQtKmCzCjPZSu4oz4enprjGguZqLHUJi2ORnBrkx6piEKc7iiu oQdectZYEBbAi2XNMhZqAxsEktVuKMKWON2IPg2LA1HQzFpI5UPZsjNdj/u3XxMUL7zv DcaP+8hkAflnbfmNJXMLln9jNCE2yyMkCWtA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=J0Vtil+X91xMDt8yL32Zvd4a1bI1jdQ7SvNiozbIQncAp7ZJN1oWo7AVYPD1RyBvWj 7boAjoV6XDT71lt/88Fv9W+sOaNzJholR7bYZ20Me6MAODRRKjGFjoy+fMsmv4OmSRHM Tr+bwGB+z9VM3uYKHZVECML1nVCKF2TgJ7IRk= MIME-Version: 1.0 Received: by 10.101.167.16 with SMTP id u16mr10647892ano.170.1266539816326; Thu, 18 Feb 2010 16:36:56 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Feb 2010 02:36:56 +0200 Message-ID: From: Dan Naumov To: Matt Reimer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , rnoland@freebsd.org Subject: Re: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 00:36:57 -0000 On Fri, Feb 19, 2010 at 1:03 AM, Matt Reimer wrote: > On Thu, Feb 18, 2010 at 10:57 AM, Matt Reimer wro= te: >> >> On Tue, Feb 16, 2010 at 12:38 AM, Dan Naumov wrot= e: >>> >>> > I don't know, but I plan to test that scenario in a few days. >>> > >>> > Matt >>> >>> Please share the results when you're done, I am really curious :) >> >> Booting from a stripe of two raidz vdevs works: >> FreeBSD/i386 boot >> Default: doom:/boot/zfsloader >> boot: status >> pool: doom >> config: >> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NAME =A0 =A0 =A0STATE >> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0doom =A0 =A0 ONLINE >> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0raidz1 =A0 =A0 ONLINE >> =A0=A0 =A0 =A0 =A0 =A0 =A0label/doom-0 =A0 =A0 ONLINE >> =A0=A0 =A0 =A0 =A0 =A0 =A0label/doom-1 =A0 =A0 ONLINE >> =A0=A0 =A0 =A0 =A0 =A0 =A0label/doom-2 =A0 =A0 ONLINE >> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0raidz1 =A0 =A0 ONLINE >> =A0=A0 =A0 =A0 =A0 =A0 =A0label/doom-3 =A0 =A0 ONLINE >> =A0=A0 =A0 =A0 =A0 =A0 =A0label/doom-4 =A0 =A0 ONLINE >> =A0=A0 =A0 =A0 =A0 =A0 =A0label/doom-5 =A0 =A0 ONLINE >> I'd guess a stripe of mirrors would work fine too. If I get a chance I'l= l >> test that combo. > > A stripe of three-way mirrors works: > FreeBSD/i386 boot > Default: mithril:/boot/zfsloader > boot: status > pool: mithril > config: > =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NAME =A0 =A0 =A0STATE > =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mithril =A0 =A0 ONLINE > =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mirror =A0 =A0 ONLINE > =A0=A0 =A0 =A0 =A0 =A0 =A0label/mithril-0 =A0 =A0 ONLINE > =A0=A0 =A0 =A0 =A0 =A0 =A0label/mithril-1 =A0 =A0 ONLINE > =A0=A0 =A0 =A0 =A0 =A0 =A0label/mithril-2 =A0 =A0 ONLINE > =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mirror =A0 =A0 ONLINE > =A0=A0 =A0 =A0 =A0 =A0 =A0label/mithril-3 =A0 =A0 ONLINE > =A0=A0 =A0 =A0 =A0 =A0 =A0label/mithril-4 =A0 =A0 ONLINE > =A0=A0 =A0 =A0 =A0 =A0 =A0label/mithril-5 =A0 =A0 ONLINE > Matt A stripe of 3-way mirrors, whoa. Out of curiosity, what is the system used for? I am not doubting that there exist some uses/workloads for a system that uses 6 disks with 2 disks worth of usable space, but that's a bit of an unusual configuration. What are your system/disc specs and what kind of performance are you seeing from the pool? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 00:42:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFC5D1065694 for ; Fri, 19 Feb 2010 00:42:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f189.google.com (mail-qy0-f189.google.com [209.85.221.189]) by mx1.freebsd.org (Postfix) with ESMTP id 9DDCB8FC08 for ; Fri, 19 Feb 2010 00:42:51 +0000 (UTC) Received: by qyk27 with SMTP id 27so6126647qyk.3 for ; Thu, 18 Feb 2010 16:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=3TD9ocLxv9YwJ8FRrb2YZYQfXUyKEeSKpeN1RS2Nonk=; b=IbBazV+2+0pZMD/Z562JF/5USXgA5e+Xr9rlP+joAKe/FsePyqWs+Rug1M6LCrXd47 kBsISRlL6awI810O/bcpXhzT2yHZdgmnYQtECZdMUn+cCIvic4jerzUWcvZk2RDI6cz2 AyZJxzUgWDEhRISAyiXf8905kc7zWLPCHP06g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=iixcBqahYjbMLAsFub8ZXZrByK1+aDtTW0WkDS5AgvPV78um/BCEhEuuE0c5LyAy3s ZjtykYCvTaMK9oNR4DDK5JU+knmaBuJCb07QivaTpk4BjtgiSaMuhIEg6KuTQynw4bNu KWPAMBYWn038O+hjuVvPWEb+/Lhl0VAqn/HG4= Received: by 10.224.14.66 with SMTP id f2mr2971327qaa.233.1266540170819; Thu, 18 Feb 2010 16:42:50 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm7079893qyk.0.2010.02.18.16.42.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 16:42:49 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 18 Feb 2010 16:42:10 -0800 From: Pyun YongHyeon Date: Thu, 18 Feb 2010 16:42:10 -0800 To: Jeremy Chadwick Message-ID: <20100219004210.GF11675@michelle.cdnetworks.com> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100218233254.GA68902@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100218233254.GA68902@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 00:42:52 -0000 On Thu, Feb 18, 2010 at 03:32:54PM -0800, Jeremy Chadwick wrote: > On Fri, Feb 19, 2010 at 12:50:39AM +0300, Slawa Olhovchenkov wrote: > > On Thu, Feb 18, 2010 at 01:32:13PM -0800, Pyun YongHyeon wrote: > > > > > > > dmesg output(only bge(4) related one). > > > > > > > > dmesg from boot: > > > > > > > > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > > > > miibus0: on bge0 > > > > brgphy0: PHY 1 on miibus0 > > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > > bge0: Ethernet address: 00:14:c2:3d:e5:52 > > > > bge0: [ITHREAD] > > > > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > > > > miibus1: on bge1 > > > > brgphy1: PHY 1 on miibus1 > > > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > > bge1: Ethernet address: 00:14:c2:3d:e5:51 > > > > bge1: [ITHREAD] > > > > bge1: link state changed to UP > > > > bge0: link state changed to UP > > > > > > > > Nothing in dmesg before trap. > > > > > > > > > > Is this PCI-X controller? It would be even better if you can post > > > > This integrated controller (HP DL360-G4) > > > > > bge(4) related dmesg output of verbosed boot and the output of > > > > ... > > pci0:2:2:0: bad VPD cksum, remain 19 > > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfdf70000 > > bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X > > ... > > pci0:2:2:1: bad VPD cksum, remain 19 > > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > > bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfdf60000 > > bge1: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X > > Are the "bad VPD checksum" messages somehow responsible for this? > They're both related to the bge(4) interfaces: > > > bge0@pci0:2:2:0: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 > > bge1@pci0:2:2:1: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 > Driver tries to read VPD from controller but it seems it failed to fully parse the data. But it managed to get PN part so it successfully extracted device name string from the controller. I don't think this is related with driver instability though. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 03:19:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56AB51065672; Fri, 19 Feb 2010 03:19:56 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id DB5128FC08; Fri, 19 Feb 2010 03:19:55 +0000 (UTC) Received: by yxe2 with SMTP id 2so9195460yxe.7 for ; Thu, 18 Feb 2010 19:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=O+HQSnmRgNWHcSE51bGlMwKG/Kw/HyRI4eDhUilKw0U=; b=QG7EhcDWmX/H0UPtsFoZ3/1ZAscx2jaGoHs3sUC+hB5J6VsKE6qZ/WYwM20sAzVHmW sTxjGC50kZusmPp037eWvLQooEFVI9d5IIVLqihUvxfeh+w32OO3kuBKq0k2YQC72T2T NH34SI9YNHDTdF+Mmo82oWs4mcL5jFXUxoJio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SM6HrmZKlPJJ8X68GL4qMHbLviGWVei1DGGKtS76mgsh31lqPgI+TsVLr5nOi7xM9h aM85bmyD4xjikANduRQJCSDdkwqkARMJcSYQTjfka0Oz36ZaXFY3GHGU5+BIHPtUf3iZ XxsxMWm4MJonX8g61fKI9U2EOlMwrOT+M7TQs= MIME-Version: 1.0 Received: by 10.150.118.11 with SMTP id q11mr578965ybc.40.1266549594927; Thu, 18 Feb 2010 19:19:54 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2010 19:19:54 -0800 Message-ID: From: Matt Reimer To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-STABLE Mailing List , rnoland@freebsd.org Subject: Re: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 03:19:56 -0000 On Thu, Feb 18, 2010 at 4:36 PM, Dan Naumov wrote: > > A stripe of 3-way mirrors, whoa. Out of curiosity, what is the system > used for? I am not doubting that there exist some uses/workloads for a > system that uses 6 disks with 2 disks worth of usable space, but > that's a bit of an unusual configuration. What are your system/disc > specs and what kind of performance are you seeing from the pool? > It's for a reasonably busy webserver hosting a few hundred domains, which tends to be somewhat seek-intensive. For this pool we had two main criteria: speed and double-disk redundancy. A stripe of three two-way mirrors would only give us single-disk redundancy in the worst case (i.e. losing both disks in one of the mirrors), so we went with two three-way mirrors instead. Even though we're only getting the capacity of two disks worth of space, we'll still have 6x the capacity of the array it's replacing. A simple-minded dd test gives me ~180MB/s writing a single long file, and 400-500MB/s reading. Matt From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 05:51:33 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33D0C106566B for ; Fri, 19 Feb 2010 05:51:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id E17EA8FC0A for ; Fri, 19 Feb 2010 05:51:31 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NiLlx-000DLH-RQ; Fri, 19 Feb 2010 08:51:29 +0300 Date: Fri, 19 Feb 2010 08:51:29 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100219055129.GL55307@zxy.spb.ru> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219001913.GE11675@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 05:51:33 -0000 On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote: > > I'm still not sure whether the panic is related with bge(4) but > there are a couple of missing workaround for PCIX BCM5704 silicon > bug in bge(4). Did you also see the panic before updating to > stable/8? Before updating to stable/8 2010-Feb-16 I see network freez on stable/8 2009-Sep -- bge stop receiving packets (by tcpdump), after aprox. 40-50 days uptime. > Anyway, try attached patch and let me know how it works. Thanks, I try. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 09:11:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D19B1065672; Fri, 19 Feb 2010 09:11:40 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 285128FC12; Fri, 19 Feb 2010 09:11:40 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o1J9BXNq017666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 01:11:33 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o1J9BX1r017665; Fri, 19 Feb 2010 01:11:33 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08562; Fri, 19 Feb 10 01:06:40 PST Date: Fri, 19 Feb 2010 01:03:37 -0800 From: perryh@pluto.rain.com To: hawei@free.fr, ivoras@freebsd.org Message-Id: <4b7e53e9.ncAxiSQAvpijczMn%perryh@pluto.rain.com> References: <20100218152601.GA3076@pollux.local.net> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Incorrect super block X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 09:11:40 -0000 Ivan Voras wrote: > On 02/18/10 16:26, Harald Weis wrote: > > Has anybody encountered the following problem ? > > > > Mac OS X does recognize FreeBSD partitions on USB disks, but > > doesn't want to mount them because ``Incorrect super block''. > > This is extremely annoying for my ``client'' because he relies > > on dayly backups on USB keys. Is there a solution ? > > Are you using UFS1 or UFS2? If one, try the other :) This is not the first time I've heard of one OS having problems with another OS' instantiation of UFS. For the particular application at hand, I'd use tar(1) to collect the files into a single stream and write the tarfile onto a USB key formatted as FAT32. OS X should have no trouble reading a FreeBSD tarfile. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 10:51:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D53B61065670 for ; Fri, 19 Feb 2010 10:51:25 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 59E888FC1D for ; Fri, 19 Feb 2010 10:51:24 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1JApN5b047173 for ; Fri, 19 Feb 2010 12:51:23 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B7E6D26.9000704@eng.auth.gr> Date: Fri, 19 Feb 2010 12:51:18 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B74502C.3080906@eng.auth.gr> <4B75D4C4.10400@eng.auth.gr> <4B7BC74C.702@eng.auth.gr> In-Reply-To: <4B7BC74C.702@eng.auth.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 10:51:25 -0000 On 17/02/2010 12:39, George Mamalakis wrote: > On 13/02/2010 00:23, George Mamalakis wrote: >> On 12/2/2010 8:48 πμ, jhell wrote: >>> >>> >>> This is a lot of information to consume. >>> >>> Lets start with this: >>> >>> All of the machines in question are of some form of FreeBSD 8. >>> >>> You enter gdb and very clearly it starts whining about a segfault & >>> libc.so.7 >>> >>> Did you happen to upgrade these clients & server from FreeBSD 7 ? >>> >>> AFAIK the libc version on FreeBSD 8 was bumped to libc.so.8 >>> >>> If you upgraded and from source did you run make delete-old and make >>> delete-old-libs after your make install and after your mergemaster ? >>> >>> Will wait here for results. >>> >>> Best wishes. >>> >> > Guys(?!), > > anybody having taken a look at the issue or has an opinion/workaround > whatsoever? > > Thanks again. > > mamalos > I've setup a linux client with the latest arch linux, I installed openldap 2.4.21-2, cyrus-sasl 2.1.23-3 and cyrus-sasl-plugins 2.1.23-1 using pacman, I configured /etc/krb5.conf and /etc/openldap/ldap.conf to read the same as in my other boxes, and tested ldapwhoami before and after kiniting to mamalos, and everything worked alright. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 12:24:18 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C918106568D for ; Fri, 19 Feb 2010 12:24:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 356108FC2A for ; Fri, 19 Feb 2010 12:24:17 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NiRu3-000KCv-Ia; Fri, 19 Feb 2010 15:24:15 +0300 Date: Fri, 19 Feb 2010 15:24:15 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100219122415.GR55307@zxy.spb.ru> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219055129.GL55307@zxy.spb.ru> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 12:24:18 -0000 On Fri, Feb 19, 2010 at 08:51:29AM +0300, Slawa Olhovchenkov wrote: > On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote: > > > > > I'm still not sure whether the panic is related with bge(4) but > > there are a couple of missing workaround for PCIX BCM5704 silicon > > bug in bge(4). Did you also see the panic before updating to > > stable/8? > > Before updating to stable/8 2010-Feb-16 I see network freez on stable/8 > 2009-Sep -- bge stop receiving packets (by tcpdump), after aprox. 40-50 > days uptime. > > > > Anyway, try attached patch and let me know how it works. > > Thanks, I try. > I don't get trap after 2 hour, but already see next trouble: === PING 10.200.0.1 (10.200.0.1): 56 data bytes --- 10.200.0.1 ping statistics --- 100 packets transmitted, 97 packets received, 3.0% packet loss round-trip min/avg/max/stddev = 0.188/0.268/0.356/0.044 ms === w/o patch, but witch fresh source I see same trouble: after 12 hour 7% lost. netstat -i don't show any errors. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 15:13:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F4D4106566C for ; Fri, 19 Feb 2010 15:13:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EE3A98FC14 for ; Fri, 19 Feb 2010 15:13:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIc5fkuDaFvH/2dsb2JhbACbB3S9c4RnBIMV X-IronPort-AV: E=Sophos;i="4.49,503,1262581200"; d="scan'208";a="65956876" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 19 Feb 2010 10:13:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 946AC108455C; Fri, 19 Feb 2010 10:13:39 -0500 (EST) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJV8nyMiCzG1; Fri, 19 Feb 2010 10:13:32 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 5877610847E1; Fri, 19 Feb 2010 10:09:55 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1JFLbO19030; Fri, 19 Feb 2010 10:21:37 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 19 Feb 2010 10:21:37 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kostik Belousov In-Reply-To: <20100218220714.GU50403@deviant.kiev.zoral.com.ua> Message-ID: References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> <20100218220714.GU50403@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marius@freebsd.org, Boris Kochergin , FreeBSD-STABLE Mailing List Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 15:13:44 -0000 On Fri, 19 Feb 2010, Kostik Belousov wrote: [stuff snipped] > > I think this is changed in HEAD, and part of the changes are already in > stable/8, which is different from 8.0 too. > > Anyway, for HEAD nfsserver we need 1. nfscommon 2. nfs_common. Also, > nfs_common module is not attached to the build. > > The patch below gives up on nfs_common, puts that parts into nfscommon, > and corrects dependencies for nfsserver and nfsclient. With the patch, > I can export and mount nfs filesystem on the HEAD again, with all > nfs* stuff loaded as modules. If following this route, sys/modules/nfs_common > can be removed. > > I did not looked into fs/nfs* modules. > The common module for fs/nfs* is called nfscommon, which was why Marius used nfs_common. I don't know what happens when you have two modules of the same name. I suspect your fix is fine otherwise, since the experimental stuff (fs/nfs*) won't get loaded unless "-e" is used on mountd/nfsd. Thanks for the help with this, rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 15:29:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A81E4106568D; Fri, 19 Feb 2010 15:29:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0538FC08; Fri, 19 Feb 2010 15:29:39 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1JFT3Yk037152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 17:29:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o1JFT3xs057734; Fri, 19 Feb 2010 17:29:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o1JFT2kt057733; Fri, 19 Feb 2010 17:29:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Feb 2010 17:29:02 +0200 From: Kostik Belousov To: Rick Macklem Message-ID: <20100219152902.GZ50403@deviant.kiev.zoral.com.ua> References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> <20100218220714.GU50403@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TXv8ADjWKuT9E31y" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: marius@freebsd.org, Boris Kochergin , FreeBSD-STABLE Mailing List Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 15:29:40 -0000 --TXv8ADjWKuT9E31y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2010 at 10:21:37AM -0500, Rick Macklem wrote: >=20 >=20 > On Fri, 19 Feb 2010, Kostik Belousov wrote: >=20 > [stuff snipped] > > > >I think this is changed in HEAD, and part of the changes are already in > >stable/8, which is different from 8.0 too. > > > >Anyway, for HEAD nfsserver we need 1. nfscommon 2. nfs_common. Also, > >nfs_common module is not attached to the build. > > > >The patch below gives up on nfs_common, puts that parts into nfscommon, > >and corrects dependencies for nfsserver and nfsclient. With the patch, > >I can export and mount nfs filesystem on the HEAD again, with all > >nfs* stuff loaded as modules. If following this route,=20 > >sys/modules/nfs_common > >can be removed. > > > >I did not looked into fs/nfs* modules. > > > The common module for fs/nfs* is called nfscommon, which was why Marius > used nfs_common. I don't know what happens when you have two modules of > the same name. I suspect your fix is fine otherwise, since the=20 I do not introduce new module, I added symbols from nfs_common to nfscommon, indending to remove sys/modules/nfs_common from src, since it is not attached to the build even without the patch. It seems that there is no name conflicts between newnfs symbols from this combined module and old nfs server and client. I did not checked possible name conflicts between this nfscommon and fs/nfs*, that is what I mean by "not looked into ...". > experimental stuff (fs/nfs*) won't get loaded unless "-e" is used on > mountd/nfsd. >=20 > Thanks for the help with this, rick --TXv8ADjWKuT9E31y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkt+rj4ACgkQC3+MBN1Mb4jZQgCeMr8piSoUSyucnrSr0RtGTa5F YNgAoKtYOh7oyeJsKlZwa3r5LOGQMsEY =W/+e -----END PGP SIGNATURE----- --TXv8ADjWKuT9E31y-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 15:44:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76C491065672 for ; Fri, 19 Feb 2010 15:44:51 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id F1EB38FC13 for ; Fri, 19 Feb 2010 15:44:50 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1JFinOL052656 for ; Fri, 19 Feb 2010 17:44:49 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B7EB1E5.3080907@eng.auth.gr> Date: Fri, 19 Feb 2010 17:44:37 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: mountd segfaults in NFSv4 if -alldirs is present in exports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 15:44:51 -0000 Hi all, the title explains it all... But ok, let's be a bit more extensive. If I have one line in /etc/exports reading: V4: / -alldirs and try to start mountd, it segfaults with signal 11. From the manpage I read that -alldirs is the "second method" used to export a filesystem and V4 is the "third", maybe implying that they are mutually exclusive. Nevertheless, I suppose that mountd shouldn't segfault in my case, it could just refuse to start giving an error message or something. I've tried a different /etc/exports containing a dummy option -dummy instead of -alldirs and mountd won't segfault, hence there's no problem with its parser. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 15:51:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 648FB106566C for ; Fri, 19 Feb 2010 15:51:47 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id C5E2C8FC19 for ; Fri, 19 Feb 2010 15:51:46 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1JFpjTV071456 for ; Fri, 19 Feb 2010 17:51:45 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B7EB387.5010107@eng.auth.gr> Date: Fri, 19 Feb 2010 17:51:35 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B7EB1E5.3080907@eng.auth.gr> In-Reply-To: <4B7EB1E5.3080907@eng.auth.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: mountd segfaults in NFSv4 if -alldirs is present in exports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 15:51:47 -0000 On 19/02/2010 17:44, George Mamalakis wrote: > Hi all, > > the title explains it all... > > But ok, let's be a bit more extensive. > > If I have one line in /etc/exports reading: > > V4: / -alldirs > > and try to start mountd, it segfaults with signal 11. From the manpage > I read that -alldirs is the "second method" used to export a > filesystem and V4 is the "third", maybe implying that they are > mutually exclusive. Nevertheless, I suppose that mountd shouldn't > segfault in my case, it could just refuse to start giving an error > message or something. I've tried a different /etc/exports containing a > dummy option -dummy instead of -alldirs and mountd won't segfault, > hence there's no problem with its parser. > oops, forgotten system info: # uname -a FreeBSD lala 8.0-STABLE FreeBSD 8.0-STABLE #0: Fri Feb 19 11:45:56 EET 2010 root@lala:/usr/obj/usr/src/sys/MAMALOPYRINO-NFS4 i386 my custom kernel has the follwoing differences from GENERIC: # diff GENERIC MAMALOPYRINO-NFS4 21,22c21,22 < cpu I486_CPU < cpu I586_CPU --- > #cpu I486_CPU > #cpu I586_CPU 24c24 < ident GENERIC --- > ident MAMALOPYRINO-NFS4 49c49,50 < options NFSSERVER # Network Filesystem Server --- > options NFSD # Network Filesystem Server > #options NFSSERVER # Network Filesystem Server 332c333 < device firewire # FireWire bus code --- > #device firewire # FireWire bus code 334,337c335,338 < device fwe # Ethernet over FireWire (non-standard!) < device fwip # IP over FireWire (RFC 2734,3146) < device dcons # Dumb console driver < device dcons_crom # Configuration ROM for dcons --- > #device fwe # Ethernet over FireWire (non-standard!) > #device fwip # IP over FireWire (RFC 2734,3146) > #device dcons # Dumb console driver > #device dcons_crom # Configuration ROM for dcons Which means that I have all firewire commented out (since fbsd8 kernel panics on my msi gt627 otherwise, but that's another issue), and I have NFSD instead of NFSSERVER as an option. Cheers all. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 15:53:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 607A9106568B for ; Fri, 19 Feb 2010 15:53:38 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C869B8FC1A for ; Fri, 19 Feb 2010 15:53:37 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o1JFqaAx056859; Fri, 19 Feb 2010 16:52:37 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o1JFqZv3056858; Fri, 19 Feb 2010 16:52:35 +0100 (CET) (envelope-from marius) Date: Fri, 19 Feb 2010 16:52:35 +0100 From: Marius Strobl To: Kostik Belousov Message-ID: <20100219155235.GU50825@alchemy.franken.de> References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> <20100218220714.GU50403@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100218220714.GU50403@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: Boris Kochergin , FreeBSD-STABLE Mailing List , Rick Macklem Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 15:53:38 -0000 On Fri, Feb 19, 2010 at 12:07:14AM +0200, Kostik Belousov wrote: > On Thu, Feb 18, 2010 at 03:00:28PM -0500, Boris Kochergin wrote: > > Rick Macklem wrote: > > > > > > > > >On Thu, 18 Feb 2010, Boris Kochergin wrote: > > > > > >>Ahoy. I didn't get any replies to this on -net, so I thought I'd try > > >>here. I have an 8.0-RELEASE-p2/amd64 machine running a custom kernel > > >>(configuration file at http://acm.poly.edu/~spawk/ACM) and I am > > >>unable to use the NFS server module on it. After loading the nfssvc > > >>module, attempting to load the nfsserver module fails and the > > >>following appears in dmesg: > > >> > > >>Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create > > >>undefined > > >>Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type > > >> > > >>I see a reference to the problem at > > >>http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.html. > > >>Am I missing something or has it never gotten resolved? Thanks. > > >> > > >I don't know diddly about the module loading stuff, but you could try > > >this patch. (svcpool_create() is a part of the krpc, which is listed > > >as a module that nfsserver depends on) > > > > > >rick > > >--- untested patch for nfs_srvsubs.c --- > > >--- nfsserver/nfs_srvsubs.c.sav 2010-02-18 14:41:52.000000000 -0500 > > >+++ nfsserver/nfs_srvsubs.c 2010-02-18 14:42:12.000000000 -0500 > > >@@ -554,7 +554,7 @@ > > > nfsrv_modevent, > > > NULL, > > > }; > > >-DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_ANY); > > >+DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_FIRST); > > > > > > /* So that loader and kldload(2) can find us, wherever we are.. */ > > > MODULE_VERSION(nfsserver, 1); > > Thanks for the patch, but the problem persists with it, I'm afraid. > > I think this is changed in HEAD, and part of the changes are already in > stable/8, which is different from 8.0 too. > > Anyway, for HEAD nfsserver we need 1. nfscommon 2. nfs_common. Could you please elaborate on why nfsserver requires the former? At least as far as svcpool_create() is concerned I see no reason why it should require nfscommon. Also, when testing r203968 the following list of modules where sufficient to have both nfsclient and nfsserver working: krpc.ko nfs_common.ko nfsclient.ko nfslockd.ko nfsserver.ko nfssvc.ko Marius From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 16:03:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 904031065672; Fri, 19 Feb 2010 16:03:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA068FC0A; Fri, 19 Feb 2010 16:03:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD9FfkuDaFvK/2dsb2JhbACbB3S+I4RnBIMV X-IronPort-AV: E=Sophos;i="4.49,504,1262581200"; d="scan'208";a="65963638" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 19 Feb 2010 11:03:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 5A38F109C2BA; Fri, 19 Feb 2010 11:03:16 -0500 (EST) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tUv2LnqDzoE; Fri, 19 Feb 2010 11:03:16 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id E29BB109C31A; Fri, 19 Feb 2010 11:03:15 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1JGEwr25743; Fri, 19 Feb 2010 11:14:58 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 19 Feb 2010 11:14:58 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kostik Belousov In-Reply-To: <20100219152902.GZ50403@deviant.kiev.zoral.com.ua> Message-ID: References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> <20100218220714.GU50403@deviant.kiev.zoral.com.ua> <20100219152902.GZ50403@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marius@freebsd.org, Boris Kochergin , FreeBSD-STABLE Mailing List Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 16:03:17 -0000 On Fri, 19 Feb 2010, Kostik Belousov wrote: > I do not introduce new module, I added symbols from nfs_common to > nfscommon, indending to remove sys/modules/nfs_common from src, since it > is not attached to the build even without the patch. It seems that there > is no name conflicts between newnfs symbols from this combined module > and old nfs server and client. > > I did not checked possible name conflicts between this nfscommon > and fs/nfs*, that is what I mean by "not looked into ...". > Okay, I see that now. (I'm a bit slow:-) I don't think there will be any name conflicts in nfscommon, since you can build a kernel with both NFSSERVER and NFSD and they would show up multiply defined otherwise. I think that sys/nfsclient also has to be changed to use nfscommon and checked? rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 16:07:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE00106566B; Fri, 19 Feb 2010 16:07:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AF9718FC08; Fri, 19 Feb 2010 16:07:06 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1JG6vpS040874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 18:06:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o1JG6veJ057878; Fri, 19 Feb 2010 18:06:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o1JG6v7x057877; Fri, 19 Feb 2010 18:06:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Feb 2010 18:06:57 +0200 From: Kostik Belousov To: Rick Macklem Message-ID: <20100219160657.GA50403@deviant.kiev.zoral.com.ua> References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> <20100218220714.GU50403@deviant.kiev.zoral.com.ua> <20100219152902.GZ50403@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+0KmLy8UubQqhxHi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: marius@freebsd.org, Boris Kochergin , FreeBSD-STABLE Mailing List Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 16:07:07 -0000 --+0KmLy8UubQqhxHi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2010 at 11:14:58AM -0500, Rick Macklem wrote: >=20 >=20 > On Fri, 19 Feb 2010, Kostik Belousov wrote: >=20 > >I do not introduce new module, I added symbols from nfs_common to > >nfscommon, indending to remove sys/modules/nfs_common from src, since it > >is not attached to the build even without the patch. It seems that there > >is no name conflicts between newnfs symbols from this combined module > >and old nfs server and client. > > > >I did not checked possible name conflicts between this nfscommon > >and fs/nfs*, that is what I mean by "not looked into ...". > > > Okay, I see that now. (I'm a bit slow:-) I don't think there will > be any name conflicts in nfscommon, since you can build a kernel > with both NFSSERVER and NFSD and they would show up multiply > defined otherwise. >=20 > I think that sys/nfsclient also has to be changed to use nfscommon > and checked? It was changed, see sys/nfsclient/nfs_vfsops.c chunk in the patch. I tested it by mounting localhost:/usr/home over /mnt. --+0KmLy8UubQqhxHi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkt+tyAACgkQC3+MBN1Mb4gXUwCgl4zo3mLOPxLCFLQ0PkuepjbI ENYAoLIr2zrd9d+uCe3Nc0XUmJauTbDF =yDtw -----END PGP SIGNATURE----- --+0KmLy8UubQqhxHi-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 16:12:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0CAF1065679 for ; Fri, 19 Feb 2010 16:12:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A8A698FC12 for ; Fri, 19 Feb 2010 16:12:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAONGfkuDaFvJ/2dsb2JhbACbB3S+EIRnBIMV X-IronPort-AV: E=Sophos;i="4.49,504,1262581200"; d="scan'208";a="66153578" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 19 Feb 2010 11:12:53 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id CECE7FB808C; Fri, 19 Feb 2010 11:12:53 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biBhO15c6FdH; Fri, 19 Feb 2010 11:12:52 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 7115EFB80D9; Fri, 19 Feb 2010 11:12:52 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1JGOY327467; Fri, 19 Feb 2010 11:24:34 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 19 Feb 2010 11:24:34 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B7EB1E5.3080907@eng.auth.gr> Message-ID: References: <4B7EB1E5.3080907@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable Subject: Re: mountd segfaults in NFSv4 if -alldirs is present in exports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 16:12:55 -0000 On Fri, 19 Feb 2010, George Mamalakis wrote: > Hi all, > > the title explains it all... > > But ok, let's be a bit more extensive. > > If I have one line in /etc/exports reading: > > V4: / -alldirs > > and try to start mountd, it segfaults with signal 11. From the manpage I read > that -alldirs is the "second method" used to export a filesystem and V4 is > the "third", maybe implying that they are mutually exclusive. Nevertheless, I > suppose that mountd shouldn't segfault in my case, it could just refuse to > start giving an error message or something. I've tried a different > /etc/exports containing a dummy option -dummy instead of -alldirs and mountd > won't segfault, hence there's no problem with its parser. > The "V4:" line does not export a file system. It only specifies where the "root" is for NFSv4 and what clients/security flavours are supported for the NFSv4 lock state Ops that aren't associated with any file handle is. (There can be multiple V4: lines for different hosts, but they should differ in their "-sec" specification and only that.) The file systems must still be exported by separate lines, just like NFSv2,3. It happens that "-alldirs" always applies to NFSv4, since it does not use the Mount protocol and can mount anything under the "root" that has been exported. As such, "-sec" plus the ones related to specifying host(s) "-network, -mask" are the only ones that should be in the "V4:" line(s). But, of course it shouldn't segfault. I'll put that on my to do list. Thanks for reporting it, rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 16:15:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46132106566B; Fri, 19 Feb 2010 16:15:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id CFB928FC1D; Fri, 19 Feb 2010 16:15:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJdHfkuDaFvI/2dsb2JhbACbB3S+EYRnBIMV X-IronPort-AV: E=Sophos;i="4.49,504,1262581200"; d="scan'208";a="65965461" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 19 Feb 2010 11:15:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 1CEB89400EA; Fri, 19 Feb 2010 11:15:27 -0500 (EST) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iodAWlEhajJ5; Fri, 19 Feb 2010 11:15:26 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 5E81B940074; Fri, 19 Feb 2010 11:15:26 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1JGR8X28166; Fri, 19 Feb 2010 11:27:08 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 19 Feb 2010 11:27:08 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kostik Belousov In-Reply-To: <20100219160657.GA50403@deviant.kiev.zoral.com.ua> Message-ID: References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> <20100218220714.GU50403@deviant.kiev.zoral.com.ua> <20100219152902.GZ50403@deviant.kiev.zoral.com.ua> <20100219160657.GA50403@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marius@freebsd.org, Boris Kochergin , FreeBSD-STABLE Mailing List Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 16:15:28 -0000 On Fri, 19 Feb 2010, Kostik Belousov wrote: > > It was changed, see sys/nfsclient/nfs_vfsops.c chunk in the patch. > I tested it by mounting localhost:/usr/home over /mnt. > Oops, sorry for the noise. Me being slow again:-) rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 17:44:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 771C5106568B for ; Fri, 19 Feb 2010 17:44:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CBB078FC12 for ; Fri, 19 Feb 2010 17:44:32 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1JHgu63049784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 19:42:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o1JHgul1058201; Fri, 19 Feb 2010 19:42:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o1JHguTg058200; Fri, 19 Feb 2010 19:42:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Feb 2010 19:42:56 +0200 From: Kostik Belousov To: Marius Strobl Message-ID: <20100219174256.GB50403@deviant.kiev.zoral.com.ua> References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> <20100218220714.GU50403@deviant.kiev.zoral.com.ua> <20100219155235.GU50825@alchemy.franken.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B2XwZuBUJ8PPSpsy" Content-Disposition: inline In-Reply-To: <20100219155235.GU50825@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Boris Kochergin , FreeBSD-STABLE Mailing List , Rick Macklem Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 17:44:33 -0000 --B2XwZuBUJ8PPSpsy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2010 at 04:52:35PM +0100, Marius Strobl wrote: > On Fri, Feb 19, 2010 at 12:07:14AM +0200, Kostik Belousov wrote: > > On Thu, Feb 18, 2010 at 03:00:28PM -0500, Boris Kochergin wrote: > > > Rick Macklem wrote: > > > > > > > > > > > >On Thu, 18 Feb 2010, Boris Kochergin wrote: > > > > > > > >>Ahoy. I didn't get any replies to this on -net, so I thought I'd tr= y=20 > > > >>here. I have an 8.0-RELEASE-p2/amd64 machine running a custom kerne= l=20 > > > >>(configuration file at http://acm.poly.edu/~spawk/ACM) and I am=20 > > > >>unable to use the NFS server module on it. After loading the nfssvc= =20 > > > >>module, attempting to load the nfsserver module fails and the=20 > > > >>following appears in dmesg: > > > >> > > > >>Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create=20 > > > >>undefined > > > >>Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type > > > >> > > > >>I see a reference to the problem at=20 > > > >>http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025= .html.=20 > > > >>Am I missing something or has it never gotten resolved? Thanks. > > > >> > > > >I don't know diddly about the module loading stuff, but you could try > > > >this patch. (svcpool_create() is a part of the krpc, which is listed > > > >as a module that nfsserver depends on) > > > > > > > >rick > > > >--- untested patch for nfs_srvsubs.c --- > > > >--- nfsserver/nfs_srvsubs.c.sav 2010-02-18 14:41:52.000000000 -05= 00 > > > >+++ nfsserver/nfs_srvsubs.c 2010-02-18 14:42:12.000000000 -0500 > > > >@@ -554,7 +554,7 @@ > > > > nfsrv_modevent, > > > > NULL, > > > > }; > > > >-DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_ANY); > > > >+DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_FIRST= ); > > > > > > > > /* So that loader and kldload(2) can find us, wherever we are.. */ > > > > MODULE_VERSION(nfsserver, 1); > > > Thanks for the patch, but the problem persists with it, I'm afraid. > >=20 > > I think this is changed in HEAD, and part of the changes are already in > > stable/8, which is different from 8.0 too. > >=20 > > Anyway, for HEAD nfsserver we need 1. nfscommon 2. nfs_common. >=20 > Could you please elaborate on why nfsserver requires the former? Not any more. I did a check yesterday on the outdated tree without realizing this. Sorry. > At least as far as svcpool_create() is concerned I see no reason > why it should require nfscommon. Also, when testing r203968 the > following list of modules where sufficient to have both nfsclient > and nfsserver working: > krpc.ko > nfs_common.ko > nfsclient.ko > nfslockd.ko > nfsserver.ko > nfssvc.ko I confirm. So the only thing missing ATM is to actually add nfs_common.ko to the build. diff --git a/sys/modules/Makefile b/sys/modules/Makefile index 06a4a5d..caa9f3c 100644 --- a/sys/modules/Makefile +++ b/sys/modules/Makefile @@ -194,6 +194,7 @@ SUBDIR=3D ${_3dfx} \ ${_ndis} \ ${_netgraph} \ ${_nfe} \ + nfs_common \ nfscl \ nfsclient \ nfscommon \ --B2XwZuBUJ8PPSpsy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkt+zZ8ACgkQC3+MBN1Mb4jndgCg98jX0fcCrgh45KX/P7OdDQQd Dn8An3Qgmt9Llr7d67/2dh6h77u65gpx =XCJX -----END PGP SIGNATURE----- --B2XwZuBUJ8PPSpsy-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 18:11:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 626841065672 for ; Fri, 19 Feb 2010 18:11:39 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id CFA248FC0C for ; Fri, 19 Feb 2010 18:11:38 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1JIBbBh022896; Fri, 19 Feb 2010 20:11:37 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B7ED454.3020404@eng.auth.gr> Date: Fri, 19 Feb 2010 20:11:32 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: Rick Macklem References: <4B7EB1E5.3080907@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: mountd segfaults in NFSv4 if -alldirs is present in exports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 18:11:39 -0000 On 19/02/2010 18:24, Rick Macklem wrote: > > > On Fri, 19 Feb 2010, George Mamalakis wrote: > >> Hi all, >> >> the title explains it all... >> >> But ok, let's be a bit more extensive. >> >> If I have one line in /etc/exports reading: >> >> V4: / -alldirs >> >> and try to start mountd, it segfaults with signal 11. From the >> manpage I read that -alldirs is the "second method" used to export a >> filesystem and V4 is the "third", maybe implying that they are >> mutually exclusive. Nevertheless, I suppose that mountd shouldn't >> segfault in my case, it could just refuse to start giving an error >> message or something. I've tried a different /etc/exports containing >> a dummy option -dummy instead of -alldirs and mountd won't segfault, >> hence there's no problem with its parser. >> > The "V4:" line does not export a file system. It only specifies where > the "root" is for NFSv4 and what clients/security flavours are supported > for the NFSv4 lock state Ops that aren't associated with any file handle > is. (There can be multiple V4: lines for different hosts, but they should > differ in their "-sec" specification and only that.) The file systems > must still be exported by separate lines, just like NFSv2,3. > > It happens that "-alldirs" always applies to NFSv4, since it does > not use the Mount protocol and can mount anything under the "root" > that has been exported. > > As such, "-sec" plus the ones related to specifying host(s) > "-network, -mask" are the only ones that should be in the "V4:" > line(s). > > But, of course it shouldn't segfault. I'll put that on my to do > list. > > Thanks for reporting it, rick > Yes Rick, I understood that there was something wrong with my syntax but I wouldn't expect a segfault, as you already have stated :). Moreover, this is the problem that I was facing in one of my previous emails with the title "Kerberized NFSv3 incorrect behavior". In my last email to you I was claiming that mountd segfaults when both NFSD and KGSSAPI (along with device crypto) exist in the kernel config file. You replied to me that you would have it fixed. Now I understood that the problem had nothing to do with KGSSAPI, my problem was my /etc/exports file that contained -alldirs in V4 line. So no need to check if there's a conflict with KGSSAPI, there isn't :). Now, two last questions. question 1) I want to export my /export directory with -sec=krb5 to my clients, and the configuration of my server and client is respectively as follows: - server: /etc/exports: V4: / -sec=krb5 /export /etc/rc.conf rpcbind_enable="YES" mountd_flags="-e" nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_enable="YES" gssd_enable="YES" KERNEL: options NFSD options KGSSAPI device crypto -client: rc.conf: gssd_enable="YES" nfsuserd_enable="YES" nfsclient_enable="YES" rpcbind_enable="YES" nfs_client_flags="-n 4" rpc_statd_enable="YES" rpc_lockd_enable="YES" KERNEL: options KGSSAPI device crypto As I said, heimdal seems to work fine, all keytabs are where they should be, and I don't know how to mount the partition to my client. When I run: [root@fbsdclient ~]# mount_newnfs -onfsv4,sec=krb5 filesrv.ee.auth.gr:/export /mnt nfsv4 err=10016 mount_newnfs: /mnt, : Input/output error An I/O error I receive if I use opensolaris as a client. The kdc.log shows that the clients request the nfs server's ticket (2010-02-19T19:56:29 TGS-REQ mamalos@EE.AUTH.GR from IPv4:192.168.100.11 for nfs/filesrv.ee.auth.gr@EE.AUTH.GR), so things should be working that far, but then they refuse to mount the partition. If I export the partition with sec=sys and try to mount it with sec=sys, it works fine. question 2) At the end of nfsv4(4) man page (in the BUGS session) it states: "At this time, there is no recall of delegations for local file system operations. As such, delegations should only be enabled for file systems that are being used soley as NFS export volumes and are not being accessed via local system calls nor services such as Samba." Does this mean that if I manage to export my /home filesystem eventually, and my mailserver copies the emails to my users' maildirs (located in their home folder), or through another nfs mount, or a user is connected to his/her account both through nfsv4 and samba, then there will be a serious problem? Should I setup the nfs server in solaris and use bsd/linux nfs4 clients instead, to be sure that I will have no corrupted filesystems, etc? Have you tried mounting solaris-nfsv4 exported filesystems with the fbsd nfsclient and sec>=krb5? Thanx again for your help and attention. mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 19:04:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EB17106566C for ; Fri, 19 Feb 2010 19:04:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C9CCC8FC0C for ; Fri, 19 Feb 2010 19:04:42 +0000 (UTC) Received: by vws14 with SMTP id 14so163743vws.13 for ; Fri, 19 Feb 2010 11:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=FmYRVUs9J9tM2TGt+14Vr0skaQMf7jBDuPzX0W/TeKw=; b=lMcv5Z3g5VK2Ajvp2yHBBEUHnklj0g5cAwkWI7I8awttman+8hGP4DPYDmuebFs9Da wKvaAIJusIZ9i3BCTKNeMZ15d8TREfRHrbvP/qCITiecmEW44srzk9Ufgk1tUyrmLa/2 sUsFgu3DJDa8jhISnnoGnCHODlfGXpj6fmX4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=VkY0YSeXejLbQ/nCZgC2dYa1gv1OyMd9wwp3ZXWiRmeBg9dMjwLM3gCHUOUkxM1+nD i+9zksBXxm1xaCAM3yxydd2gnF+//RmWEf8cH3IjR89eAr2MsHfP/8aryMsnPunt+MyI NO4WqqyxyKAlt3HqXUiRAtiT9DhXh0Z7zLTS4= Received: by 10.220.99.208 with SMTP id v16mr4533875vcn.89.1266606279521; Fri, 19 Feb 2010 11:04:39 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 35sm3468768vws.0.2010.02.19.11.04.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 11:04:38 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 19 Feb 2010 11:03:59 -0800 From: Pyun YongHyeon Date: Fri, 19 Feb 2010 11:03:59 -0800 To: Slawa Olhovchenkov Message-ID: <20100219190359.GJ11675@michelle.cdnetworks.com> References: <147432021002141004o6c1412b7gd548b87709532ef9@mail.gmail.com> <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219122415.GR55307@zxy.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 19:04:43 -0000 On Fri, Feb 19, 2010 at 03:24:15PM +0300, Slawa Olhovchenkov wrote: > On Fri, Feb 19, 2010 at 08:51:29AM +0300, Slawa Olhovchenkov wrote: > > > On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote: > > > > > > > > I'm still not sure whether the panic is related with bge(4) but > > > there are a couple of missing workaround for PCIX BCM5704 silicon > > > bug in bge(4). Did you also see the panic before updating to > > > stable/8? > > > > Before updating to stable/8 2010-Feb-16 I see network freez on stable/8 > > 2009-Sep -- bge stop receiving packets (by tcpdump), after aprox. 40-50 > > days uptime. > > > > > > > Anyway, try attached patch and let me know how it works. > > > > Thanks, I try. > > > > I don't get trap after 2 hour, but already see next trouble: > > === > PING 10.200.0.1 (10.200.0.1): 56 data bytes > > --- 10.200.0.1 ping statistics --- > 100 packets transmitted, 97 packets received, 3.0% packet loss > round-trip min/avg/max/stddev = 0.188/0.268/0.356/0.044 ms > === > > w/o patch, but witch fresh source I see same trouble: after 12 hour 7% lost. > netstat -i don't show any errors. I think BCM5704 supports HW MAC statistics counter. Try extract it with "sysctl dev.bge.0.stats". It will give you much more information. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 19:11:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFEB31065672 for ; Fri, 19 Feb 2010 19:11:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 98C4B8FC1F for ; Fri, 19 Feb 2010 19:11:03 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta03.emeryville.ca.mail.comcast.net with comcast id jup21d0061bwxycA3vB4Kf; Fri, 19 Feb 2010 19:11:04 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.emeryville.ca.mail.comcast.net with comcast id jvDB1d00T3S48mS8evDB9N; Fri, 19 Feb 2010 19:13:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1DBAF1E301B; Fri, 19 Feb 2010 11:11:02 -0800 (PST) Date: Fri, 19 Feb 2010 11:11:02 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100219191102.GA1045@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: RELENG_8 -- NFSv3 credentials/permissions issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 19:11:03 -0000 I'm willing to bet this is something simple I've overlooked, but I'm out of ideas. Client is 8.0-RELEASE i386, server is 8.0-STABLE amd64 (kernel/world 2010/01/16). NFS version used is v3. Server filesystem is UFS2. Client configuration is off-kilter: it's a PXE booted machine. Initial PXE booting uses TFTP, then switches to NFS to load the kernel and kernel modules. The TFTP part works, with a caveat[1], but the NFS portion fails. With NFS, I'm forced to change permissions on all the exported files/directories to be 0644/0755 (specifically, setting other/global read/write access) otherwise the client gets back "Permission denied". The nfsd(8) man page implies that this shouldn't be necessary; adding -mapall=nobody:nobody or -maproot=nobody doesn't fix things either. In the absence of -maproot and -mapall options, remote accesses by root will result in using a credential of -2:-2. All other users will be mapped to their remote credential. If a -maproot option is given, remote access by root will be mapped to that credential instead of -2:-2. If a -mapall option is given, all users (including root) will be mapped to that credential in place of their own. Configuration data, tcpdump validation (client=192.168.1.140, server=192.168.1.51), and syslog data is below. Ideas? [1]: TFTP works as long as the file its trying to request (in this case /usr/local/freebsd8/boot/pxeboot) has its other/global read bit set, otherwise EACCESS is returned; I had to look in the tftpd source to figure this out. I'm not sure what the justification is there, given that use of -s and/or -u switches credentials to user/group nobody... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | Relevant server configuration bits: /etc/rc.conf ============== rpcbind_enable="yes" rpcbind_flags="-l" mountd_enable="yes" mountd_flags="-r -l" nfs_server_enable="yes" /etc/exports ============== /usr/local/freebsd8 -network 192.168.1 -mask 255.255.255.0 Permissions ============= drwxr-xr-x 22 root wheel 512 Feb 6 12:25 / drwxr-xr-x 17 root wheel 512 Feb 12 03:38 /usr drwxr-xr-x 15 root wheel 512 Feb 19 10:41 /usr/local drwx------ 5 nobody nobody 512 Feb 19 10:42 /usr/local/freebsd8 drwx------ 7 nobody nobody 1024 Nov 21 08:11 /usr/local/freebsd8/boot drwx------ 2 nobody nobody 12800 Nov 21 08:11 /usr/local/freebsd8/boot/kernel -r-------- 1 nobody nobody 11492703 Nov 21 07:48 /usr/local/freebsd8/boot/kernel/kernel tcpdump ========= {...snipping TFTP portion...} 10:57:20.601313 IP 192.168.1.140.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:30:48:71:60:6b, length 548 10:57:20.601442 IP 192.168.1.51.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 323 10:57:20.601688 IP 192.168.1.140.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:30:48:71:60:6b, length 548 10:57:20.601782 IP 192.168.1.51.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 323 10:57:20.613056 IP 192.168.1.140.1023 > 192.168.1.51.111: UDP, length 76 10:57:20.613369 IP 192.168.1.51.111 > 192.168.1.140.1023: UDP, length 28 10:57:20.613556 IP 192.168.1.140.1023 > 192.168.1.51.947: UDP, length 84 10:57:20.613921 IP 192.168.1.51.947 > 192.168.1.140.1023: UDP, length 60 10:57:20.614055 IP 192.168.1.140.1023 > 192.168.1.51.111: UDP, length 76 10:57:20.614291 IP 192.168.1.51.111 > 192.168.1.140.1023: UDP, length 28 10:57:20.614432 IP 192.168.1.140.4 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" 10:57:20.614458 IP 192.168.1.51.2049 > 192.168.1.140.4: reply ok 28 lookup ERROR: Permission denied 10:57:20.615436 IP 192.168.1.140.1022 > 192.168.1.51.947: UDP, length 84 10:57:20.615677 IP 192.168.1.51.947 > 192.168.1.140.1022: UDP, length 60 10:57:20.615806 IP 192.168.1.140.6 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" 10:57:20.615824 IP 192.168.1.51.2049 > 192.168.1.140.6: reply ok 28 lookup ERROR: Permission denied 10:57:20.615929 IP 192.168.1.140.1021 > 192.168.1.51.947: UDP, length 84 10:57:20.616164 IP 192.168.1.51.947 > 192.168.1.140.1021: UDP, length 60 10:57:20.616308 IP 192.168.1.140.8 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" 10:57:20.616327 IP 192.168.1.51.2049 > 192.168.1.140.8: reply ok 28 lookup ERROR: Permission denied 10:57:20.616428 IP 192.168.1.140.1020 > 192.168.1.51.947: UDP, length 84 10:57:20.616660 IP 192.168.1.51.947 > 192.168.1.140.1020: UDP, length 60 {...repeat until client gives up...} Feb 19 10:57:20 icarus dhcpd: DHCPDISCOVER from 00:30:48:71:60:6b via em0 Feb 19 10:57:20 icarus dhcpd: DHCPOFFER on 192.168.1.140 to 00:30:48:71:60:6b via em0 Feb 19 10:57:20 icarus dhcpd: DHCPREQUEST for 192.168.1.140 (192.168.1.51) from 00:30:48:71:60:6b via em0 Feb 19 10:57:20 icarus dhcpd: DHCPACK on 192.168.1.140 to 00:30:48:71:60:6b via em0 Feb 19 10:57:20 icarus rpcbind: connect from 192.168.1.140 to getport/addr(mountd) Feb 19 10:57:20 icarus mountd[1474]: mount request succeeded from 192.168.1.140 for /usr/local/freebsd8 Feb 19 10:57:20 icarus rpcbind: connect from 192.168.1.140 to getport/addr(nfs) Feb 19 10:57:20 icarus mountd[1474]: mount request succeeded from 192.168.1.140 for /usr/local/freebsd8 Feb 19 10:57:21 icarus last message repeated 34 times From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 19:11:05 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2E2E106566B for ; Fri, 19 Feb 2010 19:11:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 078D38FC12 for ; Fri, 19 Feb 2010 19:11:04 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NiYFj-000O8m-Sh; Fri, 19 Feb 2010 22:11:03 +0300 Date: Fri, 19 Feb 2010 22:11:03 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100219191103.GT55307@zxy.spb.ru> References: <20100216175719.GB1394@michelle.cdnetworks.com> <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219190359.GJ11675@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 19:11:05 -0000 On Fri, Feb 19, 2010 at 11:03:59AM -0800, Pyun YongHyeon wrote: > On Fri, Feb 19, 2010 at 03:24:15PM +0300, Slawa Olhovchenkov wrote: > > On Fri, Feb 19, 2010 at 08:51:29AM +0300, Slawa Olhovchenkov wrote: > > > > > On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > I'm still not sure whether the panic is related with bge(4) but > > > > there are a couple of missing workaround for PCIX BCM5704 silicon > > > > bug in bge(4). Did you also see the panic before updating to > > > > stable/8? > > > > > > Before updating to stable/8 2010-Feb-16 I see network freez on stable/8 > > > 2009-Sep -- bge stop receiving packets (by tcpdump), after aprox. 40-50 > > > days uptime. > > > > > > > > > > Anyway, try attached patch and let me know how it works. > > > > > > Thanks, I try. > > > > > > > I don't get trap after 2 hour, but already see next trouble: > > > > === > > PING 10.200.0.1 (10.200.0.1): 56 data bytes > > > > --- 10.200.0.1 ping statistics --- > > 100 packets transmitted, 97 packets received, 3.0% packet loss > > round-trip min/avg/max/stddev = 0.188/0.268/0.356/0.044 ms > > === > > > > w/o patch, but witch fresh source I see same trouble: after 12 hour 7% lost. > > netstat -i don't show any errors. > > I think BCM5704 supports HW MAC statistics counter. Try extract it > with "sysctl dev.bge.0.stats". It will give you much more > information. dev.bge.0.stats.FramesDroppedDueToFilters: 0 dev.bge.0.stats.DmaWriteQueueFull: 0 dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 dev.bge.0.stats.NoMoreRxBDs: 0 dev.bge.0.stats.InputDiscards: 0 dev.bge.0.stats.InputErrors: 0 dev.bge.0.stats.RecvThresholdHit: 561594 dev.bge.0.stats.DmaReadQueueFull: 41972 dev.bge.0.stats.DmaReadHighPriQueueFull: 0 dev.bge.0.stats.SendDataCompQueueFull: 0 dev.bge.0.stats.RingSetSendProdIndex: 705180 dev.bge.0.stats.RingStatusUpdate: 950302 dev.bge.0.stats.Interrupts: 950302 dev.bge.0.stats.AvoidedInterrupts: 0 dev.bge.0.stats.SendThresholdHit: 0 dev.bge.0.stats.rx.Octets: 196013834 dev.bge.0.stats.rx.Fragments: 0 dev.bge.0.stats.rx.UcastPkts: 582767 dev.bge.0.stats.rx.MulticastPkts: 0 dev.bge.0.stats.rx.FCSErrors: 0 dev.bge.0.stats.rx.AlignmentErrors: 0 dev.bge.0.stats.rx.xonPauseFramesReceived: 0 dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 dev.bge.0.stats.rx.ControlFramesReceived: 0 dev.bge.0.stats.rx.xoffStateEntered: 0 dev.bge.0.stats.rx.FramesTooLong: 0 dev.bge.0.stats.rx.Jabbers: 0 dev.bge.0.stats.rx.UndersizePkts: 0 dev.bge.0.stats.rx.inRangeLengthError: 0 dev.bge.0.stats.rx.outRangeLengthError: 0 dev.bge.0.stats.tx.Octets: 654902713 dev.bge.0.stats.tx.Collisions: 0 dev.bge.0.stats.tx.XonSent: 0 dev.bge.0.stats.tx.XoffSent: 0 dev.bge.0.stats.tx.flowControlDone: 0 dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 dev.bge.0.stats.tx.SingleCollisionFrames: 0 dev.bge.0.stats.tx.MultipleCollisionFrames: 0 dev.bge.0.stats.tx.DeferredTransmissions: 0 dev.bge.0.stats.tx.ExcessiveCollisions: 0 dev.bge.0.stats.tx.LateCollisions: 0 dev.bge.0.stats.tx.UcastPkts: 699931 dev.bge.0.stats.tx.MulticastPkts: 0 dev.bge.0.stats.tx.BroadcastPkts: 492 dev.bge.0.stats.tx.CarrierSenseErrors: 0 dev.bge.0.stats.tx.Discards: 0 dev.bge.0.stats.tx.Errors: 0 dev.bge.1.stats.FramesDroppedDueToFilters: 0 dev.bge.1.stats.DmaWriteQueueFull: 0 dev.bge.1.stats.DmaWriteHighPriQueueFull: 0 dev.bge.1.stats.NoMoreRxBDs: 0 dev.bge.1.stats.InputDiscards: 0 dev.bge.1.stats.InputErrors: 0 dev.bge.1.stats.RecvThresholdHit: 2889283 dev.bge.1.stats.DmaReadQueueFull: 79 dev.bge.1.stats.DmaReadHighPriQueueFull: 0 dev.bge.1.stats.SendDataCompQueueFull: 0 dev.bge.1.stats.RingSetSendProdIndex: 2861918 dev.bge.1.stats.RingStatusUpdate: 5518912 dev.bge.1.stats.Interrupts: 5518912 dev.bge.1.stats.AvoidedInterrupts: 0 dev.bge.1.stats.SendThresholdHit: 0 dev.bge.1.stats.rx.Octets: 930931282 dev.bge.1.stats.rx.Fragments: 1 dev.bge.1.stats.rx.UcastPkts: 2956515 dev.bge.1.stats.rx.MulticastPkts: 0 dev.bge.1.stats.rx.FCSErrors: 18 dev.bge.1.stats.rx.AlignmentErrors: 0 dev.bge.1.stats.rx.xonPauseFramesReceived: 0 dev.bge.1.stats.rx.xoffPauseFramesReceived: 0 dev.bge.1.stats.rx.ControlFramesReceived: 0 dev.bge.1.stats.rx.xoffStateEntered: 0 dev.bge.1.stats.rx.FramesTooLong: 0 dev.bge.1.stats.rx.Jabbers: 0 dev.bge.1.stats.rx.UndersizePkts: 0 dev.bge.1.stats.rx.inRangeLengthError: 0 dev.bge.1.stats.rx.outRangeLengthError: 0 dev.bge.1.stats.tx.Octets: 305055886 dev.bge.1.stats.tx.Collisions: 0 dev.bge.1.stats.tx.XonSent: 0 dev.bge.1.stats.tx.XoffSent: 0 dev.bge.1.stats.tx.flowControlDone: 0 dev.bge.1.stats.tx.InternalMacTransmitErrors: 0 dev.bge.1.stats.tx.SingleCollisionFrames: 0 dev.bge.1.stats.tx.MultipleCollisionFrames: 0 dev.bge.1.stats.tx.DeferredTransmissions: 0 dev.bge.1.stats.tx.ExcessiveCollisions: 0 dev.bge.1.stats.tx.LateCollisions: 0 dev.bge.1.stats.tx.UcastPkts: 2860335 dev.bge.1.stats.tx.MulticastPkts: 0 dev.bge.1.stats.tx.BroadcastPkts: 447 dev.bge.1.stats.tx.CarrierSenseErrors: 0 dev.bge.1.stats.tx.Discards: 0 dev.bge.1.stats.tx.Errors: 0 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 20:07:29 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0615B106568D for ; Fri, 19 Feb 2010 20:07:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id A9DDB8FC12 for ; Fri, 19 Feb 2010 20:07:28 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so88701qwh.7 for ; Fri, 19 Feb 2010 12:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=KDMDZLvVK8kal+ViJSKWW3MgymDyBv3wH67Ik9Mf5xI=; b=IBqbvtCULBx8hfXkROU9ftKbZlL5El8WWHPicZlSV4G8uAkQKyNcLFQj2oJMTI0ta/ iOikbT+/p4oR33Rmj8ZGqWfUb536Q+VIHu9HZD6ogoCoo98biZDv5babzPzz4zjg4XoV et/2ceQ1MfK06+uZWy8nvCcq1qHnwCu7OmTvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YE688dnIWziQ4AdluKokTvuPmiGfQ5v33uaXPBuEgLcRzLuSCMXS8oCZf/8iZ1Gf9u GiswfP5BRICCPYTCHY7rRvD3pZxmCYe2hJnH2P2uGFivGbFbE4IIGKkC/11s8VvtKNx7 WVDQlb5EpedatHk4fynJ0iOQN6QvnaPme4Yfc= Received: by 10.224.123.96 with SMTP id o32mr3767112qar.290.1266610047788; Fri, 19 Feb 2010 12:07:27 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm1527972qwj.31.2010.02.19.12.07.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 12:07:26 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 19 Feb 2010 12:06:47 -0800 From: Pyun YongHyeon Date: Fri, 19 Feb 2010 12:06:47 -0800 To: Slawa Olhovchenkov Message-ID: <20100219200647.GK11675@michelle.cdnetworks.com> References: <20100218143822.GA8380@zxy.spb.ru> <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219191103.GT55307@zxy.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:07:29 -0000 On Fri, Feb 19, 2010 at 10:11:03PM +0300, Slawa Olhovchenkov wrote: > On Fri, Feb 19, 2010 at 11:03:59AM -0800, Pyun YongHyeon wrote: > > > On Fri, Feb 19, 2010 at 03:24:15PM +0300, Slawa Olhovchenkov wrote: > > > On Fri, Feb 19, 2010 at 08:51:29AM +0300, Slawa Olhovchenkov wrote: > > > > > > > On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > > > > I'm still not sure whether the panic is related with bge(4) but > > > > > there are a couple of missing workaround for PCIX BCM5704 silicon > > > > > bug in bge(4). Did you also see the panic before updating to > > > > > stable/8? > > > > > > > > Before updating to stable/8 2010-Feb-16 I see network freez on stable/8 > > > > 2009-Sep -- bge stop receiving packets (by tcpdump), after aprox. 40-50 > > > > days uptime. > > > > > > > > > > > > > Anyway, try attached patch and let me know how it works. > > > > > > > > Thanks, I try. > > > > > > > > > > I don't get trap after 2 hour, but already see next trouble: > > > > > > === > > > PING 10.200.0.1 (10.200.0.1): 56 data bytes > > > > > > --- 10.200.0.1 ping statistics --- > > > 100 packets transmitted, 97 packets received, 3.0% packet loss > > > round-trip min/avg/max/stddev = 0.188/0.268/0.356/0.044 ms > > > === > > > > > > w/o patch, but witch fresh source I see same trouble: after 12 hour 7% lost. > > > netstat -i don't show any errors. > > > > I think BCM5704 supports HW MAC statistics counter. Try extract it > > with "sysctl dev.bge.0.stats". It will give you much more > > information. > [...] > dev.bge.1.stats.rx.Fragments: 1 You received a frame that is less than 64 bytes with a bad FCS. > dev.bge.1.stats.rx.UcastPkts: 2956515 > dev.bge.1.stats.rx.MulticastPkts: 0 > dev.bge.1.stats.rx.FCSErrors: 18 You have a lot of FCS errors here. Please double check cabling. If the statistics counter is right, sender is guilty or you have bad cabling issues here. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 20:09:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E92471065693 for ; Fri, 19 Feb 2010 20:09:37 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5553C8FC12 for ; Fri, 19 Feb 2010 20:09:36 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1JK9ani083729 for ; Fri, 19 Feb 2010 22:09:36 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B7EEFFA.90104@eng.auth.gr> Date: Fri, 19 Feb 2010 22:09:30 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B7EB1E5.3080907@eng.auth.gr> <4B7ED454.3020404@eng.auth.gr> In-Reply-To: <4B7ED454.3020404@eng.auth.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: mountd segfaults in NFSv4 if -alldirs is present in exports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:09:38 -0000 On 19/02/2010 20:11, George Mamalakis wrote: > [root@fbsdclient ~]# mount_newnfs -onfsv4,sec=krb5 > filesrv.ee.auth.gr:/export /mnt > nfsv4 err=10016 > mount_newnfs: /mnt, : Input/output error I performed some more test on this setup and I can shed a bit more light to the issue. My /etc/export on my server (filesrv.ee.auth.gr) reads: V4: / -sec=krb5 /home If I run: # mount_newnfs -onfsv4,sec=krb5 filesrv.ee.auth.gr:/home /mnt as root, without having kinited to some principal, the partition gets mounted in /mnt and I can perform operations on it. Once I kinit to some user I get the error: nfsv4 err=10016 Then, I read the article on http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup a bit more thoroughly (with regard to nfsv4), and changed /etc/fstab to read: V4: / -sec=krb5 /home -sec=krb5 I restarted nfsd and mountd, switched to a simple user (mamalos), kinited as mamalos principal, and typed: [mamalos@fbsdclient ~]$ mount_newnfs -onfsv4,sec=krb5 filesrv.ee.auth.gr:/home mnt where mnt is a directory in mamalos' homefolder owned by that user. Of course, one has to run sysctl vfs.usermount=1 in order to allow simple users to mount filesystems (as was already suggested by the aforementioned article). This time the mount worked! I ls'd the directory, cd'd to a folder owned by mamalos (permissions 700), even touched a file in it. The only problem was that the first time I touched a file, it took a few seconds for the touch command to complete. After that, all subsequent touch commands were executed immediately. So, for the time being, mounting nfsv4 partitions with sec=krb5 has been established, but with a few limitations. I'll test now what can be done with solaris and linux clients. Good night everybody (~GMT+2). -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 20:14:00 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8BF2106566B for ; Fri, 19 Feb 2010 20:14:00 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 27E088FC14 for ; Fri, 19 Feb 2010 20:14:00 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NiZEd-000OZy-DR; Fri, 19 Feb 2010 23:13:59 +0300 Date: Fri, 19 Feb 2010 23:13:59 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100219201359.GU55307@zxy.spb.ru> References: <20100218193612.GB11675@michelle.cdnetworks.com> <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219200647.GK11675@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:14:00 -0000 On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > dev.bge.1.stats.rx.Fragments: 1 > > You received a frame that is less than 64 bytes with a bad FCS. > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > dev.bge.1.stats.rx.MulticastPkts: 0 > > dev.bge.1.stats.rx.FCSErrors: 18 > > You have a lot of FCS errors here. > Please double check cabling. If the statistics counter is right, > sender is guilty or you have bad cabling issues here. 1. lost packets much more 18. I think hundreds, or thousands. 2. packets lost on both (bge0 & bge1) interfaces 3. packets don't lost on sources at Aug'09 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 21:12:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE91E1065694 for ; Fri, 19 Feb 2010 21:12:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1258FC08 for ; Fri, 19 Feb 2010 21:12:43 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so101315qwh.7 for ; Fri, 19 Feb 2010 13:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=u5YUeI6xDCKeJjMMvZiZRn+cOsa+hnMwTmuXNP8aWF4=; b=K3dpxN1HyV854xtCyA4SSypjevCnr1pOt9BnNxoL9TbX8x2oWKUUNo8pUTHqj5dtfM CVp8jq/Ml+rK96MRtY/spZhAmBscseAZ/HFmhzoSHV0YX28JqVOekKBqTL5xdnzLIPrQ zruqpbyuWsVZTsElaIIjPi3cXn7ZXOJBu72zE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=RVDQ88LokwUnwJ/XeIw3kN3SK18r8wF08isJNxPzQ2Ku9y/28kp0EqhYlEPjyXvIJ6 DnkQc3MK8Tr/SN3xWpqaoy9XBchZNwiNSA8w1pgqbTXYQ5fTuY8epJZm6AWEA8HEuHfo SYATFv2RG/oNi4kyoyVlDIZjMKsyrwX7Eo3hQ= Received: by 10.229.230.4 with SMTP id jk4mr4378787qcb.1.1266613962599; Fri, 19 Feb 2010 13:12:42 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 29sm4386514vws.3.2010.02.19.13.12.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 13:12:41 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 19 Feb 2010 13:12:01 -0800 From: Pyun YongHyeon Date: Fri, 19 Feb 2010 13:12:01 -0800 To: Slawa Olhovchenkov Message-ID: <20100219211201.GL11675@michelle.cdnetworks.com> References: <20100218212428.GJ55307@zxy.spb.ru> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219201359.GU55307@zxy.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 21:12:43 -0000 On Fri, Feb 19, 2010 at 11:13:59PM +0300, Slawa Olhovchenkov wrote: > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > > > > dev.bge.1.stats.rx.Fragments: 1 > > > > You received a frame that is less than 64 bytes with a bad FCS. > > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > > dev.bge.1.stats.rx.MulticastPkts: 0 > > > dev.bge.1.stats.rx.FCSErrors: 18 > > > > You have a lot of FCS errors here. > > Please double check cabling. If the statistics counter is right, > > sender is guilty or you have bad cabling issues here. > > 1. lost packets much more 18. I think hundreds, or thousands. > 2. packets lost on both (bge0 & bge1) interfaces If you see the MAC statistics counter, you have the following number of status updates and interrupts. Both numbers are same which means the controller didn't lost interrupts for state updates. dev.bge.0.stats.RingStatusUpdate: 950302 dev.bge.0.stats.Interrupts: 950302 and dev.bge.1.stats.RingStatusUpdate: 5518912 dev.bge.1.stats.Interrupts: 5518912 You received 582767 unicast packets and lost 0 packet for bge0. dev.bge.0.stats.rx.UcastPkts: 582767 And you also received 2956515 unicast packets and lost 19 packets for bge1. dev.bge.1.stats.rx.Fragments: 1 dev.bge.1.stats.rx.UcastPkts: 2956515 dev.bge.1.stats.rx.FCSErrors: 18 I don't see such a large number packet drops from these MAC statistics unless upper stack drops received packets. I fixed some counter updates which were ignored in previous releases so you may happen to see lost counters in recent version. Normally you should not have any FCS errors, it could be related with signal quality and these errors might not be correctly counted. > 3. packets don't lost on sources at Aug'09 Since I don't have BCM5704 hardware it's hard to find which revision may affect to this issue. Could you narrow down which revision number started showing the issue? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 21:12:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73513106568B for ; Fri, 19 Feb 2010 21:12:49 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id F2CD68FC18 for ; Fri, 19 Feb 2010 21:12:48 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o1JLCjx5059095; Fri, 19 Feb 2010 22:12:45 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o1JLCjMj059094; Fri, 19 Feb 2010 22:12:45 +0100 (CET) (envelope-from marius) Date: Fri, 19 Feb 2010 22:12:45 +0100 From: Marius Strobl To: Kostik Belousov Message-ID: <20100219211245.GV50825@alchemy.franken.de> References: <4B7D74A7.6010006@acm.poly.edu> <4B7D9C5C.1090909@acm.poly.edu> <20100218220714.GU50403@deviant.kiev.zoral.com.ua> <20100219155235.GU50825@alchemy.franken.de> <20100219174256.GB50403@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219174256.GB50403@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: Boris Kochergin , FreeBSD-STABLE Mailing List , Rick Macklem Subject: Re: Can't load NFS server module with a custom 8.0 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 21:12:49 -0000 On Fri, Feb 19, 2010 at 07:42:56PM +0200, Kostik Belousov wrote: > On Fri, Feb 19, 2010 at 04:52:35PM +0100, Marius Strobl wrote: > > On Fri, Feb 19, 2010 at 12:07:14AM +0200, Kostik Belousov wrote: > > > On Thu, Feb 18, 2010 at 03:00:28PM -0500, Boris Kochergin wrote: > > > > Rick Macklem wrote: > > > > > > > > > > > > > > >On Thu, 18 Feb 2010, Boris Kochergin wrote: > > > > > > > > > >>Ahoy. I didn't get any replies to this on -net, so I thought I'd try > > > > >>here. I have an 8.0-RELEASE-p2/amd64 machine running a custom kernel > > > > >>(configuration file at http://acm.poly.edu/~spawk/ACM) and I am > > > > >>unable to use the NFS server module on it. After loading the nfssvc > > > > >>module, attempting to load the nfsserver module fails and the > > > > >>following appears in dmesg: > > > > >> > > > > >>Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create > > > > >>undefined > > > > >>Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type > > > > >> > > > > >>I see a reference to the problem at > > > > >>http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.html. > > > > >>Am I missing something or has it never gotten resolved? Thanks. > > > > >> > > > > >I don't know diddly about the module loading stuff, but you could try > > > > >this patch. (svcpool_create() is a part of the krpc, which is listed > > > > >as a module that nfsserver depends on) > > > > > > > > > >rick > > > > >--- untested patch for nfs_srvsubs.c --- > > > > >--- nfsserver/nfs_srvsubs.c.sav 2010-02-18 14:41:52.000000000 -0500 > > > > >+++ nfsserver/nfs_srvsubs.c 2010-02-18 14:42:12.000000000 -0500 > > > > >@@ -554,7 +554,7 @@ > > > > > nfsrv_modevent, > > > > > NULL, > > > > > }; > > > > >-DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_ANY); > > > > >+DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_FIRST); > > > > > > > > > > /* So that loader and kldload(2) can find us, wherever we are.. */ > > > > > MODULE_VERSION(nfsserver, 1); > > > > Thanks for the patch, but the problem persists with it, I'm afraid. > > > > > > I think this is changed in HEAD, and part of the changes are already in > > > stable/8, which is different from 8.0 too. > > > > > > Anyway, for HEAD nfsserver we need 1. nfscommon 2. nfs_common. > > > > Could you please elaborate on why nfsserver requires the former? > Not any more. I did a check yesterday on the outdated tree without > realizing this. Sorry. > > > At least as far as svcpool_create() is concerned I see no reason > > why it should require nfscommon. Also, when testing r203968 the > > following list of modules where sufficient to have both nfsclient > > and nfsserver working: > > krpc.ko > > nfs_common.ko > > nfsclient.ko > > nfslockd.ko > > nfsserver.ko > > nfssvc.ko > > I confirm. So the only thing missing ATM is to actually add nfs_common.ko > to the build. Correct, thanks for pointing this out. Marius From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 21:35:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91BA01065697 for ; Fri, 19 Feb 2010 21:35:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 461598FC30 for ; Fri, 19 Feb 2010 21:35:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA6TfkuDaFvK/2dsb2JhbACbCXOwdQiNC4JPDgiCAgSDFQ X-IronPort-AV: E=Sophos;i="4.49,505,1262581200"; d="scan'208";a="66198108" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 19 Feb 2010 16:35:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 68F1F109C285; Fri, 19 Feb 2010 16:35:50 -0500 (EST) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHvr+Pl0XwUu; Fri, 19 Feb 2010 16:35:49 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id A158B109C26F; Fri, 19 Feb 2010 16:35:49 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1JLlXd08526; Fri, 19 Feb 2010 16:47:33 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 19 Feb 2010 16:47:33 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B7ED454.3020404@eng.auth.gr> Message-ID: References: <4B7EB1E5.3080907@eng.auth.gr> <4B7ED454.3020404@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable Subject: Re: mountd segfaults in NFSv4 if -alldirs is present in exports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 21:35:51 -0000 On Fri, 19 Feb 2010, George Mamalakis wrote: > > question 1) > > I want to export my /export directory with -sec=krb5 to my clients, and the > configuration of my server and client is respectively as follows: > > - server: > /etc/exports: > V4: / -sec=krb5 > /export You need "-sec=krb5" on the /export line as well. For example: V4: / -sec=krb5 /export -sec=krb5 > > /etc/rc.conf > rpcbind_enable="YES" > mountd_flags="-e" > nfs_server_enable="YES" > nfsv4_server_enable="YES" > nfsuserd_enable="YES" > gssd_enable="YES" > > KERNEL: > options NFSD > options KGSSAPI > device crypto > > -client: > rc.conf: > gssd_enable="YES" > nfsuserd_enable="YES" > nfsclient_enable="YES" > rpcbind_enable="YES" > nfs_client_flags="-n 4" > rpc_statd_enable="YES" > rpc_lockd_enable="YES" > > KERNEL: > options KGSSAPI > device crypto > all the above looks ok, at a glance. > As I said, heimdal seems to work fine, all keytabs are where they should be, > and I don't know how to mount the partition to my client. When I run: > > [root@fbsdclient ~]# mount_newnfs -onfsv4,sec=krb5 filesrv.ee.auth.gr:/export > /mnt > nfsv4 err=10016 > mount_newnfs: /mnt, : Input/output error > Unless you have applied the experimental patch that allows host based client side credentials, mounting as root isn't going to work. Have you looked at: http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup You basically have to do the mount as a non-root user after that user has acquired a valid TGT. > An I/O error I receive if I use opensolaris as a client. The kdc.log shows > that the clients request the nfs server's ticket (2010-02-19T19:56:29 TGS-REQ > mamalos@EE.AUTH.GR from IPv4:192.168.100.11 for > nfs/filesrv.ee.auth.gr@EE.AUTH.GR), so things should be working that far, but > then they refuse to mount the partition. > > If I export the partition with sec=sys and try to mount it with sec=sys, it > works fine. > On the server, do you have a keytab entry for nfs/filesrv.ee.auth.gr@EE.AUTH.GR in its default keytab file (/etc/krb5.keytab) with encryption type des-crc-cbc? > question 2) > At the end of nfsv4(4) man page (in the BUGS session) it states: > > "At this time, there is no recall of delegations for local file system > operations. As such, delegations should only be enabled for file systems > that are being used soley as NFS export volumes and are not being > accessed via local system calls nor services such as Samba." > > Does this mean that if I manage to export my /home filesystem eventually, and > my mailserver copies the emails to my users' maildirs (located in their home > folder), or through another nfs mount, or a user is connected to his/her > account both through nfsv4 and samba, then there will be a serious problem? > Potential problem if you enable delegations. I think they're disabled by default. (do a "sysctl -a | grep newnfs" and look at them) > Should I setup the nfs server in solaris and use bsd/linux nfs4 clients > instead, to be sure that I will have no corrupted filesystems, etc? Have you > tried mounting solaris-nfsv4 exported filesystems with the fbsd nfsclient and > sec>=krb5? > I do quite a bit of testing against Solaris10, so I wouldn't expect a problem if you use a Solaris server and fbsd8 client. Good luck with it, rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 21:38:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48314106568B for ; Fri, 19 Feb 2010 21:38:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f180.google.com (mail-px0-f180.google.com [209.85.216.180]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2998FC0A for ; Fri, 19 Feb 2010 21:38:13 +0000 (UTC) Received: by pxi10 with SMTP id 10so338442pxi.13 for ; Fri, 19 Feb 2010 13:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=slL37NsGGQ/zONne+LjNVWvQiF9PeU+KVrZYQVr/xwA=; b=fm41FxM6kwQbbb+2awMisMOj2FlgZXnCPG57LnnIHnlXQum5eR1kaHW24jZw8RFckh Tr4ssbbWM92l0NrMAcxtrfyZldtaXvYEP7NmvvQebSHT7SReRxfFfhZg/09phqzWSDXW JZQmIzquh4K300WWDOwK+fZoiI9hj6rju9jc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mByf7rkMGz9jTIVBe4nx8A5r84k04EHeAGlquEL2cg1yKyvk2FwCvrZUYBjsbWQyS5 CpWFtTeeoLZYqURYXGtdP0npJHEnJuPThFCDNAZqlfGrog77L5bwxDkEKW0a4yG6Vf8u 1OXlYSgI5qpCAPR6ufESMjG8mHRqLkZNlL2Bw= MIME-Version: 1.0 Received: by 10.142.8.14 with SMTP id 14mr7797011wfh.59.1266615493229; Fri, 19 Feb 2010 13:38:13 -0800 (PST) In-Reply-To: <1234698255.13304.37.camel@horst-tla> References: <1234698255.13304.37.camel@horst-tla> Date: Fri, 19 Feb 2010 13:38:13 -0800 Message-ID: <7d6fde3d1002191338u7f73ddjb2afbdf35bd16b7b@mail.gmail.com> From: Garrett Cooper To: =?ISO-8859-1?Q?Horst_G=FCnther_Burkhardt_III?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , FreeBSD PowerPC ML Subject: Re: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 21:38:14 -0000 On Sun, Feb 15, 2009 at 3:44 AM, Horst G=FCnther Burkhardt III wrote: > Hey everybody :) > > I'm having yet another issue compiling 7-STABLE, just as the last was sol= ved, and I _really_ would appreciate some assistance. During `make buildwor= ld`, this error > occurs: > > > =3D=3D=3D> gnu/lib/libstdc++ (depend) > ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/g= eneric/atomicity_mutex/atomicity.h atomicity.cc > ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h u= nwind.h > rm -f .depend > mkdep -f .depend -a =A0 =A0-DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu= /lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libs= upc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/= libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/.= ./../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contr= ib/libstdc++/include -I. /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libmath/stubs.c /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/lib= iberty/cp-demangle.c > mkdep -f .depend -a =A0 =A0 =A0/usr/src/gnu/lib/libstdc++/../../../contri= b/libstdc++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc++/../../../con= trib/libstdc++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc++/../../../co= ntrib/libstdc++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc++/../../../con= trib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/l= ibstdc++/src/compatibility.cc /usr/src/gnu/lib/libstdc++/../../../contrib/l= ibstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libs= tdc++/src/ctype.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/sr= c/debug.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug_= list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functexce= pt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_io.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc /usr/src/= gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu/l= ib/libstdc++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib/= libstdc++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc++/../../= ../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/src/locale_init.cc /usr/src/gnu/lib/libstdc++/../../../contri= b/libstdc++/src/locale_facets.cc /usr/src/gnu/lib/libstdc++/../../../contri= b/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc++/../../../contrib/l= ibstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/src/strstream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /src/tree.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/allo= cator-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/con= cept-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/fstr= eam-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ext-i= nst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios-inst.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/iostream-inst.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream-inst.cc= /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale-inst.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/gn= u/lib/libstdc++/../../../contrib/libstdc++/src/ostream-inst.cc /usr/src/gnu= /lib/libstdc++/../../../contrib/libstdc++/src/sstream-inst.cc /usr/src/gnu/= lib/libstdc++/../../../contrib/libstdc++/src/streambuf-inst.cc /usr/src/gnu= /lib/libstdc++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/lib= /libstdc++/../../../contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib/l= ibstdc++/../../../contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib/l= ibstdc++/../../../contrib/libstdc++/src/wlocale-inst.cc /usr/src/gnu/lib/li= bstdc++/../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/codecv= t_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/l= ocale/generic/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../contri= b/libstdc++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/config/locale/generic/messages_members.cc /usr= /src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/mon= etary_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/conf= ig/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../co= ntrib/libstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/libs= tdc++/../../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/gnu= /lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.cc= /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_op.cc = /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opnt.cc= /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opv.cc= /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opvnt.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_alloc= .cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_arm.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux_r= untime.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/e= h_call.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/e= h_catch.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/= eh_exception.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsu= pc++/eh_globals.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/li= bsupc++/eh_personality.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_term_handler.cc /usr/src/gnu/lib/libstdc++/../../../contr= ib/libstdc++/libsupc++/eh_terminate.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/libsupc++/eh_throw.cc /usr/src/gnu/lib/libstdc++/../../..= /contrib/libstdc++/libsupc++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../..= /contrib/libstdc++/libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc++/= ../../../contrib/libstdc++/libsupc++/guard.cc /usr/src/gnu/lib/libstdc++/..= /../../contrib/libstdc++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/libsupc++/new_op.cc /usr/src/gnu/lib/libstdc++= /../../../contrib/libstdc++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/libsupc++/new_opv.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc++= /../../../contrib/libstdc++/libsupc++/tinfo.cc /usr/src/gnu/lib/libstdc++/.= ./../../contrib/libstdc++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc++/..= /../../contrib/libstdc++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc++/../../= ../contrib/libstdc++/libsupc++/vterminate.cc > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_alloc.cc:41: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_arm.cc:31: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_aux_runtime.cc:34: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_call.cc:33: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.c= c:37:23: error: unwind-pe.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_catch.cc:31: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_exception.cc:34: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_globals.cc:35: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_personality.cc:33: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_person= ality.cc:41:23: error: unwind-pe.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_term_handler.cc:31: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_terminate.cc:34: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_throw.cc:31: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_type.cc:33: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/eh_unex_handler.cc:30: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/pure.cc:32: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/libsupc++/vec.cc:37: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cx= x.h:41:20: error: unwind.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/src/gnu/lib/libstdc++. > *** Error code 1 > > Stop in /usr/src/gnu/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > [ bsdbox ] [ root ] [ /usr/src ] =3D=3D> Ran into the same issue with RELENG_8 -> 9-CURRENT. What does your make.conf // src.conf look like? Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 23:15:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E561065670 for ; Fri, 19 Feb 2010 23:15:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 16E048FC0A for ; Fri, 19 Feb 2010 23:15:38 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta05.emeryville.ca.mail.comcast.net with comcast id jvQT1d0081HpZEsA5zFfCp; Fri, 19 Feb 2010 23:15:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta14.emeryville.ca.mail.comcast.net with comcast id jzFe1d0063S48mS8azFfFC; Fri, 19 Feb 2010 23:15:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 86AE81E301A; Fri, 19 Feb 2010 15:15:37 -0800 (PST) Date: Fri, 19 Feb 2010 15:15:37 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100219231537.GA7704@icarus.home.lan> References: <1234698255.13304.37.camel@horst-tla> <7d6fde3d1002191338u7f73ddjb2afbdf35bd16b7b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <7d6fde3d1002191338u7f73ddjb2afbdf35bd16b7b@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:15:39 -0000 On Fri, Feb 19, 2010 at 01:38:13PM -0800, Garrett Cooper wrote: > On Sun, Feb 15, 2009 at 3:44 AM, Horst G=FCnther Burkhardt III > wrote: > > Hey everybody :) > > > > I'm having yet another issue compiling 7-STABLE, just as the last was s= olved, and I _really_ would appreciate some assistance. During `make buildw= orld`, this error > > occurs: > > > > > > =3D=3D=3D> gnu/lib/libstdc++ (depend) > > ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu= /generic/atomicity_mutex/atomicity.h atomicity.cc > > ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h= unwind.h > > rm -f .depend > > mkdep -f .depend -a =A0 =A0-DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/g= nu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/li= bsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/li= b/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++= /../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../con= trib/libstdc++/include -I. /usr/src/gnu/lib/libstdc++/../../../contrib/libs= tdc++/libmath/stubs.c /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/l= ibiberty/cp-demangle.c > > mkdep -f .depend -a =A0 =A0 =A0/usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/src/compatibility.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/li= bstdc++/src/ctype.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/= src/debug.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debu= g_list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functex= cept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_i= o.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_i > nit.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_loca= le.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/limits.cc /= usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc /usr/src/g= nu/lib/libstdc++/../../../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/= libstdc++/../../../contrib/libstdc++/src/locale_init.cc /usr/src/gnu/lib/li= bstdc++/../../../contrib/libstdc++/src/locale_facets.cc /usr/src/gnu/lib/li= bstdc++/../../../contrib/libstdc++/src/localename.cc /usr/src/gnu/lib/libst= dc++/../../../contrib/libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc++= /../../../contrib/libstdc++/src/strstream.cc /usr/src/gnu/lib/libstdc++/../= =2E./../contrib/libstdc++/src/tree.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/src/allocator-inst.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/src/concept-inst.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/src/fstream-inst.cc /usr/src/gnu/lib/libstdc++/../../../co= ntrib/libstdc++/src/ext-inst.cc /usr/src/gnu/lib/lib > stdc++/../../../contrib/libstdc++/src/ios-inst.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/src/iostream-inst.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/src/istream-inst.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/src/istream.cc /usr/src/gnu/lib/libstdc++/../= =2E./../contrib/libstdc++/src/locale-inst.cc /usr/src/gnu/lib/libstdc++/../= =2E./../contrib/libstdc++/src/misc-inst.cc /usr/src/gnu/lib/libstdc++/../..= /../contrib/libstdc++/src/ostream-inst.cc /usr/src/gnu/lib/libstdc++/../../= =2E./contrib/libstdc++/src/sstream-inst.cc /usr/src/gnu/lib/libstdc++/../..= /../contrib/libstdc++/src/streambuf-inst.cc /usr/src/gnu/lib/libstdc++/../.= =2E/../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/lib/libstdc++/../../= =2E./contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib/libstdc++/../../= =2E./contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib/libstdc++/../.= =2E/../contrib/libstdc++/src/wlocale-inst.cc /usr/src/gnu/lib/libstdc++/../= =2E./../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/sr > c/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/code= cvt_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config= /locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/config/locale/generic/messages_members.cc /u= sr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/m= onetary_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/co= nfig/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/li= bstdc++/../../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/g= nu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_op.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opnt.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib > stdc++/libsupc++/del_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/l= ibstdc++/libsupc++/del_opvnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/libsupc++/eh_alloc.cc /usr/src/gnu/lib/libstdc++/../../../contri= b/libstdc++/libsupc++/eh_arm.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/libsupc++/eh_aux_runtime.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/libsupc++/eh_call.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/libsupc++/eh_catch.cc /usr/src/gnu/lib/libstdc++/../../..= /contrib/libstdc++/libsupc++/eh_exception.cc /usr/src/gnu/lib/libstdc++/../= =2E./../contrib/libstdc++/libsupc++/eh_globals.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/libsupc++/eh_personality.cc /usr/src/gnu/lib/l= ibstdc++/../../../contrib/libstdc++/libsupc++/eh_term_handler.cc /usr/src/g= nu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_terminate.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc /usr= /src/gnu/lib/libstdc++/../../../contrib/libstdc++/li > bsupc++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/= libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/li= bstdc++/libsupc++/guard.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libs= tdc++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/= libstdc++/libsupc++/new_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/l= ibstdc++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/= libstdc++/libsupc++/new_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/= libstdc++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libstdc++/../../../contri= b/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc++/../../../contrib/l= ibstdc++/libsupc++/tinfo.cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib= stdc++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libs= tdc++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc+= +/libsupc++/vterminate.cc > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_alloc.cc:41: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_arm.cc:31: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_aux_runtime.cc:34: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_call.cc:33: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call= =2Ecc:37:23: error: unwind-pe.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_catch.cc:31: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_exception.cc:34: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_globals.cc:35: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_personality.cc:33: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_pers= onality.cc:41:23: error: unwind-pe.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_term_handler.cc:31: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_terminate.cc:34: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_throw.cc:31: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_type.cc:33: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_unex_handler.cc:30: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/pure.cc:32: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/vec.cc:37: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory > > mkdep: compile failed > > *** Error code 1 > > > > Stop in /usr/src/gnu/lib/libstdc++. > > *** Error code 1 > > > > Stop in /usr/src/gnu/lib. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > [ bsdbox ] [ root ] [ /usr/src ] =3D=3D> >=20 > Ran into the same issue with RELENG_8 -> 9-CURRENT. What does your > make.conf // src.conf look like? I just rebuilt world and kernel on 5 separate servers last night. Three are RELENG_7, two are RELENG_8. I encountered no such errors. Missing files or other oddities like the above can stem from local clock problems too -- make or gcc ends up not being able to find something as a result. crontabs that execute ntpdate (bad bad bad!), for example, could cause this. Clocks that drift too much could also cause it (if the system runs ntpd, make sure that ntpq -c peers doesn't constantly list "STEP" as a refid). --=20 | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 23:24:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3194610656BC; Fri, 19 Feb 2010 23:24:16 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id F28118FC38; Fri, 19 Feb 2010 23:24:15 +0000 (UTC) Received: by pwj7 with SMTP id 7so722054pwj.13 for ; Fri, 19 Feb 2010 15:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A7/uYCwtJKtN27b9XAvreM8KmIpO3dF48zO37IgKYZk=; b=H+3eSuOcM2thfQgL6goFXXeTs3sbxREh1BURb1HQYpzWZSAkwjuTQN4ckV/ELMIm4f iYlIzbW7JCGBGrhZUDXRok/cVnVVJwPiWpL6whfZEzWzTuQ0pH7JEcFZZm40UD43oEao x83S+LVhIHgBEdolO58FQW1URc82xQewY7W1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=X2xor7doBzWCvENYK5nRSZy1SVzVBKFiJHnb93tmnUsOBC2SAIRGer9ySe+yadLYCp NzdxqNdTQOcw6wqyYfg7dvbts8EhHMAtMXxWILmGFDuZZF2wqP3bk2o03sXmkOtmWG5W eDY9RJrqVNh72UHZLTrC9lQdxHuk6BHD3C1GU= MIME-Version: 1.0 Received: by 10.143.21.18 with SMTP id y18mr4186019wfi.58.1266621855602; Fri, 19 Feb 2010 15:24:15 -0800 (PST) In-Reply-To: <7d6fde3d1002191338u7f73ddjb2afbdf35bd16b7b@mail.gmail.com> References: <1234698255.13304.37.camel@horst-tla> <7d6fde3d1002191338u7f73ddjb2afbdf35bd16b7b@mail.gmail.com> Date: Fri, 19 Feb 2010 15:24:15 -0800 Message-ID: <7d6fde3d1002191524i2d8c8e41ob4164996d984d4b1@mail.gmail.com> From: Garrett Cooper To: =?ISO-8859-1?Q?Horst_G=FCnther_Burkhardt_III?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , FreeBSD PowerPC ML Subject: Re: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:24:16 -0000 On Fri, Feb 19, 2010 at 1:38 PM, Garrett Cooper wrote: > On Sun, Feb 15, 2009 at 3:44 AM, Horst G=FCnther Burkhardt III > wrote: >> Hey everybody :) >> >> I'm having yet another issue compiling 7-STABLE, just as the last was so= lved, and I _really_ would appreciate some assistance. During `make buildwo= rld`, this error >> occurs: >> >> >> =3D=3D=3D> gnu/lib/libstdc++ (depend) >> ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/= generic/atomicity_mutex/atomicity.h atomicity.cc >> ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h = unwind.h >> rm -f .depend >> mkdep -f .depend -a =A0 =A0-DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gn= u/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/lib= supc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib= /libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/= ../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/include -I. /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libmath/stubs.c /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/li= biberty/cp-demangle.c >> mkdep -f .depend -a =A0 =A0 =A0/usr/src/gnu/lib/libstdc++/../../../contr= ib/libstdc++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc++/../../../co= ntrib/libstdc++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc++/../../../co= ntrib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/= libstdc++/src/compatibility.cc /usr/src/gnu/lib/libstdc++/../../../contrib/= libstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib= stdc++/src/ctype.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/s= rc/debug.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug= _list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functexc= ept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_io= .cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc /usr/s= rc/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc /usr/src= /gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu/= lib/libstdc++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib= /libstdc++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc++/../..= /../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc++/../../../con= trib/libstdc++/src/locale_init.cc /usr/src/gnu/lib/libstdc++/../../../contr= ib/libstdc++/src/locale_facets.cc /usr/src/gnu/lib/libstdc++/../../../contr= ib/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc++/../../../contrib/= libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libs= tdc++/src/strstream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc+= +/src/tree.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/all= ocator-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/co= ncept-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/fst= ream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ext-= inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios-inst.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/iostream-inst.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream-inst.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream.cc /usr= /src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale-inst.cc /usr/s= rc/gnu/lib/libstdc++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/g= nu/lib/libstdc++/../../../contrib/libstdc++/src/ostream-inst.cc /usr/src/gn= u/lib/libstdc++/../../../contrib/libstdc++/src/sstream-inst.cc /usr/src/gnu= /lib/libstdc++/../../../contrib/libstdc++/src/streambuf-inst.cc /usr/src/gn= u/lib/libstdc++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/li= b/libstdc++/../../../contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib/= libstdc++/../../../contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib/= libstdc++/../../../contrib/libstdc++/src/wlocale-inst.cc /usr/src/gnu/lib/l= ibstdc++/../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/s= rc/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/codec= vt_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/= locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../contr= ib/libstdc++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/config/locale/generic/messages_members.cc /us= r/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/mo= netary_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/con= fig/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/lib= stdc++/../../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/gn= u/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_op.cc= /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opnt.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opv.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opvnt= .cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_allo= c.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_arm= .cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux_= runtime.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/= eh_call.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/= eh_catch.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++= /eh_exception.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libs= upc++/eh_globals.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/l= ibsupc++/eh_personality.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libs= tdc++/libsupc++/eh_term_handler.cc /usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/libsupc++/eh_terminate.cc /usr/src/gnu/lib/libstdc++/../../..= /contrib/libstdc++/libsupc++/eh_throw.cc /usr/src/gnu/lib/libstdc++/../../.= ./contrib/libstdc++/libsupc++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../.= ./contrib/libstdc++/libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc++= /../../../contrib/libstdc++/libsupc++/guard.cc /usr/src/gnu/lib/libstdc++/.= ./../../contrib/libstdc++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/libsupc++/new_op.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/libsupc++/new_opv.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libst= dc++/../../../contrib/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/libsupc++/tinfo.cc /usr/src/gnu/lib/libstdc++/= ../../../contrib/libstdc++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc++/.= ./../../contrib/libstdc++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc++/../..= /../contrib/libstdc++/libsupc++/vterminate.cc >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_alloc.cc:41: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_arm.cc:31: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_aux_runtime.cc:34: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_call.cc:33: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.= cc:37:23: error: unwind-pe.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_catch.cc:31: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_exception.cc:34: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_globals.cc:35: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_personality.cc:33: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_perso= nality.cc:41:23: error: unwind-pe.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_term_handler.cc:31: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_terminate.cc:34: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_throw.cc:31: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_type.cc:33: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/eh_unex_handler.cc:30: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/pure.cc:32: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/libsupc++/vec.cc:37: >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-c= xx.h:41:20: error: unwind.h: No such file or directory >> mkdep: compile failed >> *** Error code 1 >> >> Stop in /usr/src/gnu/lib/libstdc++. >> *** Error code 1 >> >> Stop in /usr/src/gnu/lib. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> [ bsdbox ] [ root ] [ /usr/src ] =3D=3D> > > =A0 =A0Ran into the same issue with RELENG_8 -> 9-CURRENT. What does your > make.conf // src.conf look like? Another potential problem that could be introduced (like I think I've tracked down) is when you _set_ C[XX]FLAGS in /etc/make.conf instead of append to it (`:=3D' / `=3D' vs `+=3D'). Stupid mistake that's well documented in the manpage (that's what I get for not setting up a machine from scratch without .conf files in a few years)... Cheers, -Garrett From owner-freebsd-stable@FreeBSD.ORG Fri Feb 19 23:47:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FDE8106566C; Fri, 19 Feb 2010 23:47:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3AA8FC13; Fri, 19 Feb 2010 23:47:17 +0000 (UTC) Received: by pwj7 with SMTP id 7so740525pwj.13 for ; Fri, 19 Feb 2010 15:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vsIsnp8/mpv5CQ2gGXPcDsWqpglgb4wPVmgEbpzas4Y=; b=P/QqIySe7D1pCF8uthGffzaKBnR3a7Jg7BdIBM6yuEF2OAlMQ2g/67xBP5Sk5pJKlm T0FOJ3/yoicWrVTx3RH/WIANTc0rlR7COT4t36sOjwT94sY2ViVQijXuyIFSNOMq89XP TRFx3F2RwjygKvoM8tkl3c40Cuxq7Lg6qEdGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JTNBKR3zxqCwZVwwkq2+tq2nGCKnAtfsPX04/bI7TXMICVceh2suoVuA1Kgo5AzApD A6HT+3WzlRE1H/nIhLer59DPOn75ufFh+Ij0HLthmFLBS3plTcTbl19wiWarBld/79Ev uyrRq7N/WTjT0X9u25uDYdycP1xNwvBKCDNyg= MIME-Version: 1.0 Received: by 10.142.60.7 with SMTP id i7mr717788wfa.202.1266623236932; Fri, 19 Feb 2010 15:47:16 -0800 (PST) In-Reply-To: <7d6fde3d1002191524i2d8c8e41ob4164996d984d4b1@mail.gmail.com> References: <1234698255.13304.37.camel@horst-tla> <7d6fde3d1002191338u7f73ddjb2afbdf35bd16b7b@mail.gmail.com> <7d6fde3d1002191524i2d8c8e41ob4164996d984d4b1@mail.gmail.com> Date: Fri, 19 Feb 2010 15:47:16 -0800 Message-ID: <7d6fde3d1002191547l3765a55kc856dd4d17302be0@mail.gmail.com> From: Garrett Cooper To: =?ISO-8859-1?Q?Horst_G=FCnther_Burkhardt_III?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , FreeBSD PowerPC ML Subject: Re: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:47:17 -0000 On Fri, Feb 19, 2010 at 3:24 PM, Garrett Cooper wrote: > On Fri, Feb 19, 2010 at 1:38 PM, Garrett Cooper wrot= e: >> On Sun, Feb 15, 2009 at 3:44 AM, Horst G=FCnther Burkhardt III >> wrote: >>> Hey everybody :) >>> >>> I'm having yet another issue compiling 7-STABLE, just as the last was s= olved, and I _really_ would appreciate some assistance. During `make buildw= orld`, this error >>> occurs: >>> >>> >>> =3D=3D=3D> gnu/lib/libstdc++ (depend) >>> ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu= /generic/atomicity_mutex/atomicity.h atomicity.cc >>> ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h= unwind.h >>> rm -f .depend >>> mkdep -f .depend -a =A0 =A0-DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/g= nu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/li= bsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/li= b/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++= /../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../con= trib/libstdc++/include -I. /usr/src/gnu/lib/libstdc++/../../../contrib/libs= tdc++/libmath/stubs.c /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/l= ibiberty/cp-demangle.c >>> mkdep -f .depend -a =A0 =A0 =A0/usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/src/compatibility.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/li= bstdc++/src/ctype.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/= src/debug.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debu= g_list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functex= cept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_i= o.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu= /lib/libstdc++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/li= b/libstdc++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libst= dc++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc++/../.= ./../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc++/../../../co= ntrib/libstdc++/src/locale_init.cc /usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/src/locale_facets.cc /usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib= stdc++/src/strstream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc= ++/src/tree.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/al= locator-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/c= oncept-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/fs= tream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ext= -inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios-inst= .cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/iostream-inst= .cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream-inst.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream.cc /us= r/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale-inst.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/= gnu/lib/libstdc++/../../../contrib/libstdc++/src/ostream-inst.cc /usr/src/g= nu/lib/libstdc++/../../../contrib/libstdc++/src/sstream-inst.cc /usr/src/gn= u/lib/libstdc++/../../../contrib/libstdc++/src/streambuf-inst.cc /usr/src/g= nu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/l= ib/libstdc++/../../../contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib= /libstdc++/../../../contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib= /libstdc++/../../../contrib/libstdc++/src/wlocale-inst.cc /usr/src/gnu/lib/= libstdc++/../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/code= cvt_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config= /locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../cont= rib/libstdc++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/config/locale/generic/messages_members.cc /u= sr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/m= onetary_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/co= nfig/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/li= bstdc++/../../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/g= nu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_op.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opnt.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opv.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opvn= t.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_all= oc.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_ar= m.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux= _runtime.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++= /eh_call.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++= /eh_catch.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc+= +/eh_exception.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/lib= supc++/eh_globals.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/= libsupc++/eh_personality.cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib= stdc++/libsupc++/eh_term_handler.cc /usr/src/gnu/lib/libstdc++/../../../con= trib/libstdc++/libsupc++/eh_terminate.cc /usr/src/gnu/lib/libstdc++/../../.= ./contrib/libstdc++/libsupc++/eh_throw.cc /usr/src/gnu/lib/libstdc++/../../= ../contrib/libstdc++/libsupc++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../= ../contrib/libstdc++/libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/libsupc++/guard.cc /usr/src/gnu/lib/libstdc++/= ../../../contrib/libstdc++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/libsupc++/new_op.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/libsupc++/new_opv.cc /usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libs= tdc++/../../../contrib/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/libsupc++/tinfo.cc /usr/src/gnu/lib/libstdc++= /../../../contrib/libstdc++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc++/= ../../../contrib/libstdc++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc++/../.= ./../contrib/libstdc++/libsupc++/vterminate.cc >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_alloc.cc:41: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_arm.cc:31: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_aux_runtime.cc:34: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_call.cc:33: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call= .cc:37:23: error: unwind-pe.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_catch.cc:31: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_exception.cc:34: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_globals.cc:35: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_personality.cc:33: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_pers= onality.cc:41:23: error: unwind-pe.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_term_handler.cc:31: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_terminate.cc:34: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_throw.cc:31: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_type.cc:33: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_unex_handler.cc:30: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/pure.cc:32: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/vec.cc:37: >>> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-= cxx.h:41:20: error: unwind.h: No such file or directory >>> mkdep: compile failed >>> *** Error code 1 >>> >>> Stop in /usr/src/gnu/lib/libstdc++. >>> *** Error code 1 >>> >>> Stop in /usr/src/gnu/lib. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> [ bsdbox ] [ root ] [ /usr/src ] =3D=3D> >> >> =A0 =A0Ran into the same issue with RELENG_8 -> 9-CURRENT. What does you= r >> make.conf // src.conf look like? > > =A0 =A0Another potential problem that could be introduced (like I think > I've tracked down) is when you _set_ C[XX]FLAGS in /etc/make.conf > instead of append to it (`:=3D' / `=3D' vs `+=3D'). Stupid mistake that's > well documented in the manpage (that's what I get for not setting up a > machine from scratch without .conf files in a few years)... And bingo, that was my problem and it's now solved... Cheers, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 01:53:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6C92106566B for ; Sat, 20 Feb 2010 01:53:59 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 4075E8FC18 for ; Sat, 20 Feb 2010 01:53:58 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1K1rrQv027747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Feb 2010 12:53:54 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1K1rqCq019546; Sat, 20 Feb 2010 12:53:52 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1K1rpRC019545; Sat, 20 Feb 2010 12:53:51 +1100 (EST) (envelope-from peter) Date: Sat, 20 Feb 2010 12:53:51 +1100 From: Peter Jeremy To: Torfinn Ingolfsen Message-ID: <20100220015351.GB81639@server.vk2pj.dyndns.org> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 01:53:59 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-19 00:38:44 +0100, Torfinn Ingolfsen wrote: >root@kg-f2# sysctl machdep.acpi_timer_freq=3D3577045 >machdep.acpi_timer_freq: 3579545 -> 3577045 Looks reasonable. Let us know the results. I'd be interested in the output from "ntpdc -c loopi -c sysi". --=20 Peter Jeremy --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt/QK8ACgkQ/opHv/APuIe11ACcDb4NchMGUlQ4TcB8Lv0EEATh voMAoJGLrrdOyBPYj68wq8xPFir0X8il =wgHs -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 19:21:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2801065672 for ; Sat, 20 Feb 2010 19:21:24 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 360D88FC18 for ; Sat, 20 Feb 2010 19:21:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY5004YIN39N340@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 20 Feb 2010 20:21:09 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY5005K1N3875J0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 20 Feb 2010 20:21:09 +0100 (CET) Date: Sat, 20 Feb 2010 20:21:08 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 19:21:24 -0000 Another day, another crash. >From /var/log/messages: Feb 20 08:52:26 kg-f2 ntpd[58609]: time reset +1.169751 s Feb 20 08:54:57 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 20 08:54:57 kg-f2 kernel: ata5: hardware reset timeout Feb 20 19:18:51 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel The drives are as follows: root@kg-f2# atacontrol list;camcontrol devlist ATA channel 0: Master: no device present Slave: no device present ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: ad6 SATA revision 2.x Slave: no device present ATA channel 4: Master: ad8 SATA revision 2.x Slave: no device present ATA channel 5: Master: ad10 SATA revision 2.x Slave: no device present ATA channel 6: Master: ad12 SATA revision 2.x Slave: no device present ATA channel 7: Master: ad14 SATA revision 2.x Slave: no device present at scbus0 target 0 lun 0 (pass0,ada0) Smartctl is happy, too: root@kg-f2# smartctl -H /dev/ad4 smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED root@kg-f2# smartctl -H /dev/ad6 smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED root@kg-f2# smartctl -H /dev/ad8 smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED root@kg-f2# smartctl -H /dev/ad10 smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED root@kg-f2# smartctl -H /dev/ad12 smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED root@kg-f2# smartctl -H /dev/ada0 smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED Maybe the hardware is just plain broken. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 19:37:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FCEC1065670 for ; Sat, 20 Feb 2010 19:37:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 02DC78FC12 for ; Sat, 20 Feb 2010 19:37:19 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id kJYT1d0031vN32cACKdL3J; Sat, 20 Feb 2010 19:37:20 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id kKfd1d0013S48mS8iKfdll; Sat, 20 Feb 2010 19:39:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 69C841E301A; Sat, 20 Feb 2010 11:37:18 -0800 (PST) Date: Sat, 20 Feb 2010 11:37:18 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100220193718.GA33214@icarus.home.lan> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 19:37:21 -0000 On Sat, Feb 20, 2010 at 08:21:08PM +0100, Torfinn Ingolfsen wrote: > Another day, another crash. > >From /var/log/messages: > Feb 20 08:52:26 kg-f2 ntpd[58609]: time reset +1.169751 s > Feb 20 08:54:57 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f > Feb 20 08:54:57 kg-f2 kernel: ata5: hardware reset timeout > Feb 20 19:18:51 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel > > The drives are as follows: > root@kg-f2# atacontrol list;camcontrol devlist > ATA channel 0: > Master: no device present > Slave: no device present > ATA channel 2: > Master: ad4 SATA revision 2.x > Slave: no device present > ATA channel 3: > Master: ad6 SATA revision 2.x > Slave: no device present > ATA channel 4: > Master: ad8 SATA revision 2.x > Slave: no device present > ATA channel 5: > Master: ad10 SATA revision 2.x > Slave: no device present > ATA channel 6: > Master: ad12 SATA revision 2.x > Slave: no device present > ATA channel 7: > Master: ad14 SATA revision 2.x > Slave: no device present > at scbus0 target 0 lun 0 (pass0,ada0) > > Smartctl is happy, too: > root@kg-f2# smartctl -H /dev/ad4 > smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) > Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > root@kg-f2# smartctl -H /dev/ad6 > smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) > Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > root@kg-f2# smartctl -H /dev/ad8 > smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) > Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > root@kg-f2# smartctl -H /dev/ad10 > smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) > Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > root@kg-f2# smartctl -H /dev/ad12 > smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) > Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > root@kg-f2# smartctl -H /dev/ada0 > smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) > Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > Maybe the hardware is just plain broken. Can you re-run smartctl -a instead of -H? Some of the SMART attributes may help determine what's going on, or there may be related errors in the SMART error log. Otherwise I'd say what's happening is a SATA controller lock-up of some sort, since it happens on any of your channels. Could be a quirk of some kind in the SATA->CAM stuff (unless it also happens when using pure ata(4)). What controller are these disks hooked to again? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 21:32:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84DE106566C for ; Sat, 20 Feb 2010 21:32:03 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id A028D8FC0A for ; Sat, 20 Feb 2010 21:32:03 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY5008RYT5EXR80@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 20 Feb 2010 22:32:02 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY5001TZT5EOJ81@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 20 Feb 2010 22:32:02 +0100 (CET) Date: Sat, 20 Feb 2010 22:32:01 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100220015351.GB81639@server.vk2pj.dyndns.org> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 21:32:04 -0000 On Sat, 20 Feb 2010 12:53:51 +1100 Peter Jeremy wrote: > Looks reasonable. Let us know the results. I'd be interested in > the output from "ntpdc -c loopi -c sysi". Ok, here we go (the server panic'ed again last night): root@kg-f2# uptime 10:28PM up 2:26, 3 users, load averages: 0.00, 0.00, 0.00 root@kg-f2# sysctl machdep.acpi_timer_freq machdep.acpi_timer_freq: 3577045 root@kg-f2# tvlm Feb 20 20:06:41 kg-f2 ntpd[942]: kernel time sync status change 2001 Feb 20 20:21:49 kg-f2 ntpd[942]: time reset +1.118880 s Feb 20 20:37:53 kg-f2 ntpd[942]: time reset +1.188538 s Feb 20 20:53:03 kg-f2 ntpd[942]: time reset +1.121903 s Feb 20 21:09:00 kg-f2 ntpd[942]: time reset +1.179924 s Feb 20 21:24:57 kg-f2 ntpd[942]: time reset +1.178490 s Feb 20 21:39:58 kg-f2 ntpd[942]: time reset +1.110647 s Feb 20 21:55:53 kg-f2 ntpd[942]: time reset +1.177292 s Feb 20 22:11:44 kg-f2 ntpd[942]: time reset +1.172358 s Feb 20 22:26:48 kg-f2 ntpd[942]: time reset +1.114350 s root@kg-f2# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== kg-omni1.kg4.no 129.240.64.3 3 u 8 64 7 0.176 133.306 77.731 root@kg-f2# ntpdc -c loopi -c sysi offset: 0.000000 s frequency: 500.000 ppm poll adjust: 4 watchdog timer: 194 s system peer: 0.0.0.0 system peer mode: unspec leap indicator: 11 stratum: 16 precision: -18 root distance: 0.00000 s root dispersion: 0.00290 s reference ID: [83.84.69.80] reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000 system flags: auth monitor ntp kernel stats jitter: 0.358109 s stability: 0.000 ppm broadcastdelay: 0.003998 s authdelay: 0.000000 s Not synced at all. Not good. :-/ Perhaps I should give it more time? -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 21:44:52 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6297B106566B for ; Sat, 20 Feb 2010 21:44:52 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id C73D28FC0C for ; Sat, 20 Feb 2010 21:44:51 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Nix86-0009GX-H5; Sun, 21 Feb 2010 00:44:50 +0300 Date: Sun, 21 Feb 2010 00:44:50 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100220214450.GV55307@zxy.spb.ru> References: <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> <20100219211201.GL11675@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219211201.GL11675@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 21:44:52 -0000 On Fri, Feb 19, 2010 at 01:12:01PM -0800, Pyun YongHyeon wrote: > Normally you should not have any FCS errors, it could be related > with signal quality and these errors might not be correctly > counted. I can't check cable and switch counters on bge1 before Feb 24. > > 3. packets don't lost on sources at Aug'09 > > Since I don't have BCM5704 hardware it's hard to find which > revision may affect to this issue. Could you narrow down which > revision number started showing the issue? I am don't update source between Aug'09 and Feb 16. 4. Packets don't lost immediately after reboot. PS: I got kernel panic. === Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff802eb3b7 stack pointer = 0x28:0xffffff80001c66e0 frame pointer = 0x28:0xffffff8 01c6740 code segment = base 0x0, limi 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 724 (named) [thread pid 724 tid 100051 ] Stopped at m_copym+0x37: movl 0x18(%r12),%eax db> panic panic: from debugger cpuid = 0 Uptime: 1d5h55m33s Physical memory: 2039 MB Dumping 1448 MB: 1433 1417 1401 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 21:50:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32DEC106566B for ; Sat, 20 Feb 2010 21:50:04 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id A941F8FC17 for ; Sat, 20 Feb 2010 21:50:03 +0000 (UTC) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_5X2EXmL0BjmV9PkJJ/E9DA)" Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY5008A6TZEXRB0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 20 Feb 2010 22:50:02 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY5001W5TZBOJA1@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 20 Feb 2010 22:50:02 +0100 (CET) Date: Sat, 20 Feb 2010 22:49:59 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100220193718.GA33214@icarus.home.lan> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> <20100220193718.GA33214@icarus.home.lan> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 21:50:04 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5X2EXmL0BjmV9PkJJ/E9DA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT On Sat, 20 Feb 2010 11:37:18 -0800 Jeremy Chadwick wrote: > Can you re-run smartctl -a instead of -H? Some of the SMART attributes > may help determine what's going on, or there may be related errors in > the SMART error log. smartctl -a output attached. Test sequence: ad4 - ad12, ada0. > Otherwise I'd say what's happening is a SATA controller lock-up of some > sort, since it happens on any of your channels. Could be a quirk of > some kind in the SATA->CAM stuff (unless it also happens when using pure > ata(4)). I am running a quite recent 8.0-stable: root@kg-f2# uname -a FreeBSD kg-f2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #2: Sun Jan 31 18:39:17 CET 2010 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 Perhaps I should upgrade. > What controller are these disks hooked to again? Six of the disks (ad4, ad6, ad8, ad10, ad12) are connected to the SATA ports on the motherboard: root@kg-f2# pciconf -lv | grep ata -A 4 atapci0@pci0:0:17:0: class=0x010601 card=0xb0021458 chip=0x43911002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 SATA Controller [AHCI mode]' class = mass storage subclass = SATA -- atapci1@pci0:0:20:1: class=0x01018a card=0x50021458 chip=0x439c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'PATA 133 Controller (SB7xx)' class = mass storage subclass = ATA (There is nothing connected to the PATA ports). The last disk (ada0) is connected to a PCI card: oot@kg-f2# pciconf -lv | grep siis -A 3 siis0@pci0:2:0:0: class=0x018000 card=0x35311095 chip=0x35311095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SiI 3531 SATA Controller' class = mass storage Hardware info about the machine here: http://sites.google.com/site/tingox/ga-ma74gm-s2h HTH -- Torfinn --Boundary_(ID_5X2EXmL0BjmV9PkJJ/E9DA) Content-type: text/plain; name=f2-smartctl-20100220.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=f2-smartctl-20100220.txt smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint F1 DT series Device Model: SAMSUNG HD252HJ Serial Number: S17HJ9BSA04283 Firmware Version: 1AC01118 User Capacity: 250,059,350,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Sat Feb 20 22:44:11 2010 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (3651) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 62) minutes. Conveyance self-test routine recommended polling time: ( 8) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 092 092 011 Pre-fail Always - 3260 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1705 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 068 064 000 Old_age Always - 32 (Lifetime Min/Max 21/32) 194 Temperature_Celsius 0x0022 065 062 000 Old_age Always - 35 (Lifetime Min/Max 21/35) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 932 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint F1 DT series Device Model: SAMSUNG HD252HJ Serial Number: S17HJ9BSA04051 Firmware Version: 1AC01118 User Capacity: 250,059,350,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Sat Feb 20 22:44:20 2010 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (3763) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 64) minutes. Conveyance self-test routine recommended polling time: ( 8) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 092 092 011 Pre-fail Always - 3380 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1705 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 069 064 000 Old_age Always - 31 (Lifetime Min/Max 22/31) 194 Temperature_Celsius 0x0022 066 063 000 Old_age Always - 34 (Lifetime Min/Max 22/34) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1337 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: SAMSUNG HD103SJ Serial Number: S246J1KSB01853 Firmware Version: 1AJ100E4 User Capacity: 1,000,204,886,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Sat Feb 20 22:44:35 2010 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (9120) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 152) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 252 252 051 Pre-fail Always - 0 2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0 3 Spin_Up_Time 0x0023 073 073 025 Pre-fail Always - 8226 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 11 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0 8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1679 10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 12 191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 1 192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0 194 Temperature_Celsius 0x0002 063 061 000 Old_age Always - 37 (Lifetime Min/Max 26/39) 195 Hardware_ECC_Recovered 0x003a 252 252 000 Old_age Always - 0 196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x002a 252 252 000 Old_age Always - 0 223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 12 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] Note: selective self-test log revision number (0) not 1 implies that no selective self-test has ever been run SMART Selective self-test log data structure revision number 0 Note: revision number not 1 implies that no selective self-test has ever been run SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Completed [00% left] (0-65535) 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: SAMSUNG HD103SJ Serial Number: S246J1KSB01864 Firmware Version: 1AJ100E4 User Capacity: 1,000,204,886,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Sat Feb 20 22:44:45 2010 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (9300) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 155) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 252 252 051 Pre-fail Always - 0 2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0 3 Spin_Up_Time 0x0023 073 073 025 Pre-fail Always - 8253 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 26 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0 8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1677 10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 27 191 G-Sense_Error_Rate 0x0022 252 252 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0 194 Temperature_Celsius 0x0002 063 060 000 Old_age Always - 37 (Lifetime Min/Max 26/40) 195 Hardware_ECC_Recovered 0x003a 252 252 000 Old_age Always - 0 196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x002a 252 252 000 Old_age Always - 0 223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 27 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] Note: selective self-test log revision number (0) not 1 implies that no selective self-test has ever been run SMART Selective self-test log data structure revision number 0 Note: revision number not 1 implies that no selective self-test has ever been run SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Completed [00% left] (0-65535) 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: SAMSUNG HD103SJ Serial Number: S246J1KSB01865 Firmware Version: 1AJ100E4 User Capacity: 1,000,204,886,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Sat Feb 20 22:44:57 2010 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (9540) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 159) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 252 252 051 Pre-fail Always - 0 2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0 3 Spin_Up_Time 0x0023 073 073 025 Pre-fail Always - 8213 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 26 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0 8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1676 10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 27 191 G-Sense_Error_Rate 0x0022 252 252 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0 194 Temperature_Celsius 0x0002 064 062 000 Old_age Always - 35 (Lifetime Min/Max 25/38) 195 Hardware_ECC_Recovered 0x003a 252 252 000 Old_age Always - 0 196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x002a 252 252 000 Old_age Always - 0 223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 27 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] Note: selective self-test log revision number (0) not 1 implies that no selective self-test has ever been run SMART Selective self-test log data structure revision number 0 Note: revision number not 1 implies that no selective self-test has ever been run SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Completed [00% left] (0-65535) 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. smartctl 5.39 2009-12-09 r2995 [FreeBSD 8.0-STABLE amd64] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: SAMSUNG HD103SJ Serial Number: S246J1KSB01867 Firmware Version: 1AJ100E4 User Capacity: 1,000,204,886,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Sat Feb 20 22:45:10 2010 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (9420) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 157) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 252 252 051 Pre-fail Always - 0 2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0 3 Spin_Up_Time 0x0023 073 073 025 Pre-fail Always - 8183 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 8 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0 8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 1679 10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 12 191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 1 192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0 194 Temperature_Celsius 0x0002 064 064 000 Old_age Always - 33 (Lifetime Min/Max 22/35) 195 Hardware_ECC_Recovered 0x003a 252 252 000 Old_age Always - 0 196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x002a 252 252 000 Old_age Always - 0 223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0 225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 12 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] Note: selective self-test log revision number (0) not 1 implies that no selective self-test has ever been run SMART Selective self-test log data structure revision number 0 Note: revision number not 1 implies that no selective self-test has ever been run SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Completed [00% left] (0-65535) 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. --Boundary_(ID_5X2EXmL0BjmV9PkJJ/E9DA)-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 21:55:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA46010656B2 for ; Sat, 20 Feb 2010 21:55:53 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 614508FC12 for ; Sat, 20 Feb 2010 21:55:53 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY500822U89XRC0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 20 Feb 2010 22:55:21 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY500BANU897KM0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 20 Feb 2010 22:55:21 +0100 (CET) Date: Sat, 20 Feb 2010 22:55:21 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100220225521.18586aaf.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 21:55:53 -0000 On Sat, 20 Feb 2010 22:32:01 +0100 Torfinn Ingolfsen wrote: This output looks ... wrong ... somehow to my eyes: root@kg-f2# date Sat Feb 20 22:51:24 CET 2010 root@kg-f2# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *kg-omni1.kg4.no 129.240.64.3 3 u 62 64 377 0.244 597.314 360.123 root@kg-f2# ntpdc -c loopi -c sysi offset: 0.000000 s frequency: 500.000 ppm poll adjust: 4 watchdog timer: 549 s system peer: kg-omni1.kg4.no system peer mode: client leap indicator: 11 stratum: 16 precision: -18 root distance: 0.00000 s root dispersion: 0.00822 s reference ID: [10.1.10.1] reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000 system flags: auth monitor ntp kernel stats jitter: 0.360107 s stability: 0.000 ppm broadcastdelay: 0.003998 s authdelay: 0.000000 s Shouldn't ntpq and ntpdc be in agreement? -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 22:19:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86EB0106566C; Sat, 20 Feb 2010 22:19:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 1EFE58FC08; Sat, 20 Feb 2010 22:19:39 +0000 (UTC) Received: by iwn15 with SMTP id 15so1350858iwn.7 for ; Sat, 20 Feb 2010 14:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=n+90xLH9qr8zVsECyDAh5icnNh6C+ve2ovdINOaP7Lg=; b=QhAEuGgmoT9D40iq/ooqVidTfw3sauC7L6hX5+ZQ313a7usG0bS448tmSoktds5W+J f0N6DctkkVvXRr/UpiCqc8hk+nMmaR/MsA1P1gYnB8fcbLOCYsSYgw+QCwLL6vojcc2N UNFAAXVH5EQpWgu5iAX0BpCrClh6TKDLomYeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=kSBqHTntFome8WJfSpA9RQNB/iTV0ysfzhwymF4S/oXtb3cYCHVkGskso+sv/ZV0iO nkrPTmz5twA/h2HPr1yh4PJoDcWoMmLTbDGUGt1zQi/hYPA8jyvodKswNyp+kVEHXj+E 4wtuVw/cVVSBUBbG9rb1nWFReEGz14mY/kcTg= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.144.201 with SMTP id a9mr2641556ibv.69.1266704379191; Sat, 20 Feb 2010 14:19:39 -0800 (PST) In-Reply-To: <179b97fb1001270941m2d8e9c8au20abc798c16b9c11@mail.gmail.com> References: <179b97fb1001270941m2d8e9c8au20abc798c16b9c11@mail.gmail.com> Date: Sat, 20 Feb 2010 23:19:39 +0100 X-Google-Sender-Auth: 5d13842cfb9ed9df Message-ID: <3bbf2fe11002201419v52b249ccg8d82c8ae747cf318@mail.gmail.com> From: Attilio Rao To: Brandon Gooch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-emulation@freebsd.org, stable-list freebsd , John Baldwin Subject: Re: ZFS and sh(1) panic: spin lock [lock addr] (smp rendezvous) held by [sh(1) proc tid] too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 22:19:40 -0000 2010/1/27 Brandon Gooch : > The machine, a Dell Optiplex 755, has been locking up recently. The > situation usually occurs while using VirtualBox (running a 64-bit > Windows 7 instance) and doing anything else in another xterm (such as > rebuilding a port). =C2=A0I've been unable to reliably reproduce it (I'm = in > an X session and the machine will not panic "properly"). > > However, while rebuilding Xorg today at ttyv0 and runnning > VBoxHeadless on ttyv1, I managed to trigger what I believe is the > lockup. > > I've attached a textdump in hopes that someone may be able to take a > look and provide clues or instruction on debugging this. I think that jhb@ saw a similar problem while working on nVidia driver or the like. Not sure if he made any progress to debug this. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 23:35:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD6B71065672 for ; Sat, 20 Feb 2010 23:35:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id B04A38FC12 for ; Sat, 20 Feb 2010 23:35:47 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta11.emeryville.ca.mail.comcast.net with comcast id kNtS1d0090x6nqcABPYl7F; Sat, 20 Feb 2010 23:32:45 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta12.emeryville.ca.mail.comcast.net with comcast id kPbn1d0023S48mS8YPbnUy; Sat, 20 Feb 2010 23:35:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 29BCD1E301A; Sat, 20 Feb 2010 15:35:46 -0800 (PST) Date: Sat, 20 Feb 2010 15:35:46 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100220233546.GA36973@icarus.home.lan> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> <20100220193718.GA33214@icarus.home.lan> <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 23:35:48 -0000 On Sat, Feb 20, 2010 at 10:49:59PM +0100, Torfinn Ingolfsen wrote: > On Sat, 20 Feb 2010 11:37:18 -0800 > Jeremy Chadwick wrote: > > > Can you re-run smartctl -a instead of -H? Some of the SMART attributes > > may help determine what's going on, or there may be related errors in > > the SMART error log. > > smartctl -a output attached. Test sequence: ad4 - ad12, ada0. Most of your disks look to be in decent shape. Well, that is to say, all of them should be working fine; I don't see anything that's of major, or even minor concern. Others might focus on Attributes 191 or 195, but neither of those are absurdly high given the number of hours these disks have been in use (see Attribute 9). > > Otherwise I'd say what's happening is a SATA controller lock-up of some > > sort, since it happens on any of your channels. Could be a quirk of > > some kind in the SATA->CAM stuff (unless it also happens when using pure > > ata(4)). > > I am running a quite recent 8.0-stable: > root@kg-f2# uname -a > FreeBSD kg-f2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #2: Sun Jan 31 18:39:17 CET 2010 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 > > Perhaps I should upgrade. > > > What controller are these disks hooked to again? > > Six of the disks (ad4, ad6, ad8, ad10, ad12) are connected to the SATA ports on the motherboard: > root@kg-f2# pciconf -lv | grep ata -A 4 > atapci0@pci0:0:17:0: class=0x010601 card=0xb0021458 chip=0x43911002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 SATA Controller [AHCI mode]' > class = mass storage > subclass = SATA Let's backtrack a bit. I've gone back and read through all of your previous posts on this matter, and so far all the problems are happening on ata5 and ata6. No timeouts or anomalies have appeared on any other ports -- just those two. The kernel error messages indicate that commands submit to the controller took longer than 10 seconds to get a response, so the OS does a force-reset of the ports in attempt to get things working again. We can safely rule out the Silicon Image controller (otherwise "ataX" wouldn't be involved), which leaves the AMD SB700 SATA controller and the AMD SB700 PATA controller. What exact disks (e.g. adX) are attached to ata5 and ata6? You haven't provided dmesg output in any of your posts, and atacontrol/pciconf is not sufficient (I should really improve atacontrol by printing this information. I'll work on that in a few minutes). Some Linux users have reported AHCI-related issues with the SB600 southbridge, but the core of the problem turned out to be MSI on certain AMD northbridges (specifically RS480, RS400, and RS200). By disabling MSI entirely they were able to achieve stability. The FreeBSD equivalent would be to set the following in loader.conf and reboot: hw.pci.enable_msix="0" hw.pci.enable_msi="0" The Linux quirk fix for this: http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=queue-2.6.21/pci-quirks-disable-msi-on-rs400-200-and-rs480.patch;hb=05ab505f2909acf3a614d3e6a32271c4c1f8a69d Your board has an AMD 740G northbridge, but it might be worth trying the MSI disable trick anyway. If it doesn't fix the problem then definitely re-enable MSI. Isn't hardware fun? ;-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Feb 20 23:42:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29CE8106566B for ; Sat, 20 Feb 2010 23:42:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7A98FC18 for ; Sat, 20 Feb 2010 23:42:35 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta07.emeryville.ca.mail.comcast.net with comcast id kPK51d0061zF43QA7PicTm; Sat, 20 Feb 2010 23:42:36 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta24.emeryville.ca.mail.comcast.net with comcast id kPkN1d0013S48mS8kPkNJ7; Sat, 20 Feb 2010 23:44:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 366B01E301A; Sat, 20 Feb 2010 15:42:34 -0800 (PST) Date: Sat, 20 Feb 2010 15:42:34 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100220234234.GB36973@icarus.home.lan> References: <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100220225521.18586aaf.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100220225521.18586aaf.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 23:42:36 -0000 On Sat, Feb 20, 2010 at 10:55:21PM +0100, Torfinn Ingolfsen wrote: > On Sat, 20 Feb 2010 22:32:01 +0100 > Torfinn Ingolfsen wrote: > > > This output looks ... wrong ... somehow to my eyes: > root@kg-f2# date > Sat Feb 20 22:51:24 CET 2010 > root@kg-f2# ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > *kg-omni1.kg4.no 129.240.64.3 3 u 62 64 377 0.244 597.314 360.123 > root@kg-f2# ntpdc -c loopi -c sysi > offset: 0.000000 s > frequency: 500.000 ppm > poll adjust: 4 > watchdog timer: 549 s > system peer: kg-omni1.kg4.no > system peer mode: client > leap indicator: 11 > stratum: 16 > precision: -18 > root distance: 0.00000 s > root dispersion: 0.00822 s > reference ID: [10.1.10.1] > reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000 > system flags: auth monitor ntp kernel stats > jitter: 0.360107 s > stability: 0.000 ppm > broadcastdelay: 0.003998 s > authdelay: 0.000000 s > > Shouldn't ntpq and ntpdc be in agreement? ntpq and ntpdc output data in slightly different formats, depending on what arguments you give them. I'm not familiar with the loopi or sysi commands; Peter should be able to help here. For sake of example -- look at ntpq's "delay" column for each peer, and then look at the same column but for ntpdc. You'll see that for ntpdc they're divided by 1000 (presumably kern.hz rate): $ ntpq -c peers remote refid st t when poll reach delay offset jitter ============================================================================== +clock-a.develoo 204.123.2.72 2 u 476 512 377 25.287 -0.852 0.550 -enigma.wiredgoa 209.81.9.7 2 u 185 512 377 14.754 0.284 0.688 +mtnlion.com 139.78.135.14 2 u 208 512 377 30.788 -0.233 0.160 *ntp1.phoenixpub .LCL. 1 u 179 512 377 36.322 -0.552 0.522 -ntp-1.gw.uiuc.e 128.174.38.133 2 u 141 512 377 77.321 -5.381 0.328 -tick.jrc.us 172.21.0.14 2 u 149 512 377 112.424 -8.110 1.440 $ ntpdc -c peers remote local st poll reach delay offset disp ======================================================================= *mailserv1.phoen 192.168.1.51 1 512 377 0.03632 -0.000552 0.09666 =clock-a.develoo 192.168.1.51 2 512 377 0.02528 -0.000852 0.08611 =tick.jrc.us 192.168.1.51 2 512 377 0.11241 -0.008110 0.08615 =enigma.wiredgoa 192.168.1.51 2 512 377 0.01474 0.000284 0.11473 =mtnlion.com 192.168.1.51 2 512 377 0.03078 -0.000233 0.09665 =ntp-1.gw.uiuc.e 192.168.1.51 2 512 377 0.07732 -0.005381 0.10612 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |