From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 04:49:48 2011 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 64006106564A for ; Sun, 9 Jan 2011 04:49:48 +0000 (UTC) (envelope-from jyavenard@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E10C8FC0C for ; Sun, 9 Jan 2011 04:49:47 +0000 (UTC) Received: by iwn39 with SMTP id 39so18619190iwn.13 for ; Sat, 08 Jan 2011 20: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:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=4K9LiL3/oK+2pBDKgok4pLKjeqrepl/jFdLg3ALraCI=; b=VnmgBBdwaMOdyuU3v9UprVXK3k2yddRFRb4eUFFDMQ6f+1SBb4GPOM/O+sQFGLGeEc x2xaoNBK1TJm6YO+/hn53qZt7a3ESq5IHAL1IO6uS/v+YR2l0lNKqO5ZQRp2+hRkXWZh bQyFRbXWC7a/k7MoIZSqd7SKLRZNnXNsrbsFU= 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=SfdJMORFEdx+cSJT7afBWKTSHBt5BK8aq5P9CAic30tkBYtsKjvkUaPJJD0m4LHlug w/0sTci8AqSqmoRVj7VA5XDlz7XAHHBfKwfU9Ue7Mq/IXwgwwxdy1ZlQxlwKfcOZu/me 6i9U4DfFi9uJcFcRiR0GAh/z7Ns8/WcbM5kWc= MIME-Version: 1.0 Received: by 10.42.218.129 with SMTP id hq1mr2689343icb.263.1294548586033; Sat, 08 Jan 2011 20:49:46 -0800 (PST) Received: by 10.42.172.69 with HTTP; Sat, 8 Jan 2011 20:49:46 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Jan 2011 15:49:46 +1100 Message-ID: From: Jean-Yves Avenard To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: faulted zpool , do not resilver 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, 09 Jan 2011 04:49:48 -0000 Hi responding to myself here.. I ran zpool scrub on it. It started to resilver ; but then I got: Problems with ZFS: pool: pool state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: resilver completed after 4h33m with 7 errors on Sun Jan 9 08:23:12 2011 config: NAME STATE READ WRITE CKSUM pool DEGRADED 0 0 9 raidz2 DEGRADED 0 0 54 ada5 ONLINE 0 0 0 3.07G resilvered ada6 ONLINE 0 0 0 2.92G resilvered ada2 ONLINE 0 0 0 3.07G resilvered ada1 ONLINE 0 0 0 2.92G resilvered replacing DEGRADED 0 0 1 1880266799568700877 UNAVAIL 0 1.92M 0 was /dev/da0 ada4 ONLINE 0 0 0 409G resilvered replacing DEGRADED 0 0 2 1406029845814225421 UNAVAIL 0 1.88M 0 was /dev/da0 ada3 ONLINE 0 0 0 408G resilvered errors: 2 data errors, use '-v' for a list I did zpool export / import ; and I'm back again to: server4# zpool status -v pool: pool state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: none requested config: NAME STATE READ WRITE CKSUM pool DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 ada5 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada1 ONLINE 0 0 0 replacing DEGRADED 0 0 0 1880266799568700877 UNAVAIL 0 98 0 was /dev/da0 ada4 ONLINE 0 0 0 replacing DEGRADED 0 0 0 1406029845814225421 UNAVAIL 0 97 0 was /dev/da0 ada3 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: :<0x2013> :<0x2014> Any pointers on what I should do now? All my data seems fine :( JY From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 05:08:49 2011 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 A8E871065674 for ; Sun, 9 Jan 2011 05:08:49 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36E448FC13 for ; Sun, 9 Jan 2011 05:08:48 +0000 (UTC) Received: by fxm16 with SMTP id 16so18021207fxm.13 for ; Sat, 08 Jan 2011 21:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=MY3Q3jKIMgWsD8R85IUIOChJix66xcaKslLqtGs4GgE=; b=gV5lLbcaCSvU9ssvQIw6qRCke7EgH3SB+A1xr4lawz3L8kePkO5jayjbiv7r02SLiz BFleQN/PJ+4jxuT/jqvSR7QFeVGSpNR9jAFaedJit7UajJdpsotFlp7CkBgPQPPkuSCs wWqLo7KDW+23asBSW3YHlb/gyLOmm6dKbygC4= 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=jPuIN9wiuye34o4+lJ/kqjswZImeXmnJ113t0ghvJJpHWduKWtwk41gz5OhdOu3edp G+heJmbzSfEPegowX8YnQF3esyG5esBCklacPojEQCl19S1Ila9B3f3XTk6Da/3c25Lp XpMwWtoF06nezTe2efjmNcNn/Qe+9d58OFwUE= MIME-Version: 1.0 Received: by 10.223.97.78 with SMTP id k14mr1468977fan.89.1294549727656; Sat, 08 Jan 2011 21:08:47 -0800 (PST) Received: by 10.223.114.4 with HTTP; Sat, 8 Jan 2011 21:08:47 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Jan 2011 23:08:47 -0600 Message-ID: From: Adam Vande More To: Jean-Yves Avenard Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: faulted zpool , do not resilver 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, 09 Jan 2011 05:08:49 -0000 On Sat, Jan 8, 2011 at 10:49 PM, Jean-Yves Avenard wrote: > Any pointers on what I should do now? > > All my data seems fine :( > The web page mentioned in the error message contains further info, have you reviewed that? (argh, I see it's behind a login now, that's a recent change). This should be it's equivalent: http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html One way the meta data corruption can occur is the hard drive lies to ZFS when it issues a cache flush. If the device says it did and in reality it didn't and there was a power outage this type of corruption can occur. http://mail.opensolaris.org/pipermail/zfs-discuss/2010-January/035740.html -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 05:47:47 2011 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 457E4106566B for ; Sun, 9 Jan 2011 05:47:47 +0000 (UTC) (envelope-from jyavenard@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B55B8FC13 for ; Sun, 9 Jan 2011 05:47:46 +0000 (UTC) Received: by iyb26 with SMTP id 26so17621721iyb.13 for ; Sat, 08 Jan 2011 21:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c8ikdRnRS+875TkiX+dxGCiiTUW6XBgBMo+MsD06mnw=; b=uHlJ47slGT6i9Xt/SWCx3ajak2jyUHTYKVglvZvyYPOfSG04qOOU17pJxmyd519kcs rQ3EvgHLgZk1gWD4i/cosVOGtaU5jYSSseDyq2es60LL3pwgT6pP9jDstZ3BCganqt4X DVYLXz6MLOS20VTCm1zuo9KfCEvW2s5XVtfCI= 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=mmbt6Q2N556qWf6Q2jJcJIrZ5i7O2HDM7u/YKRgt2TRX0oG1hrb+d7rgQQiUYhyedy iVWIc4GO/tgeFfVL+nGy/c+YRLsLM+f2Ih1d1kML8lGXGCwwVb6ooZw+mKa+FWO72QWF Kv1BBNsa5cH/RjRCqzLTToA7tGIH/vbIRjAaw= MIME-Version: 1.0 Received: by 10.42.170.6 with SMTP id d6mr896761icz.464.1294552064703; Sat, 08 Jan 2011 21:47:44 -0800 (PST) Received: by 10.42.172.69 with HTTP; Sat, 8 Jan 2011 21:47:44 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Jan 2011 16:47:44 +1100 Message-ID: From: Jean-Yves Avenard To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: faulted zpool , do not resilver 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, 09 Jan 2011 05:47:47 -0000 Hi On 9 January 2011 16:08, Adam Vande More wrote: > On Sat, Jan 8, 2011 at 10:49 PM, Jean-Yves Avenard > wrote: >> >> Any pointers on what I should do now? >> >> All my data seems fine :( > > The web page mentioned in the error message contains further info, have y= ou > reviewed that? (argh, I see it's behind a login now, that's a recent > change).=A0 This should be it's equivalent: > > http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html I did.. I can't find what this metadata: bit referes to though > > One way the meta data corruption can occur is the hard drive lies to ZFS > when it issues a cache flush.=A0 If the device says it did and in reality= it > didn't and there was a power outage this type of corruption can occur. > > http://mail.opensolaris.org/pipermail/zfs-discuss/2010-January/035740.htm= l I've been trying for 3 days to resolve those issues now.. I'm going to just destroy the zpool ; I have a full mirror of that zpool on another machine. It's going to be the easiest way. I'm still worried that for the first time I tried replaced disks, it failed so miserably... For some reason moving my SATA disk from on sata interface to another failed. zpool would want to read the pool anymore, complaining that the zpool version was too high (it's version 14, definitely ok). Moving the disks bak to the original sata interface, and I can read the pool just fine. So What I did is unplug the diisk from the old interface, zpool import it (now in degraded mode) and plug back the disk and wait for the resilvering to complete. JY From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 05:50:05 2011 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 E7A661065673 for ; Sun, 9 Jan 2011 05:50:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id CA5998FC0C for ; Sun, 9 Jan 2011 05:50:05 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PboAF-0000Ix-NU; Sun, 09 Jan 2011 05:50:03 +0000 Date: Sun, 09 Jan 2011 14:50:02 +0900 Message-ID: From: Randy Bush To: Chris Forgeron In-Reply-To: References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD-STABLE Mailing List Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 05:50:06 -0000 given i have raid or raidz1, can i move to raidz2? # 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 ad4s2 ONLINE 0 0 0 ad8s2 ONLINE 0 0 0 ad6s1 ONLINE 0 0 0 ad10s1 ONLINE 0 0 0 or # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 label/disk01 ONLINE 0 0 0 label/disk00 ONLINE 0 0 0 mirror ONLINE 0 0 0 label/disk02 ONLINE 0 0 0 label/disk03 ONLINE 0 0 0 randy From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 07:11:48 2011 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 F3D73106566B for ; Sun, 9 Jan 2011 07:11:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) 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 8A1D88FC0A for ; Sun, 9 Jan 2011 07:11:47 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id tKBn1f0010vyq2s5BKBnHQ; Sun, 09 Jan 2011 07:11:47 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta05.westchester.pa.mail.comcast.net with comcast id tKBm1f0022tehsa3RKBmWL; Sun, 09 Jan 2011 07:11:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F25649B427; Sat, 8 Jan 2011 23:11:44 -0800 (PST) Date: Sat, 8 Jan 2011 23:11:44 -0800 From: Jeremy Chadwick To: Jean-Yves Avenard Message-ID: <20110109071144.GA30734@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adam Vande More , freebsd-stable@freebsd.org Subject: Re: faulted zpool , do not resilver 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, 09 Jan 2011 07:11:48 -0000 On Sun, Jan 09, 2011 at 04:47:44PM +1100, Jean-Yves Avenard wrote: > On 9 January 2011 16:08, Adam Vande More wrote: > > On Sat, Jan 8, 2011 at 10:49 PM, Jean-Yves Avenard > > wrote: > >> > >> Any pointers on what I should do now? > >> > >> All my data seems fine :( > > > > The web page mentioned in the error message contains further info, have you > > reviewed that? (argh, I see it's behind a login now, that's a recent > > change).  This should be it's equivalent: > > > > http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html > > I did.. I can't find what this metadata: bit referes to though ZFS is stating that the data which was permanently lost was metadata for ZFS itself, not an actual file on the filesystem. What the implications are of this I have no clue. pjd@ or someone similar will need to answer. -- | 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 Sun Jan 9 08:45:11 2011 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 18EDB106564A for ; Sun, 9 Jan 2011 08:45:11 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 71BBF8FC14 for ; Sun, 9 Jan 2011 08:45:10 +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 p098j6XS071233 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 9 Jan 2011 08:45:06 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk p098j6XS071233 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1294562706; bh=uOwldtWT0oUnPm45An/0WNSqLJedHriIOLNs0NYXl+8=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4D297587.4030108@infracaninophile.co.uk>|Date:=20S un,=2009=20Jan=202011=2008:44:55=20+0000|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.13)=20Gecko/20101207=20Thunderbird/3.1.7|MIME-Version:=201 .0|To:=20freebsd-stable@freebsd.org|Subject:=20Re:=20ZFS=20-=20mov ing=20from=20a=20zraid1=20to=20zraid2=20pool=20with=201.5tb=20disk s|References:=20<4D1C6F90.3080206@my.gd>=20=09<4D21E679.80002@my.gd>=20<84882169-0461-480F-8B4C-58E794 BCC8E6@my.gd>=09=20|In-Reply-To:=20|X-Enigmail-Version:=201.1.1|OpenPGP:=20id= 3D60AE908C|Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha1 =3B=0D=0A=20protocol=3D"application/pgp-signature"=3B=0D=0A=20boun dary=3D"------------enig68A790BD637AA85422AE38F6"; b=BKYCEcFDRhnrnW3+vE7J2U1Qa/X6dA3mD70KlQul5lVlh2LUxkw10d/u0FWQV3tgK FlAnwbnN9qZyq3Q9EAFZbDYW7x4e4zl5fn/W2o32OcvPyTkm/rj5Vjy8oOgDPJufOQ nWjLm58T1PDfx2DvOYcDE0NOuyDIKv4msdtLJpSU= Message-ID: <4D297587.4030108@infracaninophile.co.uk> Date: Sun, 09 Jan 2011 08:44:55 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68A790BD637AA85422AE38F6" X-Virus-Scanned: clamav-milter 0.96.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 08:45:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68A790BD637AA85422AE38F6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/01/2011 05:50, Randy Bush wrote: > given i have raid or raidz1, can i move to raidz2? >=20 > # zpool status=20 > pool: tank > state: ONLINE > scrub: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad4s2 ONLINE 0 0 0 > ad8s2 ONLINE 0 0 0 > ad6s1 ONLINE 0 0 0 > ad10s1 ONLINE 0 0 0 >=20 > or >=20 > # zpool status > pool: tank > state: ONLINE > scrub: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/disk01 ONLINE 0 0 0 > label/disk00 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/disk02 ONLINE 0 0 0 > label/disk03 ONLINE 0 0 0 Not without backing up your current data, destroying the existing zpool(s) and rebuilding from scratch. Note: raidz2 on 4 disks doesn't really win you anything over 2 x mirror pairs of disks, and the RAID10 mirror is going to be rather more performa= nt. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig68A790BD637AA85422AE38F6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0pdZAACgkQ8Mjk52CukIzh8gCgk+XaIXtE2JTDWS9XDCzvrJqG D58An0tz2ykIRceo4FdgvnLXlVzX7l+p =E6rE -----END PGP SIGNATURE----- --------------enig68A790BD637AA85422AE38F6-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 08:47:44 2011 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 DD302106566B for ; Sun, 9 Jan 2011 08:47:44 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from alpha.tao.org.uk (alpha.tao.org.uk [212.42.1.232]) by mx1.freebsd.org (Postfix) with ESMTP id 9E48B8FC0C for ; Sun, 9 Jan 2011 08:47:44 +0000 (UTC) Received: from [90.155.77.83] (p4.dhcp.tao.org.uk [90.155.77.83]) (Authenticated sender: joemail@alpha.tao.org.uk) by alpha.tao.org.uk (Postfix) with ESMTPA id 0C6131076DE6; Sun, 9 Jan 2011 08:47:43 +0000 (GMT) References: <488AE93A-97B9-4F01-AD0A-0098E4B329C3@my.gd> <4D25BF91.7070304@my.gd> <4D25C760.4070703@digsys.bg> <20110107111635.GL28453@over-yonder.net> <2E0FDC35-B6E3-49C7-A55B-B1B08FFBF1DB@tao.org.uk> <20110108095005.GA4044@icarus.home.lan> In-Reply-To: <20110108095005.GA4044@icarus.home.lan> Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <96D05C71-2B1F-4813-B8FD-1DA39E384FC6@tao.org.uk> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C148) From: Josef Karthauser Date: Sun, 9 Jan 2011 08:48:20 +0000 To: Jeremy Chadwick Cc: "freebsd-stable@freebsd.org" , Artem Belevich , "Matthew D. Fuller" , Daniel Kalchev Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 08:47:44 -0000 Brill! Thanks :) Joe On 8 Jan 2011, at 09:50, Jeremy Chadwick wrote: > On Sat, Jan 08, 2011 at 09:14:19AM +0000, Josef Karthauser wrote: >> On 7 Jan 2011, at 17:30, Artem Belevich wrote: >>> One way to get specific ratio for *your* pool would be to collect >>> record size statistics from your pool using "zdb -L -b " and >>> then calculate L2ARC:ARC ratio based on average record size. I'm not >>> sure, though whether L2ARC stores records in compressed or >>> uncompressed form. >>=20 >> Can someone point me to a reference describing the various zfs caches ava= ilable? What's the arc and zil? Ive been running some zfs for a few years no= w, and must have missed thus entire subject :/. >=20 > ARC: http://en.wikipedia.org/wiki/ZFS#Cache_management > L2ARC: http://en.wikipedia.org/wiki/ZFS#Storage_pools > L2ARC: http://blogs.sun.com/brendan/entry/test > Both: http://www.c0t0d0s0.org/archives/5329-Some-insight-into-the-read-ca= che-of-ZFS-or-The-ARC.html > Both: http://nilesh-joshi.blogspot.com/2010/07/zfs-revisited.html > ZIL: http://blogs.sun.com/perrin/entry/the_lumberjack > ZIL: http://blogs.sun.com/realneel/entry/the_zfs_intent_log >=20 > Enjoy. >=20 > --=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 | >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 09:00:55 2011 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 0952C106564A; Sun, 9 Jan 2011 09:00:55 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 01C728FC13; Sun, 9 Jan 2011 09:00:53 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 737A2704FAF; Sun, 9 Jan 2011 10:00:52 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 10.4131] X-CRM114-CacheID: sfid-20110109_10005_8B1EC28F X-CRM114-Status: Good ( pR: 10.4131 ) X-Spambayes-Classification: ham; 0.00 Message-ID: <4D297943.1040507@fsn.hu> Date: Sun, 09 Jan 2011 10:00:51 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Martin Matuska References: <4D0A09AF.3040005@FreeBSD.org> In-Reply-To: <4D0A09AF.3040005@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: New ZFSv28 patchset for 8-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: Sun, 09 Jan 2011 09:00:55 -0000 On 12/16/2010 01:44 PM, Martin Matuska wrote: > Hi everyone, > > following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am > providing a ZFSv28 testing patch for 8-STABLE. > > Link to the patch: > > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz > I've got an IO hang with dedup enabled (not sure it's related, I've started to rewrite all data on pool, which makes a heavy load): The processes are in various states: 65747 1001 1 54 10 28620K 24360K tx->tx 0 6:58 0.00% cvsup 80383 1001 1 54 10 40616K 30196K select 1 5:38 0.00% rsync 1501 www 1 44 0 7304K 2504K zio->i 0 2:09 0.00% nginx 1479 www 1 44 0 7304K 2416K zio->i 1 2:03 0.00% nginx 1477 www 1 44 0 7304K 2664K zio->i 0 2:02 0.00% nginx 1487 www 1 44 0 7304K 2376K zio->i 0 1:40 0.00% nginx 1490 www 1 44 0 7304K 1852K zfs 0 1:30 0.00% nginx 1486 www 1 44 0 7304K 2400K zfsvfs 1 1:05 0.00% nginx And everything which wants to touch the pool is/becomes dead. Procstat says about one process: # procstat -k 1497 PID TID COMM TDNAME KSTACK 1497 100257 nginx - mi_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV null_lock VOP_LOCK1_APV _vn_lock nullfs_root lookup namei vn_open_cred kern_openat syscallenter syscall Xfast_syscall From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 09:02:00 2011 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 91B291065675 for ; Sun, 9 Jan 2011 09:02:00 +0000 (UTC) (envelope-from jyavenard@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56A748FC17 for ; Sun, 9 Jan 2011 09:02:00 +0000 (UTC) Received: by iyb26 with SMTP id 26so17683611iyb.13 for ; Sun, 09 Jan 2011 01:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5gbmHvQ7FuTiObRNB+inCklOkcp46d4waO8G+7sO7tU=; b=lLBz87QLtmL8vs7RcOV5oeeMCLqyeo2ZSvbvF3HV8VaG08mM+K/Y7KRrUbpCg8HzR3 o2jXroiczPWJ1p6YnMPv855TvNhXKTD8jwDpTT9RBXRFznHYQ0Opj0Y0u9Z9/rv4qcAj e2atyYt1sVIw42YjYk/LZ9dFDBknVKm9cWS7g= 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=BQmKdGf50LBhhtRDNKS7jW9yQv5mKamgDN+SS1GQnqQyYbeo8HHs7h3ung+wNrYjNY bRXzwMhDrq9QerX495ee4OcDx5nAeXdtHIAQnAYikEgoSiJyjA74IsxFF7HsfYfieXYa OLE0XwHkqNp4JkTnONHRl1UJN+08gU9n+VNfQ= MIME-Version: 1.0 Received: by 10.42.173.202 with SMTP id s10mr2853133icz.397.1294563719732; Sun, 09 Jan 2011 01:01:59 -0800 (PST) Received: by 10.42.172.69 with HTTP; Sun, 9 Jan 2011 01:01:59 -0800 (PST) In-Reply-To: <4D297587.4030108@infracaninophile.co.uk> References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> <4D297587.4030108@infracaninophile.co.uk> Date: Sun, 9 Jan 2011 20:01:59 +1100 Message-ID: From: Jean-Yves Avenard To: Matthew Seaman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 09:02:00 -0000 Hi On 9 January 2011 19:44, Matthew Seaman wrote: > Not without backing up your current data, destroying the existing > zpool(s) and rebuilding from scratch. > > Note: raidz2 on 4 disks doesn't really win you anything over 2 x mirror > pairs of disks, and the RAID10 mirror is going to be rather more performant. I would have thought that the probability of failure to be slightly different. Sure you out of 4 disks, 2 can fail in both conditions. *But*, in raidz2, any two of the four can fail. In RAID10, the two disks that failed must be in different block otherwise you loose it all As such the resilience for failure in a RAIDz2 is far greater than in a RAID10 system From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 10:03:24 2011 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 F20761065673 for ; Sun, 9 Jan 2011 10:03:24 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 5B08F8FC14 for ; Sun, 9 Jan 2011 10:03:24 +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 p09A3KTu063195 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 9 Jan 2011 10:03:20 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk p09A3KTu063195 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1294567400; bh=IxNLegnuaecjGX/o+SF352qkaTzQtAdNFlmztX6Jg8U=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4D2987E0.7060701@infracaninophile.co.uk>|Date:=20S un,=2009=20Jan=202011=2010:03:12=20+0000|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.13)=20Gecko/20101207=20Thunderbird/3.1.7|MIME-Version:=201 .0|To:=20Jean-Yves=20Avenard=20|CC:=20freebsd -stable@freebsd.org|Subject:=20Re:=20ZFS=20-=20moving=20from=20a=2 0zraid1=20to=20zraid2=20pool=20with=201.5tb=20disks|References:=20 <4D1C6F90.3080206@my.gd>=09=09<4D21E 679.80002@my.gd>=09<84882169-0461-480F-8B4C-58E794BCC8E6@my.gd>=09 =09< m262ty39th.wl%randy@psg.com>=09<4D297587.4030108@infracaninophile. co.uk>=20|In-Reply-To:=20|X-Enigmail-Version:=201.1.1|OpenPGP:=20id=3D 60AE908C|Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha1=3 B=0D=0A=20protocol=3D"application/pgp-signature"=3B=0D=0A=20bounda ry=3D"------------enig93899D7A3FE0208FE55B5417"; b=nEhOG1kyZwFMwB4oUT3CXD6U2vBfoMxbhDI6PO1DYD/lILJJ4naBB2CwQCfhowmtP m/3f2tUpuY8xXuJY8xGt4NiPT7iLVlj8HHnW/Pcqm8pFyTAT2TvUzTt6LVfqk6LaDL b/QRuurIM/Yujqa6j3x+/vaJ5Hpe1H69b4RU4bY4= Message-ID: <4D2987E0.7060701@infracaninophile.co.uk> Date: Sun, 09 Jan 2011 10:03:12 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jean-Yves Avenard References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> <4D297587.4030108@infracaninophile.co.uk> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig93899D7A3FE0208FE55B5417" X-Virus-Scanned: clamav-milter 0.96.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 10:03:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93899D7A3FE0208FE55B5417 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/01/2011 09:01, Jean-Yves Avenard wrote: > Hi >=20 > On 9 January 2011 19:44, Matthew Seaman wrote: >> Not without backing up your current data, destroying the existing >> zpool(s) and rebuilding from scratch. >> >> Note: raidz2 on 4 disks doesn't really win you anything over 2 x mirro= r >> pairs of disks, and the RAID10 mirror is going to be rather more perfo= rmant. >=20 > I would have thought that the probability of failure to be slightly dif= ferent. > Sure you out of 4 disks, 2 can fail in both conditions. >=20 > *But*, in raidz2, any two of the four can fail. > In RAID10, the two disks that failed must be in different block > otherwise you loose it all >=20 > As such the resilience for failure in a RAIDz2 is far greater than in > a RAID10 system So you sacrifice performance 100% of the time based on the very unlikely possibility of drives 1+2 or 3+4 failing simultaneously, compared to the similarly unlikely possibility of drives 1+3 or 1+4 or 2+3 or 2+4 failing simultaneously?[*] That's not a trade-off worth making IMHO. If the data is that valuable, you should be making copies of it to some independent machine all the time and backing up at frequent intervals, which backups you keep off-site in disaster-proof storage. Cheers, Matthew [*] All of this mathematics is pretty suspect, because if two drives fail simultaneously in a machine, the chances are the failures are not independent, but due to some external cause [eg. like the case fan breaking and the box toasting itself.] In which case, the comparative chance of whatever it is affecting three or four drives at once renders the whole argument pointless. --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig93899D7A3FE0208FE55B5417 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0ph+gACgkQ8Mjk52CukIztDwCggYueiiDzDAcshWHqpJFsUVWe rCMAoJTbRhaTvEL+IqGOdMcgvGhekLHI =yXbi -----END PGP SIGNATURE----- --------------enig93899D7A3FE0208FE55B5417-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 10:24:37 2011 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 0B9FC106566B for ; Sun, 9 Jan 2011 10:24:37 +0000 (UTC) (envelope-from jyavenard@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C23488FC16 for ; Sun, 9 Jan 2011 10:24:36 +0000 (UTC) Received: by iyb26 with SMTP id 26so17712330iyb.13 for ; Sun, 09 Jan 2011 02:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3Co05Z50R707wHH0cyy8E+Gs0HyITBFX2E0wrF/b3tg=; b=LQWs5lENcyqWRJwrCxkg9TePKU6EFG8CkwXr0q7Pzpmfz0+dkt4CFE5Epr+MN4yRLl BiAb4mj3z75nBKH0WX7b2ZpZv30jkET5hRHRra71Gv6wJ9sRCmolnfKOE9s+NjqsaZX8 5NyR+v0NwGTG2zLd9j4Nfmmlf6qiErE9x+U7g= 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=Xa4F6zvfo4mljlVSt9sjTGnQuUTWfa0W6Gx5hf5pg5vQVaa2xqD4glqjYOgFmT8H3B 6lcVN0hYwsAyRUtwrTEJlrB3G1qXgZUe9TyIuM712TOqSwcFDA4VqfYYuRt2TcIqLQ+K X6Cbv3ZvOzxwq16GtR7KYh7yUGomPNSpqI4vg= MIME-Version: 1.0 Received: by 10.42.177.196 with SMTP id bj4mr2943254icb.129.1294568676107; Sun, 09 Jan 2011 02:24:36 -0800 (PST) Received: by 10.42.172.69 with HTTP; Sun, 9 Jan 2011 02:24:36 -0800 (PST) In-Reply-To: <4D2987E0.7060701@infracaninophile.co.uk> References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> <4D297587.4030108@infracaninophile.co.uk> <4D2987E0.7060701@infracaninophile.co.uk> Date: Sun, 9 Jan 2011 21:24:36 +1100 Message-ID: From: Jean-Yves Avenard To: Matthew Seaman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 10:24:37 -0000 On 9 January 2011 21:03, Matthew Seaman w= rote: > > So you sacrifice performance 100% of the time based on the very unlikely > possibility of drives 1+2 or 3+4 failing simultaneously, compared to the > similarly unlikely possibility of drives 1+3 or 1+4 or 2+3 or 2+4 But this is not what you first wrote You said the effect were identical. they are not. Now if you want to favour performance over redundancy that's ultimately up to the user... Plus, honestly, the difference in performance between raidz and raid10 is also close to bein insignificant. > failing simultaneously?[*] =A0That's not a trade-off worth making IMHO. > If the data is that valuable, you should be making copies of it to some > independent machine all the time and backing up at frequent intervals, > which backups you keep off-site in disaster-proof storage. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 10:32:34 2011 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 DCD63106564A for ; Sun, 9 Jan 2011 10:32:34 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 671388FC08 for ; Sun, 9 Jan 2011 10:32:33 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate2.intern.punkt.de with ESMTP id p09ADJBp028908; Sun, 9 Jan 2011 11:13:19 +0100 (CET) Received: from [217.29.46.4] ([217.29.46.4]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id p09ADJPs044795; Sun, 9 Jan 2011 11:13:19 +0100 (CET) (envelope-from hausen@punkt.de) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: "Patrick M. Hausen" In-Reply-To: <4D2987E0.7060701@infracaninophile.co.uk> Date: Sun, 9 Jan 2011 11:14:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F1A810A-E5B9-420E-89C1-4316A04B9A75@punkt.de> References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> <4D297587.4030108@infracaninophile.co.uk> <4D2987E0.7060701@infracaninophile.co.uk> To: Matthew Seaman X-Mailer: Apple Mail (2.1082) Cc: freebsd-stable@freebsd.org, Jean-Yves Avenard Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 10:32:34 -0000 Hi, all, Am 09.01.2011 um 11:03 schrieb Matthew Seaman: > [*] All of this mathematics is pretty suspect, because if two drives > fail simultaneously in a machine, the chances are the failures are not > independent, but due to some external cause [eg. like the case fan > breaking and the box toasting itself.] In which case, the comparative > chance of whatever it is affecting three or four drives at once = renders > the whole argument pointless. I assume you are familiar with these papers? http://queue.acm.org/detail.cfm?id=3D1317403 http://queue.acm.org/detail.cfm?id=3D1670144 Short version: as hard disk sizes increase to 2 TB and beyond while the = URE rate stays in the order of 1 to 10^14 blocks read, the probability of = encountering an URE during rebuild of a single parity RAID approaches 1. Best regards, Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 10:50:11 2011 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 5C489106564A for ; Sun, 9 Jan 2011 10:50:11 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id B2E148FC12 for ; Sun, 9 Jan 2011 10:50:10 +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 p09Ao64M063668 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 9 Jan 2011 10:50:07 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk p09Ao64M063668 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1294570207; bh=hk2qncK17lapUYR/03JgQtpYkeDg7tgwHQ/OylOCNBA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4D2992D7.9090009@infracaninophile.co.uk>|Date:=20S un,=2009=20Jan=202011=2010:49:59=20+0000|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.13)=20Gecko/20101207=20Thunderbird/3.1.7|MIME-Version:=201 .0|To:=20Jean-Yves=20Avenard=20|CC:=20freebsd -stable@freebsd.org|Subject:=20Re:=20ZFS=20-=20moving=20from=20a=2 0zraid1=20to=20zraid2=20pool=20with=201.5tb=20disks|References:=20 <4D1C6F90.3080206@my.gd>=09=09<4D21E 679.80002@my.gd>=09<84882169-0461-480F-8B4C-58E794BCC8E6@my.gd>=09 =09< m262ty39th.wl%randy@psg.com>=09<4D297587.4030108@infracaninophile. co.uk>=09=09<4D2987E0.7060701@infracaninophile.co.uk>=20|In-Reply-To:=20 |X-E nigmail-Version:=201.1.1|OpenPGP:=20id=3D60AE908C|Content-Type:=20 multipart/signed=3B=20micalg=3Dpgp-sha1=3B=0D=0A=20protocol=3D"app lication/pgp-signature"=3B=0D=0A=20boundary=3D"------------enig378 6E061DB8ED58AB8E80202"; b=Ju+o/3Qm8lERI7yjEY4sxdMON2SrNCfZubzGEHFKJWVxCRXsOTpC/1WiVdjMVtcn9 Ms9O2FDzP3OXypeaZqiGqUmhHUm1haLIEmnr9ELLJQmDzSSXlz9tV/O7c1pd88O9nz O+/y48XsT9PEGl8wRXida6skoI04TgBAZAiJYAPE= Message-ID: <4D2992D7.9090009@infracaninophile.co.uk> Date: Sun, 09 Jan 2011 10:49:59 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jean-Yves Avenard References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> <4D297587.4030108@infracaninophile.co.uk> <4D2987E0.7060701@infracaninophile.co.uk> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3786E061DB8ED58AB8E80202" X-Virus-Scanned: clamav-milter 0.96.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 10:50:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3786E061DB8ED58AB8E80202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/01/2011 10:24, Jean-Yves Avenard wrote: > On 9 January 2011 21:03, Matthew Seaman wrote: >=20 >> >> So you sacrifice performance 100% of the time based on the very unlike= ly >> possibility of drives 1+2 or 3+4 failing simultaneously, compared to t= he >> similarly unlikely possibility of drives 1+3 or 1+4 or 2+3 or 2+4 >=20 > But this is not what you first wrote What I said was: > >> Note: raidz2 on 4 disks doesn't really win you anything over 2 x mir= ror > >> pairs of disks, and the RAID10 mirror is going to be rather more performant. > You said the effect were identical. they are not. Which is certainly not saying the effects are identical. It's saying the difference is too small to worry about. > Plus, honestly, the difference in performance between raidz and raid10 > is also close to bein insignificant. That's not my experience. It depends on what sort of workload you have. If you're streaming very large files, I'd expect RAID10 and RAIDz to be about equal. If you're doing lots of randomly distributed small IOs, then RAID10 is going to win hands down. Cheers Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig3786E061DB8ED58AB8E80202 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0pkt4ACgkQ8Mjk52CukIyDZQCgjBDL3ih7jz1BaXw35vdNBsrM wbcAn3u2gPHMH2bnHp+0JBod02aTKrq2 =+29H -----END PGP SIGNATURE----- --------------enig3786E061DB8ED58AB8E80202-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 11:49:30 2011 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 852B31065696; Sun, 9 Jan 2011 11:49:30 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 7A58D8FC1B; Sun, 9 Jan 2011 11:49:28 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id E95DA70458C; Sun, 9 Jan 2011 12:49:27 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 13.6024] X-CRM114-CacheID: sfid-20110109_12492_927F0F69 X-CRM114-Status: Good ( pR: 13.6024 ) X-Spambayes-Classification: ham; 0.00 Message-ID: <4D29A0C7.8050002@fsn.hu> Date: Sun, 09 Jan 2011 12:49:27 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Martin Matuska References: <4D0A09AF.3040005@FreeBSD.org> <4D297943.1040507@fsn.hu> In-Reply-To: <4D297943.1040507@fsn.hu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: New ZFSv28 patchset for 8-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: Sun, 09 Jan 2011 11:49:30 -0000 On 01/09/2011 10:00 AM, Attila Nagy wrote: > On 12/16/2010 01:44 PM, Martin Matuska wrote: >> Hi everyone, >> >> following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am >> providing a ZFSv28 testing patch for 8-STABLE. >> >> Link to the patch: >> >> http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz >> >> > I've got an IO hang with dedup enabled (not sure it's related, I've > started to rewrite all data on pool, which makes a heavy load): > > The processes are in various states: > 65747 1001 1 54 10 28620K 24360K tx->tx 0 6:58 0.00% cvsup > 80383 1001 1 54 10 40616K 30196K select 1 5:38 0.00% rsync > 1501 www 1 44 0 7304K 2504K zio->i 0 2:09 0.00% nginx > 1479 www 1 44 0 7304K 2416K zio->i 1 2:03 0.00% nginx > 1477 www 1 44 0 7304K 2664K zio->i 0 2:02 0.00% nginx > 1487 www 1 44 0 7304K 2376K zio->i 0 1:40 0.00% nginx > 1490 www 1 44 0 7304K 1852K zfs 0 1:30 0.00% nginx > 1486 www 1 44 0 7304K 2400K zfsvfs 1 1:05 0.00% nginx > > And everything which wants to touch the pool is/becomes dead. > > Procstat says about one process: > # procstat -k 1497 > PID TID COMM TDNAME KSTACK > 1497 100257 nginx - mi_switch sleepq_wait > __lockmgr_args vop_stdlock VOP_LOCK1_APV null_lock VOP_LOCK1_APV > _vn_lock nullfs_root lookup namei vn_open_cred kern_openat > syscallenter syscall Xfast_syscall No, it's not related. One of the disks in the RAIDZ2 pool went bad: (da4:arcmsr0:0:4:0): READ(6). CDB: 8 0 2 10 10 0 (da4:arcmsr0:0:4:0): CAM status: SCSI Status Error (da4:arcmsr0:0:4:0): SCSI status: Check Condition (da4:arcmsr0:0:4:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error) and it seems it froze the whole zpool. Removing the disk by hand solved the problem. I've seen this previously on other machines with ciss. I wonder why ZFS didn't throw it out of the pool. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 11:52:59 2011 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 6BA7B106566B; Sun, 9 Jan 2011 11:52:59 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2E38FC22; Sun, 9 Jan 2011 11:52:57 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id D0E1C7045D3; Sun, 9 Jan 2011 12:52:56 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 15.4350] X-CRM114-CacheID: sfid-20110109_12525_6A621F56 X-CRM114-Status: Good ( pR: 15.4350 ) X-Spambayes-Classification: ham; 0.00 Message-ID: <4D29A198.4070107@fsn.hu> Date: Sun, 09 Jan 2011 12:52:56 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Artem Belevich References: <4D0A09AF.3040005@FreeBSD.org> <4D1F7008.3050506@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Martin Matuska Subject: Re: New ZFSv28 patchset for 8-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: Sun, 09 Jan 2011 11:52:59 -0000 On 01/01/2011 08:09 PM, Artem Belevich wrote: > On Sat, Jan 1, 2011 at 10:18 AM, Attila Nagy wrote: >> What I see: >> - increased CPU load >> - decreased L2 ARC hit rate, decreased SSD (ad[46]), therefore increased >> hard disk load (IOPS graph) >> > ... >> Any ideas on what could cause these? I haven't upgraded the pool version and >> nothing was changed in the pool or in the file system. > The fact that L2 ARC is full does not mean that it contains the right > data. Initial L2ARC warm up happens at a much higher rate than the > rate L2ARC is updated after it's been filled initially. Even > accelerated warm-up took almost a day in your case. In order for L2ARC > to warm up properly you may have to wait quite a bit longer. My guess > is that it should slowly improve over the next few days as data goes > through L2ARC and those bits that are hit more often take residence > there. The larger your data set, the longer it will take for L2ARC to > catch the right data. > > Do you have similar graphs from pre-patch system just after reboot? I > suspect that it may show similarly abysmal L2ARC hit rates initially, > too. > > I've finally found the time to read the v28 patch and figured out the problem: vfs.zfs.l2arc_noprefetch was changed to 1, so it doesn't use the prefetched data on the L2ARC devices. This is a major hit in my case. Enabling this again restored the previous hit rates and lowered the load on the hard disks significantly. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 11:59:35 2011 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 AA739106566C for ; Sun, 9 Jan 2011 11:59:35 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D86E8FC16 for ; Sun, 9 Jan 2011 11:59:34 +0000 (UTC) Received: by qyk36 with SMTP id 36so18092428qyk.13 for ; Sun, 09 Jan 2011 03:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=q80V14eOQTXYcPHS6Z2WAOvUXtQDH2LcV/T4BWClXfo=; b=hq9yE6dIJ+BZq0ZuKdeBeR0GDk+LcYqEtxZjwmqqmujE5K847kmuAmIyGGHQNTmTV6 sq+sOzcP8SosxwQ9+fSbt/XWGOX4O8UXI6877eSVKRNPMSrLs2dVa4s4YZRb4mwCnygE PJJYIJsZ3q6bhJz6+1jOs+03VFvWjPvb2ICSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Ekw/20KUz+uP8XOZJlLwyylbUwnTQfbaH+hIkQ0cVAEvg8y3wqNCVfJyPyL1BB0j7Y 7NYKRjyM5xUwGX1Cvwrhnh+MY0QDKiGLcExxdG9rJ2v/hQJoajshpujGO2K7atqsg6u3 sn8RRk6fLkgc8DUyLlZi6EMQBTq91bvodmtwI= MIME-Version: 1.0 Received: by 10.229.250.135 with SMTP id mo7mr24063236qcb.30.1294572790350; Sun, 09 Jan 2011 03:33:10 -0800 (PST) Sender: tvijlbrief@gmail.com Received: by 10.229.50.209 with HTTP; Sun, 9 Jan 2011 03:33:10 -0800 (PST) Date: Sun, 9 Jan 2011 12:33:10 +0100 X-Google-Sender-Auth: fuy6yz1M1vBLz4mc7fbrJ5pCcRc Message-ID: From: Tom Vijlbrief To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=00163630f77d4e05a00499683739 Subject: Panic 8.2 PRERELEASE WRITE_DMA48 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, 09 Jan 2011 11:59:35 -0000 --00163630f77d4e05a00499683739 Content-Type: text/plain; charset=ISO-8859-1 The last half year I've been installing FreeBSD on several machines. I installed it on my main desktop system a few weeks ago which normally runs Linux, but I get this panic under heavy disk I/O. It even happened during the initial sysinstall, allthough I also have completed several buildworlds without problems. I can trigger it easily by accessing /usr (UFS) and a linux ext partition simultaneously, eg by copying large files to the /usr partition. Just bought a serial cable to enable the serial console of the various FreeBSD installations, which is of good use for this problem, because a crash dump is not written. Full boot output in the attachment Sun Jan 9 10:11:17 CET 2011 unknown: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=274799820^M ata2: timeout waiting to issue command^M ata2: error issuing WRITE_DMA48 command^M g_vfs_done():ad4s2f[WRITE(offset=28915105792, length=131072)]error = 6^M /usr: got error 6 while accessing filesystem^M panic: softdep_deallocate_dependencies: unrecovered I/O error^M cpuid = 0^M KDB: stack backtrace:^M #0 0xc08e0f77 at kdb_backtrace+0x47^M #1 0xc08b2037 at panic+0x117^M #2 0xc0ae2ecd at softdep_deallocate_dependencies+0x3d^M #3 0xc0925590 at brelse+0x90^M #4 0xc092829a at bufdone_finish+0x3fa^M #5 0xc092830d at bufdone+0x4d^M #6 0xc092bdf9 at cluster_callback+0x89^M #7 0xc09282f7 at bufdone+0x37^M #8 0xc0850ad5 at g_vfs_done+0x85^M #9 0xc09224d9 at biodone+0xb9^M #10 0xc084da69 at g_io_schedule_up+0x79^M #11 0xc084e0a8 at g_up_procbody+0x68^M #12 0xc0886fc1 at fork_exit+0x91^M #13 0xc0bcc144 at fork_trampoline+0x8^M Uptime: 2h56m27s^M Physical memory: 1515 MB^M Dumping 177 MB:ata2: timeout waiting to issue command^M ata2: error issuing WRITE_DMA command^M ^M ** DUMP FAILED (ERROR 5) **^M Automatic reboot in 15 seconds - press a key on the console to abort^M Rebooting...^M --00163630f77d4e05a00499683739 Content-Type: application/octet-stream; name=crash_script Content-Disposition: attachment; filename=crash_script Content-Transfer-Encoding: base64 X-Attachment-Id: f_gipv4vlv0 Q29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAx OTkyLCAxOTkzLCAxOTk0DQ0KCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlm b3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQ0KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJh ZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uDQ0KRnJlZUJTRCA4LjItUFJFUkVMRUFT RSAjMDogVGh1IERlYyAzMCAxMjoyMTowNiBDRVQgMjAxMA0NCiAgICByb290QHN3YW5ic2Qudjdm LmV1Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgaTM4Ng0NClRpbWVjb3VudGVyICJpODI1 NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwDQ0KQ1BVOiBJbnRlbChSKSBQZW50aXVt KFIpIDQgQ1BVIDIuNTNHSHogKDI1NTguNTQtTUh6IDY4Ni1jbGFzcyBDUFUpDQ0KICBPcmlnaW4g PSAiR2VudWluZUludGVsIiAgSWQgPSAweGYyNCAgRmFtaWx5ID0gZiAgTW9kZWwgPSAyICBTdGVw cGluZyA9IDQNDQogIEZlYXR1cmVzPTB4M2ZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQ QUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxE VFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0+DQ0KcmVhbCBtZW1vcnkgID0gMTYx MDYxMjczNiAoMTUzNiBNQikNDQphdmFpbCBtZW1vcnkgPSAxNTU1MzE2NzM2ICgxNDgzIE1CKQ0N CkFDUEkgQVBJQyBUYWJsZTogPEFTVVMgICBQNEI1MzMgID4NDQppb2FwaWMwIDxWZXJzaW9uIDIu MD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkDQ0Ka2JkMSBhdCBrYmRtdXgwDQ0KYWNwaTA6IDxB U1VTIFA0QjUzMz4gb24gbW90aGVyYm9hcmQNDQphY3BpMDogW0lUSFJFQURdDQ0KYWNwaTA6IFBv d2VyIEJ1dHRvbiAoZml4ZWQpDQ0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBm YWlsZWQNDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCA1ZmYwMDAwMCAoMykgZmFpbGVk DQ0KVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAx MDAwDQ0KYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHhl NDA4LTB4ZTQwYiBvbiBhY3BpMA0NCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTANDQphY3BpX2J1 dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwDQ0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0NCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIwDQ0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBj aTANDQpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQ0NCnZnYXBjaTA6IDxWR0EtY29tcGF0 aWJsZSBkaXNwbGF5PiBtZW0gMHhmMjAwMDAwMC0weGYyZmZmZmZmLDB4ZjQwMDAwMDAtMHhmN2Zm ZmZmZiwweGYzODAwMDAwLTB4ZjM4N2ZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMQ0N Cm52aWRpYTA6IDxHZUZvcmNlNCBUaSA0MjAwPiBvbiB2Z2FwY2kwDQ0KdmdhcGNpMDogY2hpbGQg bnZpZGlhMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9idXNtYXN0ZXINDQp2Z2FwY2kwOiBjaGlsZCBu dmlkaWEwIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvDQ0KbnZpZGlhMDogW0dJQU5ULUxPQ0tFRF0N DQpudmlkaWEwOiBbSVRIUkVBRF0NDQp1aGNpMDogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBj b250cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZDgwMC0weGQ4MWYgaXJxIDE2IGF0IGRldmljZSAyOS4w IG9uIHBjaTANDQp1aGNpMDogW0lUSFJFQURdDQ0KdWhjaTA6IExlZ1N1cCA9IDB4MmYwMA0NCnVz YnVzMDogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBvbiB1aGNp MA0NCnVoY2kxOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBv cnQgMHhkNDAwLTB4ZDQxZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjEgb24gcGNpMA0NCnVoY2kxOiBb SVRIUkVBRF0NDQp1aGNpMTogTGVnU3VwID0gMHgyZjAwDQ0KdXNidXMxOiA8SW50ZWwgODI4MDFE QiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IG9uIHVoY2kxDQ0KdWhjaTI6IDxJbnRlbCA4 MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQz4gcG9ydCAweGQwMDAtMHhkMDFmIGly cSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwDQ0KdWhjaTI6IFtJVEhSRUFEXQ0NCnVoY2kyOiBM ZWdTdXAgPSAweDJmMDANDQp1c2J1czI6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJv bGxlciBVU0ItQz4gb24gdWhjaTINDQplaGNpMDogPEludGVsIDgyODAxREIvTC9NIChJQ0g0KSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGYxODAwMDAwLTB4ZjE4MDAzZmYgaXJxIDIzIGF0IGRl dmljZSAyOS43IG9uIHBjaTANDQplaGNpMDogW0lUSFJFQURdDQ0KdXNidXMzOiBFSENJIHZlcnNp b24gMS4wDQ0KdXNidXMzOiA8SW50ZWwgODI4MDFEQi9ML00gKElDSDQpIFVTQiAyLjAgY29udHJv bGxlcj4gb24gZWhjaTANDQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAz MC4wIG9uIHBjaTANDQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMg0NCnJsMDogPFJlYWxU ZWsgODEzOSAxMC8xMDBCYXNlVFg+IHBvcnQgMHhiODAwLTB4YjhmZiBtZW0gMHhmMTAwMDAwMC0w eGYxMDAwMGZmIGlycSAyMiBhdCBkZXZpY2UgMTAuMCBvbiBwY2kyDQ0KbWlpYnVzMDogPE1JSSBi dXM+IG9uIHJsMA0NCnJscGh5MDogPFJlYWxUZWsgaW50ZXJuYWwgbWVkaWEgaW50ZXJmYWNlPiBQ SFkgMCBvbiBtaWlidXMwDQ0KcmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VU WCwgMTAwYmFzZVRYLUZEWCwgYXV0bw0NCnJsMDogRXRoZXJuZXQgYWRkcmVzczogMDA6NTA6YmY6 ZTE6M2I6MzUNDQpybDA6IFtJVEhSRUFEXQ0NCmF0YXBjaTA6IDxTaUkgMzUxMiBTQVRBMTUwIGNv bnRyb2xsZXI+IHBvcnQgMHhiNDAwLTB4YjQwNywweGIwMDAtMHhiMDAzLDB4YTgwMC0weGE4MDcs MHhhNDAwLTB4YTQwMywweGEwMDAtMHhhMDBmIG1lbSAweGYwODAwMDAwLTB4ZjA4MDAxZmYgaXJx IDIzIGF0IGRldmljZSAxMS4wIG9uIHBjaTINDQphdGFwY2kwOiBbSVRIUkVBRF0NDQphdGEyOiA8 QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMA0NCmF0YTI6IFtJVEhSRUFEXQ0NCmF0YTM6IDxBVEEg Y2hhbm5lbCAxPiBvbiBhdGFwY2kwDQ0KYXRhMzogW0lUSFJFQURdDQ0KcGNtMDogPENyZWF0aXZl IEVNVTEwSzE+IHBvcnQgMHg5ODAwLTB4OTgxZiBpcnEgMjAgYXQgZGV2aWNlIDEyLjAgb24gcGNp Mg0NCnBjbTA6IDxTaWdtYVRlbCBTVEFDOTcwOC8xMSBBQzk3IENvZGVjPg0NCnBjbTA6IFtJVEhS RUFEXQ0NCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTANDQpp c2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANDQphdGFwY2kxOiA8SW50ZWwgSUNINCBVRE1BMTAwIGNv bnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmMDAw LTB4ZjAwZiBpcnEgMTggYXQgZGV2aWNlIDMxLjEgb24gcGNpMA0NCmF0YTA6IDxBVEEgY2hhbm5l bCAwPiBvbiBhdGFwY2kxDQ0KYXRhMDogW0lUSFJFQURdDQ0KYXRhMTogPEFUQSBjaGFubmVsIDE+ IG9uIGF0YXBjaTENDQphdGExOiBbSVRIUkVBRF0NDQphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9j az4gcG9ydCAweDcwLTB4NzMgaXJxIDggb24gYWNwaTANDQpmZGMwOiA8ZmxvcHB5IGRyaXZlIGNv bnRyb2xsZXI+IHBvcnQgMHgzZjItMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTANDQpm ZGMwOiBbRklMVEVSXQ0NCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAw DQ0KcHBjMDogPFBhcmFsbGVsIHBvcnQ+IHBvcnQgMHgzNzgtMHgzN2YsMHg3NzgtMHg3N2IgaXJx IDcgZHJxIDMgb24gYWNwaTANDQpwcGMwOiBTTUMtbGlrZSBjaGlwc2V0IChFQ1AvRVBQL1BTMi9O SUJCTEUpIGluIENPTVBBVElCTEUgbW9kZQ0NCnBwYzA6IEZJRk8gd2l0aCAxNi8xNi8xNiBieXRl cyB0aHJlc2hvbGQNDQpwcGMwOiBbSVRIUkVBRF0NDQpwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1 cz4gb24gcHBjMA0NCnBsaXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwDQ0K cGxpcDA6IFtJVEhSRUFEXQ0NCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czANDQpscHQwOiBbSVRI UkVBRF0NDQpscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQNDQpwcGkwOiA8UGFyYWxsZWwgSS9P PiBvbiBwcGJ1czANDQp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgz ZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMA0NCnVhcnQwOiBbRklMVEVSXQ0NCnVhcnQwOiBj b25zb2xlICg5NjAwLG4sOCwxKQ0NCnVhcnQxOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAw eDJmOC0weDJmZiBpcnEgMyBvbiBhY3BpMA0NCnVhcnQxOiBbRklMVEVSXQ0NCnBtdGltZXIwIG9u IGlzYTANDQpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4ZDAwMDAtMHhkNDdmZiBw bnBpZCBPUk0wMDAwIG9uIGlzYTANDQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgx MDAgb24gaXNhMA0NCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDEwMD4N DQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAw MDAtMHhiZmZmZiBvbiBpc2EwDQ0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQy KT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMA0NCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEg MSBvbiBhdGtiZGMwDQ0Ka2JkMCBhdCBhdGtiZDANDQphdGtiZDA6IFtHSUFOVC1MT0NLRURdDQ0K YXRrYmQwOiBbSVRIUkVBRF0NDQpwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJv bD4gb24gY3B1MA0NClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAyNTU4NTM1NzIwIEh6IHF1 YWxpdHkgODAwDQ0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0NCnVzYnVzMDog MTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANDQp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVT QiB2MS4wDQ0KdXNidXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMA0NCnVzYnVzMzogNDgw TWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wDQ0KdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czANDQp1 aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAxPiBvbiB1c2J1czANDQp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQ0NCnVodWIxOiA8SW50 ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVz YnVzMQ0NCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyDQ0KdWh1YjI6IDxJbnRlbCBVSENJIHJv b3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyDQ0KdWdl bjMuMTogPEludGVsPiBhdCB1c2J1czMNDQp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMNDQphZDA6IDc2MzE5TUIg PFdEQyBXRDgwMEJCLTAwQ0FBMSAxNy4wN1cxNz4gYXQgYXRhMC1tYXN0ZXIgVURNQTEwMCANDQph Y2QwOiBEVkRST00gPEhMLURULVNURFZELVJPTSBHRFI4MTYxQi8wMTAwPiBhdCBhdGEwLXNsYXZl IFVETUEzMyANDQphdGExOiBETUEgbGltaXRlZCB0byBVRE1BMzMsIGNvbnRyb2xsZXIgZm91bmQg bm9uLUFUQTY2IGNhYmxlDQ0KYWNkMTogRFZEUiA8SEwtRFQtU1REVkQtUkFNIEdIMjJOUDIwLzEu MDI+IGF0IGF0YTEtbWFzdGVyIFVETUEzMyANDQphZDQ6IDk1Mzg2OU1CIDxTQU1TVU5HIEhEMTAz VUogMUFBMDExMTM+IGF0IGF0YTItbWFzdGVyIFVETUExMDAgU0FUQSAxLjVHYi9zDQ0KdWh1YjA6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQ0KdWh1YjE6IDIgcG9ydHMg d2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQ0KdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkDQ0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzDQ0K Um9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzDQ0KdWh1YjM6IDYgcG9ydHMgd2l0aCA2IHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkDQ0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rl di9hZDRzMmENDQpTZXR0aW5nIGhvc3R1dWlkOiAxY2NlMTg5NC0xM2YxLTExZTAtYTY4My0wMDUw YmZlMTNiMzUuDQpTZXR0aW5nIGhvc3RpZDogMHgwNjViMTMxYS4NCkVudHJvcHkgaGFydmVzdGlu ZzogaW50ZXJydXB0cyBldGhlcm5ldCBwb2ludF90b19wb2ludCBraWNrc3RhcnQuDQpTdGFydGlu ZyBmaWxlIHN5c3RlbSBjaGVja3M6DQovZGV2L2FkNHMyYTogRklMRSBTWVNURU0gQ0xFQU47IFNL SVBQSU5HIENIRUNLUw0KL2Rldi9hZDRzMmE6IGNsZWFuLCA4NzQ5MiBmcmVlICgxNDkyIGZyYWdz LCAxMDc1MCBibG9ja3MsIDAuNiUgZnJhZ21lbnRhdGlvbikNCi9kZXYvYWQ0czJlOiBGSUxFIFNZ U1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTDQovZGV2L2FkNHMyZTogY2xlYW4sIDI1MDcxMyBm cmVlICg0MSBmcmFncywgMzEzMzQgYmxvY2tzLCAwLjAlIGZyYWdtZW50YXRpb24pDQovZGV2L2Fk NHMyZjogRklMRSBTWVNURU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUw0KL2Rldi9hZDRzMmY6IGNs ZWFuLCAyMDI4NzA5OSBmcmVlICg1OTYyNyBmcmFncywgMjUyODQzNCBibG9ja3MsIDAuMiUgZnJh Z21lbnRhdGlvbikNCi9kZXYvYWQ0czJkOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hF Q0tTDQovZGV2L2FkNHMyZDogY2xlYW4sIDExNDE1MDMgZnJlZSAoMzI3MSBmcmFncywgMTQyMjc5 IGJsb2NrcywgMC4zJSBmcmFnbWVudGF0aW9uKQ0KTW91bnRpbmcgbG9jYWwgZmlsZSBzeXN0ZW1z Oi4NClNldHRpbmcgaG9zdG5hbWU6IHN3YW5ic2QudjdmLmV1Lg0KcmwwOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gRE9XTg0KU3RhcnRpbmcgTmV0d29yazogbG8wIHJsMC4NCmxvMDogZmxhZ3M9ODA0 OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0DQoJb3B0 aW9ucz0zPFJYQ1NVTSxUWENTVU0+DQoJaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAweGZmMDAwMDAw IA0KCWluZXQ2IDo6MSBwcmVmaXhsZW4gMTI4IA0KCWluZXQ2IGZlODA6OjElbG8wIHByZWZpeGxl biA2NCBzY29wZWlkIDB4MyANCgluZDYgb3B0aW9ucz0zPFBFUkZPUk1OVUQsQUNDRVBUX1JUQURW Pg0KcmwwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNU PiBtZXRyaWMgMCBtdHUgMTUwMA0KCW9wdGlvbnM9MzgwODxWTEFOX01UVSxXT0xfVUNBU1QsV09M X01DQVNULFdPTF9NQUdJQz4NCglldGhlciAwMDo1MDpiZjplMTozYjozNQ0KCWluZXQgMTkyLjE2 OC4wLjMgbmV0bWFzayAweGZmZmZmZjAwIGJyb2FkY2FzdCAxOTIuMTY4LjAuMjU1DQoJaW5ldDYg ZmU4MDo6MjUwOmJmZmY6ZmVlMTozYjM1JXJsMCBwcmVmaXhsZW4gNjQgdGVudGF0aXZlIHNjb3Bl aWQgMHgxIA0KCW5kNiBvcHRpb25zPTM8UEVSRk9STU5VRCxBQ0NFUFRfUlRBRFY+DQoJbWVkaWE6 IEV0aGVybmV0IGF1dG9zZWxlY3QgKG5vbmUpDQoJc3RhdHVzOiBubyBjYXJyaWVyDQphZGQgbmV0 IGRlZmF1bHQ6IGdhdGV3YXkgMTkyLjE2OC4wLjI1MA0KYWRkIG5ldCA6OmZmZmY6MC4wLjAuMDog Z2F0ZXdheSA6OjENCmFkZCBuZXQgOjowLjAuMC4wOiBnYXRld2F5IDo6MQ0KbmV0LmluZXQ2Lmlw Ni5mb3J3YXJkaW5nOiAwIC0+IDANCnBsaXAwOiBmbGFncz04ODEwPFBPSU5UT1BPSU5ULFNJTVBM RVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMA0KbG8wOiBmbGFncz04MDQ5PFVQLExPT1BC QUNLLFJVTk5JTkcsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTYzODQNCglvcHRpb25zPTM8UlhD U1VNLFRYQ1NVTT4NCglpbmV0NiA6OjEgcHJlZml4bGVuIDEyOCANCglpbmV0NiBmZTgwOjoxJWxv MCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDMgDQpuZXQuaW5ldDYuaXA2LmFjY2VwdF9ydGFkdjog MCAtPiAxDQpybDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0KYWRkIG5ldCBmZTgwOjo6IGdh dGV3YXkgOjoxDQphZGQgbmV0IGZmMDI6OjogZ2F0ZXdheSA6OjENCklQdjQgbWFwcGVkIElQdjYg YWRkcmVzcyBzdXBwb3J0PU5PDQpTdGFydGluZyBkZXZkLg0KRUxGIGxkY29uZmlnIHBhdGg6IC9s aWIgL3Vzci9saWIgL3Vzci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGli L2NvbXBhdC9wa2cgL3Vzci9sb2NhbC9rZGU0L2xpYiAvdXNyL2xvY2FsL2xpYi9jb21wYXQgL3Vz ci9sb2NhbC9saWIvY29tcGF0L3BrZyAvdXNyL2xvY2FsL2xpYi9ldm9sdXRpb24vMi4zMiAvdXNy L2xvY2FsL2xpYi9saWJ4dWwgL3Vzci9sb2NhbC9saWIvbXlzcWwgL3Vzci9sb2NhbC9saWIvbnNz IC91c3IvbG9jYWwvbGliL3B0aCAvdXNyL2xvY2FsL2xpYi9xdDQgL3Vzci9sb2NhbC9saWIvc2Ft YmE0DQphLm91dCBsZGNvbmZpZyBwYXRoOiAvdXNyL2xpYi9hb3V0IC91c3IvbGliL2NvbXBhdC9h b3V0DQpDcmVhdGluZyBhbmQvb3IgdHJpbW1pbmcgbG9nIGZpbGVzLg0KU3RhcnRpbmcgc3lzbG9n ZC4NCk5vIGNvcmUgZHVtcHMgZm91bmQuDQpTZXR0aW5nIGRhdGUgdmlhIG50cC4NCiA5IEphbiAw ODozNjo1MyBudHBkYXRlWzc1MV06IHN0ZXAgdGltZSBzZXJ2ZXIgMTkzLjc5LjIzNy4xNCBvZmZz ZXQgMC42Mjc2Njkgc2VjDQpDbGVhcmluZyAvdG1wIChYIHJlbGF0ZWQpLg0KVXBkYXRpbmcgbW90 ZDouDQpTdGFydGluZyBudHBkLg0KU3RhcnRpbmcgZGJ1cy4NClN0YXJ0aW5nIGhhbGQuDQpDb25m aWd1cmluZyBzeXNjb25zOiBrZXltYXAgYmxhbmt0aW1lLg0KU3RhcnRpbmcgc3NoZC4NClN0YXJ0 aW5nIGNyb24uDQoKU3VuIEphbiAgOSAxMDoxMToxNyBDRVQgMjAxMQ0KdW5rbm93bjogVElNRU9V VCAtIFdSSVRFX0RNQTQ4IHJldHJ5aW5nICgxIHJldHJ5IGxlZnQpIExCQT0yNzQ3OTk4MjANDQph dGEyOiB0aW1lb3V0IHdhaXRpbmcgdG8gaXNzdWUgY29tbWFuZA0NCmF0YTI6IGVycm9yIGlzc3Vp bmcgV1JJVEVfRE1BNDggY29tbWFuZA0NCmdfdmZzX2RvbmUoKTphZDRzMmZbV1JJVEUob2Zmc2V0 PTI4OTE1MTA1NzkyLCBsZW5ndGg9MTMxMDcyKV1lcnJvciA9IDYNDQovdXNyOiBnb3QgZXJyb3Ig NiB3aGlsZSBhY2Nlc3NpbmcgZmlsZXN5c3RlbQ0NCnBhbmljOiBzb2Z0ZGVwX2RlYWxsb2NhdGVf ZGVwZW5kZW5jaWVzOiB1bnJlY292ZXJlZCBJL08gZXJyb3INDQpjcHVpZCA9IDANDQpLREI6IHN0 YWNrIGJhY2t0cmFjZToNDQojMCAweGMwOGUwZjc3IGF0IGtkYl9iYWNrdHJhY2UrMHg0Nw0NCiMx IDB4YzA4YjIwMzcgYXQgcGFuaWMrMHgxMTcNDQojMiAweGMwYWUyZWNkIGF0IHNvZnRkZXBfZGVh bGxvY2F0ZV9kZXBlbmRlbmNpZXMrMHgzZA0NCiMzIDB4YzA5MjU1OTAgYXQgYnJlbHNlKzB4OTAN DQojNCAweGMwOTI4MjlhIGF0IGJ1ZmRvbmVfZmluaXNoKzB4M2ZhDQ0KIzUgMHhjMDkyODMwZCBh dCBidWZkb25lKzB4NGQNDQojNiAweGMwOTJiZGY5IGF0IGNsdXN0ZXJfY2FsbGJhY2srMHg4OQ0N CiM3IDB4YzA5MjgyZjcgYXQgYnVmZG9uZSsweDM3DQ0KIzggMHhjMDg1MGFkNSBhdCBnX3Zmc19k b25lKzB4ODUNDQojOSAweGMwOTIyNGQ5IGF0IGJpb2RvbmUrMHhiOQ0NCiMxMCAweGMwODRkYTY5 IGF0IGdfaW9fc2NoZWR1bGVfdXArMHg3OQ0NCiMxMSAweGMwODRlMGE4IGF0IGdfdXBfcHJvY2Jv ZHkrMHg2OA0NCiMxMiAweGMwODg2ZmMxIGF0IGZvcmtfZXhpdCsweDkxDQ0KIzEzIDB4YzBiY2Mx NDQgYXQgZm9ya190cmFtcG9saW5lKzB4OA0NClVwdGltZTogMmg1Nm0yN3MNDQpQaHlzaWNhbCBt ZW1vcnk6IDE1MTUgTUINDQpEdW1waW5nIDE3NyBNQjphdGEyOiB0aW1lb3V0IHdhaXRpbmcgdG8g aXNzdWUgY29tbWFuZA0NCmF0YTI6IGVycm9yIGlzc3VpbmcgV1JJVEVfRE1BIGNvbW1hbmQNDQoN DQoqKiBEVU1QIEZBSUxFRCAoRVJST1IgNSkgKioNDQpBdXRvbWF0aWMgcmVib290IGluIDE1IHNl Y29uZHMgLSBwcmVzcyBhIGtleSBvbiB0aGUgY29uc29sZSB0byBhYm9ydA0NClJlYm9vdGluZy4u Lg0NCg== --00163630f77d4e05a00499683739-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 12:06:23 2011 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 51C75106564A for ; Sun, 9 Jan 2011 12:06:23 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id AB08F8FC08 for ; Sun, 9 Jan 2011 12:06:22 +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 p09C6Has064568 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 9 Jan 2011 12:06:18 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk p09C6Has064568 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1294574778; bh=sfxHftCu1NlZX42Vhw0hrd/q0XW2fR4yDW0Xw7PHdAw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4D29A4B2.5090902@infracaninophile.co.uk>|Date:=20S un,=2009=20Jan=202011=2012:06:10=20+0000|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.13)=20Gecko/20101207=20Thunderbird/3.1.7|MIME-Version:=201 .0|To:=20"Patrick=20M.=20Hausen"=20|CC:=20Jean-Yv es=20Avenard=20,=20freebsd-stable@freebsd.org |Subject:=20Re:=20ZFS=20-=20moving=20from=20a=20zraid1=20to=20zrai d2=20pool=20with=201.5tb=20disks|References:=20<4D1C6F90.3080206@m y.gd>=09=09<4D21E679.80002@my.gd>=09 <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd>=09=09=09<4D297587.4030108@infracaninophile.co.uk>=20=20<4D2987E0 .7060701@infracaninophile.co.uk>=20<5F1A810A-E5B9-420E-89C1-4316A0 4B9A75@punkt.de>|In-Reply-To:=20<5F1A810A-E5B9-420E-89C1-4316A04B9 A75@punkt.de>|X-Enigmail-Version:=201.1.1|OpenPGP:=20id=3D60AE908C |Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha1=3B=0D=0A= 20protocol=3D"application/pgp-signature"=3B=0D=0A=20boundary=3D"-- ----------enigC11367E7E0A1CBE808F8CE86"; b=xCab1Eq7Yr/X86P8Xi4yRL8J1xcOZxYx7cb5yQByavok632iXIwn76MSndiWtTHWR Fe4yXxtBFK+ifz3+eH56/gSCheI9zlN0RXdxGjssBjnmh00BUc7NvAPp1VLFtewHEY vbmGrLK6bivPDqQyYbyRGRqSEjtYzpvDkZMPS7vY= Message-ID: <4D29A4B2.5090902@infracaninophile.co.uk> Date: Sun, 09 Jan 2011 12:06:10 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Patrick M. Hausen" References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> <4D297587.4030108@infracaninophile.co.uk> <4D2987E0.7060701@infracaninophile.co.uk> <5F1A810A-E5B9-420E-89C1-4316A04B9A75@punkt.de> In-Reply-To: <5F1A810A-E5B9-420E-89C1-4316A04B9A75@punkt.de> X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC11367E7E0A1CBE808F8CE86" X-Virus-Scanned: clamav-milter 0.96.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org, Jean-Yves Avenard Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 12:06:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC11367E7E0A1CBE808F8CE86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/01/2011 10:14, Patrick M. Hausen wrote: > I assume you are familiar with these papers? >=20 > http://queue.acm.org/detail.cfm?id=3D1317403 > http://queue.acm.org/detail.cfm?id=3D1670144 >=20 > Short version: as hard disk sizes increase to 2 TB and beyond while the= URE rate > stays in the order of 1 to 10^14 blocks read, the probability of encoun= tering an URE > during rebuild of a single parity RAID approaches 1. Yes. Rotating magnetic media seems to be bumping up against some intrinsic performance/reliability limits to the year-on-year doubling of capacity. Having to add more and more "extra" drives to ensure the same level of reliability is not a wining proposition in the long term. Roll on solid state storage. I particularly like the sound of HP and Hynix's memristor technology. If memristors pan out, then they are going to replace both D-RAM and hard drives, and eventually replace transistors as the basic building block for electronic logic circuits. Five to ten years from now, hardware design is going to be very different, and the software that runs on it will have to be radically redesigned to match. Think what that means. * You don't have to *save* a file, ever. If it's in memory, it's in persistent storage. * The effect on RDBMS performance is going to be awesome -- none of that time consuming waiting for sync-to-disk. * A computer should be able to survive a power outage of a few seconds and carry on where it left off, without specially going into hibernation mode. * Similarly, "reboot" will be at the flick of a switch -- pretty much instant on. * Portables will look a lot more like iPads or other tablet devices, and will have battery lifetimes of several days. About the only significant difference is one will have a hinge down the middle and a built-in keyboard, while the other will only have the touch screen. Oh, and let's not forget the beneficial effects of *no moving parts* and *lower power consumption* on system reliability. Now all we need are the telcos to lay multi-Gb/s capacity fibre to every house and business, and things will start to get very interesting indeed. Cheers Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigC11367E7E0A1CBE808F8CE86 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0ppLkACgkQ8Mjk52CukIwM5gCfZYXra54vwn1OMjdJ3Rs0mxuK p+QAn0Oi8fnHVI04ZQEfoqZWdCrnxGwS =rqGc -----END PGP SIGNATURE----- --------------enigC11367E7E0A1CBE808F8CE86-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 12:18:03 2011 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 BD3391065673 for ; Sun, 9 Jan 2011 12:18:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 7E3998FC14 for ; Sun, 9 Jan 2011 12:18:03 +0000 (UTC) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta14.westchester.pa.mail.comcast.net with comcast id tQAq1f0050SCNGk5EQJ3uS; Sun, 09 Jan 2011 12:18:03 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta09.westchester.pa.mail.comcast.net with comcast id tQJ21f0022tehsa3VQJ2Mx; Sun, 09 Jan 2011 12:18:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E62F39B427; Sun, 9 Jan 2011 04:18:00 -0800 (PST) Date: Sun, 9 Jan 2011 04:18:00 -0800 From: Jeremy Chadwick To: Attila Nagy Message-ID: <20110109121800.GA37231@icarus.home.lan> References: <4D0A09AF.3040005@FreeBSD.org> <4D297943.1040507@fsn.hu> <4D29A0C7.8050002@fsn.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D29A0C7.8050002@fsn.hu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, Martin Matuska Subject: Re: New ZFSv28 patchset for 8-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: Sun, 09 Jan 2011 12:18:03 -0000 On Sun, Jan 09, 2011 at 12:49:27PM +0100, Attila Nagy wrote: > On 01/09/2011 10:00 AM, Attila Nagy wrote: > > On 12/16/2010 01:44 PM, Martin Matuska wrote: > >>Hi everyone, > >> > >>following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am > >>providing a ZFSv28 testing patch for 8-STABLE. > >> > >>Link to the patch: > >> > >>http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz > >> > >> > >I've got an IO hang with dedup enabled (not sure it's related, > >I've started to rewrite all data on pool, which makes a heavy > >load): > > > >The processes are in various states: > >65747 1001 1 54 10 28620K 24360K tx->tx 0 6:58 0.00% cvsup > >80383 1001 1 54 10 40616K 30196K select 1 5:38 0.00% rsync > > 1501 www 1 44 0 7304K 2504K zio->i 0 2:09 0.00% nginx > > 1479 www 1 44 0 7304K 2416K zio->i 1 2:03 0.00% nginx > > 1477 www 1 44 0 7304K 2664K zio->i 0 2:02 0.00% nginx > > 1487 www 1 44 0 7304K 2376K zio->i 0 1:40 0.00% nginx > > 1490 www 1 44 0 7304K 1852K zfs 0 1:30 0.00% nginx > > 1486 www 1 44 0 7304K 2400K zfsvfs 1 1:05 0.00% nginx > > > >And everything which wants to touch the pool is/becomes dead. > > > >Procstat says about one process: > ># procstat -k 1497 > > PID TID COMM TDNAME KSTACK > > 1497 100257 nginx - mi_switch > >sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV null_lock > >VOP_LOCK1_APV _vn_lock nullfs_root lookup namei vn_open_cred > >kern_openat syscallenter syscall Xfast_syscall > No, it's not related. One of the disks in the RAIDZ2 pool went bad: > (da4:arcmsr0:0:4:0): READ(6). CDB: 8 0 2 10 10 0 > (da4:arcmsr0:0:4:0): CAM status: SCSI Status Error > (da4:arcmsr0:0:4:0): SCSI status: Check Condition > (da4:arcmsr0:0:4:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered > read error) > and it seems it froze the whole zpool. Removing the disk by hand > solved the problem. > I've seen this previously on other machines with ciss. > I wonder why ZFS didn't throw it out of the pool. Hold on a minute. An unrecoverable read error does not necessarily mean the drive is bad, it could mean that the individual LBA that was attempted to be read resulted in ASC 0x11 (MEDIUM ERROR) (e.g. a bad block was encountered). I would check SMART stats on the disk (since these are probably SATA given use of arcmsr(4)) and provide those. *That* will tell you if the disk is bad. I'll help you decode the attributes values if you provide them. My understanding is that a single LBA read failure should not warrant ZFS marking the disk UNAVAIL in the pool. It should have incremented the READ error counter and that's it. Did you receive a *single* error for the disk and then things went catatonic? If the entire system got wedged (a soft wedge, e.g. kernel is still alive but nothing's happening in userland), that could be a different problem -- either with ZFS or arcmsr(4). Does ZFS have some sort of timeout value internal to itself where it will literally mark a disk UNAVAIL in the case that repeated I/O transactions takes "too long"? What is its error recovery methodology? Speaking strictly about Solaris 10 and ZFS: I have seen many, many times a system "soft wedge" after repeated I/O errors (read or write) are spewed out on the console for a single SATA disk (via AHCI), but only when the disk is used as a sole root filesystem disk (no mirror/raidz). My impression is that ZFS isn't the problem in this scenario. In most cases, post-mortem debugging on my part shows that disks encountered some CRC errors (indicating cabling issues, etc.), sometimes as few as 2, but "something else" went crazy -- or possibly ZFS couldn't mark the disk UNAVAIL (if it has that logic) because it's a single disk associated with root. Hardware in this scenario are Hitachi SATA disks with an ICH ESB2 controller, software is Solaris 10 (Generic_142901-06) with ZFS v15. -- | 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 Sun Jan 9 12:22:45 2011 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 88459106566C for ; Sun, 9 Jan 2011 12:22:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) 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 361A38FC18 for ; Sun, 9 Jan 2011 12:22:44 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id tQEV1f0031uE5Es5BQNlEW; Sun, 09 Jan 2011 12:22:45 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta16.westchester.pa.mail.comcast.net with comcast id tQNk1f00A2tehsa3cQNkbb; Sun, 09 Jan 2011 12:22:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 347BB9B427; Sun, 9 Jan 2011 04:22:43 -0800 (PST) Date: Sun, 9 Jan 2011 04:22:43 -0800 From: Jeremy Chadwick To: Tom Vijlbrief Message-ID: <20110109122243.GA37530@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.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Panic 8.2 PRERELEASE WRITE_DMA48 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, 09 Jan 2011 12:22:45 -0000 On Sun, Jan 09, 2011 at 12:33:10PM +0100, Tom Vijlbrief wrote: > The last half year I've been installing FreeBSD on several machines. > > I installed it on my main desktop system a few weeks ago which > normally runs Linux, but I get this panic under heavy disk I/O. > > It even happened during the initial sysinstall, allthough I also have > completed several buildworlds without problems. > > I can trigger it easily by accessing /usr (UFS) and a linux ext > partition simultaneously, eg by copying > large files to the /usr partition. > > Just bought a serial cable to enable the serial console of the various > FreeBSD installations, which is of good use for this problem, because > a crash dump is not written. > > Full boot output in the attachment > > Sun Jan 9 10:11:17 CET 2011 > unknown: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=274799820^M > ata2: timeout waiting to issue command^M > ata2: error issuing WRITE_DMA48 command^M > g_vfs_done():ad4s2f[WRITE(offset=28915105792, length=131072)]error = 6^M > /usr: got error 6 while accessing filesystem^M > panic: softdep_deallocate_dependencies: unrecovered I/O error^M > cpuid = 0^M > KDB: stack backtrace:^M > #0 0xc08e0f77 at kdb_backtrace+0x47^M > #1 0xc08b2037 at panic+0x117^M > #2 0xc0ae2ecd at softdep_deallocate_dependencies+0x3d^M > #3 0xc0925590 at brelse+0x90^M > #4 0xc092829a at bufdone_finish+0x3fa^M > #5 0xc092830d at bufdone+0x4d^M > #6 0xc092bdf9 at cluster_callback+0x89^M > #7 0xc09282f7 at bufdone+0x37^M > #8 0xc0850ad5 at g_vfs_done+0x85^M > #9 0xc09224d9 at biodone+0xb9^M > #10 0xc084da69 at g_io_schedule_up+0x79^M > #11 0xc084e0a8 at g_up_procbody+0x68^M > #12 0xc0886fc1 at fork_exit+0x91^M > #13 0xc0bcc144 at fork_trampoline+0x8^M > Uptime: 2h56m27s^M > Physical memory: 1515 MB^M > Dumping 177 MB:ata2: timeout waiting to issue command^M > ata2: error issuing WRITE_DMA command^M > ^M > ** DUMP FAILED (ERROR 5) **^M > Automatic reboot in 15 seconds - press a key on the console to abort^M > Rebooting...^M Can you please provide output from the following commands (after installing ports/sysutils/smartmontools, which should be version 5.40 or later (in case you haven't updated your ports tree)): $ dmesg $ smartctl -a /dev/ad4 The SMART output should act as a verifier as to whether or not you really do have a bad block on your disk (which is what READ/WRITE_DMA48 can sometimes indicate). You may also want to boot the machine in single user mode and do a manual "fsck /dev/ad4s2f". It's been proven in the past that background_fsck doesn't manage to address all issues. -- | 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 Sun Jan 9 12:42:17 2011 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 23C081065674; Sun, 9 Jan 2011 12:42:17 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id A86118FC0C; Sun, 9 Jan 2011 12:42:15 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 267D7704876; Sun, 9 Jan 2011 13:42:14 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 31.0131] X-CRM114-CacheID: sfid-20110109_13421_CEB29D0A X-CRM114-Status: Good ( pR: 31.0131 ) X-Spambayes-Classification: ham; 0.00 Message-ID: <4D29AD25.2030501@fsn.hu> Date: Sun, 09 Jan 2011 13:42:13 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D0A09AF.3040005@FreeBSD.org> <4D297943.1040507@fsn.hu> <4D29A0C7.8050002@fsn.hu> <20110109121800.GA37231@icarus.home.lan> In-Reply-To: <20110109121800.GA37231@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, Martin Matuska Subject: Re: New ZFSv28 patchset for 8-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: Sun, 09 Jan 2011 12:42:17 -0000 On 01/09/2011 01:18 PM, Jeremy Chadwick wrote: > On Sun, Jan 09, 2011 at 12:49:27PM +0100, Attila Nagy wrote: >> On 01/09/2011 10:00 AM, Attila Nagy wrote: >>> On 12/16/2010 01:44 PM, Martin Matuska wrote: >>>> Hi everyone, >>>> >>>> following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am >>>> providing a ZFSv28 testing patch for 8-STABLE. >>>> >>>> Link to the patch: >>>> >>>> http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz >>>> >>>> >>> I've got an IO hang with dedup enabled (not sure it's related, >>> I've started to rewrite all data on pool, which makes a heavy >>> load): >>> >>> The processes are in various states: >>> 65747 1001 1 54 10 28620K 24360K tx->tx 0 6:58 0.00% cvsup >>> 80383 1001 1 54 10 40616K 30196K select 1 5:38 0.00% rsync >>> 1501 www 1 44 0 7304K 2504K zio->i 0 2:09 0.00% nginx >>> 1479 www 1 44 0 7304K 2416K zio->i 1 2:03 0.00% nginx >>> 1477 www 1 44 0 7304K 2664K zio->i 0 2:02 0.00% nginx >>> 1487 www 1 44 0 7304K 2376K zio->i 0 1:40 0.00% nginx >>> 1490 www 1 44 0 7304K 1852K zfs 0 1:30 0.00% nginx >>> 1486 www 1 44 0 7304K 2400K zfsvfs 1 1:05 0.00% nginx >>> >>> And everything which wants to touch the pool is/becomes dead. >>> >>> Procstat says about one process: >>> # procstat -k 1497 >>> PID TID COMM TDNAME KSTACK >>> 1497 100257 nginx - mi_switch >>> sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV null_lock >>> VOP_LOCK1_APV _vn_lock nullfs_root lookup namei vn_open_cred >>> kern_openat syscallenter syscall Xfast_syscall >> No, it's not related. One of the disks in the RAIDZ2 pool went bad: >> (da4:arcmsr0:0:4:0): READ(6). CDB: 8 0 2 10 10 0 >> (da4:arcmsr0:0:4:0): CAM status: SCSI Status Error >> (da4:arcmsr0:0:4:0): SCSI status: Check Condition >> (da4:arcmsr0:0:4:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered >> read error) >> and it seems it froze the whole zpool. Removing the disk by hand >> solved the problem. >> I've seen this previously on other machines with ciss. >> I wonder why ZFS didn't throw it out of the pool. > Hold on a minute. An unrecoverable read error does not necessarily mean > the drive is bad, it could mean that the individual LBA that was > attempted to be read resulted in ASC 0x11 (MEDIUM ERROR) (e.g. a bad > block was encountered). I would check SMART stats on the disk (since > these are probably SATA given use of arcmsr(4)) and provide those. > *That* will tell you if the disk is bad. I'll help you decode the > attributes values if you provide them. You are right, and I gave incorrect information. There are a lot more errors for that disk in the logs, and the zpool was frozen. I tried to offline the given disk. That helped in the ciss case, where the symptom is the same, or something similar, like there is no IO for ages, then something small and nothing for long seconds/minutes, and there are no errors logged. zpool status reported no errors, and the dmesg was clear too. There I could find the bad disk by watching gstat output and there I saw when the very small amount of IO was done, there was one disk with response times well above a second, while the others responded quickly. There the zpool offline helped. Here not, the command just got hang, like everything else. So what I did then: got into the areca-cli and searched for errors. One disk was set to failed and it seemed to be the cause. I've removed it (and did a camcontrol rescan, but I'm not sure it was necessary or not), and suddenly the zpool offline finished and everything went back to normal. But there are two controllers in the system and now I see that the above disk is on ctrl 1, while the one I have removed is on ctrl 2. I was misleaded by their same position. So now I have an offlined disk (which produces read errors, but I couldn't see them in the zpool output) and another, which is shown as failed in the RAID controller and got removed by hand (and solved the situation): NAME STATE READ WRITE CKSUM data DEGRADED 0 0 0 raidz2-0 DEGRADED 0 0 0 label/disk20-01 ONLINE 0 0 0 label/disk20-02 ONLINE 0 0 0 label/disk20-03 ONLINE 0 0 0 label/disk20-04 ONLINE 0 0 0 label/disk20-05 OFFLINE 0 0 0 label/disk20-06 ONLINE 0 0 0 label/disk20-07 ONLINE 0 0 0 label/disk20-08 ONLINE 0 0 0 label/disk20-09 ONLINE 0 0 0 label/disk20-10 ONLINE 0 0 0 label/disk20-11 ONLINE 0 0 0 label/disk20-12 ONLINE 0 0 0 raidz2-1 DEGRADED 0 0 0 label/disk21-01 ONLINE 0 0 0 label/disk21-02 ONLINE 0 0 0 label/disk21-03 ONLINE 0 0 0 label/disk21-04 ONLINE 0 0 0 label/disk21-05 REMOVED 0 0 0 label/disk21-06 ONLINE 0 0 0 label/disk21-07 ONLINE 0 0 0 label/disk21-08 ONLINE 0 0 0 label/disk21-09 ONLINE 0 0 0 label/disk21-10 ONLINE 0 0 0 label/disk21-11 ONLINE 0 0 0 label/disk21-12 ONLINE 0 0 0 cache ad4s2 ONLINE 0 0 0 ad6s2 ONLINE 0 0 0 > My understanding is that a single LBA read failure should not warrant > ZFS marking the disk UNAVAIL in the pool. It should have incremented > the READ error counter and that's it. Did you receive a *single* error > for the disk and then things went catatonic? No, there are more entries in the logs, but only for disk 20-05, which I zpool offlined without success and nothing about disk 21-05, which I have removed by hand in the controller, which marked it as failed. As you can see, all counters are zero, I haven't cleared them. > If the entire system got wedged (a soft wedge, e.g. kernel is still > alive but nothing's happening in userland), that could be a different > problem -- either with ZFS or arcmsr(4). Does ZFS have some sort of > timeout value internal to itself where it will literally mark a disk > UNAVAIL in the case that repeated I/O transactions takes "too long"? > What is its error recovery methodology? No, everything was fine, because the system is on UFS. So only the zpool was dead, I could log into the machine. That's what I'm asking too, because I saw some similar errors (see above) on different machines, and from that I would think there is no forced timeout, this can make the system livelock like this. I use ZFS mostly on RAID controllers, but if I remember correctly I could see exactly the same problem on an X4540 too (which has a plain SAS controller), gstat helped there too, by showing which disk has a very long response time. > Speaking strictly about Solaris 10 and ZFS: I have seen many, many times > a system "soft wedge" after repeated I/O errors (read or write) are > spewed out on the console for a single SATA disk (via AHCI), but only > when the disk is used as a sole root filesystem disk (no mirror/raidz). > My impression is that ZFS isn't the problem in this scenario. In most > cases, post-mortem debugging on my part shows that disks encountered > some CRC errors (indicating cabling issues, etc.), sometimes as few as > 2, but "something else" went crazy -- or possibly ZFS couldn't mark the > disk UNAVAIL (if it has that logic) because it's a single disk > associated with root. Hardware in this scenario are Hitachi SATA disks > with an ICH ESB2 controller, software is Solaris 10 (Generic_142901-06) > with ZFS v15. > I don't think it's cabling, it's the disks. I could repair all these errors by replacing the disks with a new one, and these are hot swap drives, so I wouldn't think about physical contact errors. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 12:54:04 2011 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 021BB106566B; Sun, 9 Jan 2011 12:54:04 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 771228FC13; Sun, 9 Jan 2011 12:54:03 +0000 (UTC) Received: by qyk36 with SMTP id 36so18107733qyk.13 for ; Sun, 09 Jan 2011 04:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bVxi646sCt6eWAFASlMHwz0m2lkBuEw/d/PAATnLj7o=; b=BNx/gMGYssz3Szu7ekDko4hzKMfPT/hljMrWtZSLINvQ8V8L2cxly/A1QJplRzZwl1 /CUC0DxZpTdFfR9VeVY7Wo+hipUwi4SEF7eVCUEIBqGhmJkf/vjpRWedYvlyige2E7j9 CQBOkeNfFJLeA38cx2D265UepbOkWAZ+kF5v0= 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=pwwb3sZTvxuB/JZdTePbYESZMUNd89hRCd8wg+bQ30miy4nhglFW29wlD646gxQqQ8 5Q0uYgbl5S82br3OVV5tM8g2/10uz4qPzmHhyHu0+jSQFM8tPMQ+D68xj3Fo5qZ2DXXp Z2NxbpxXxPIrkhokauWFGqxIZ2SR2N3IO04Hk= MIME-Version: 1.0 Received: by 10.229.246.79 with SMTP id lx15mr24578675qcb.25.1294575755846; Sun, 09 Jan 2011 04:22:35 -0800 (PST) Received: by 10.229.230.5 with HTTP; Sun, 9 Jan 2011 04:22:35 -0800 (PST) In-Reply-To: <20110109121800.GA37231@icarus.home.lan> References: <4D0A09AF.3040005@FreeBSD.org> <4D297943.1040507@fsn.hu> <4D29A0C7.8050002@fsn.hu> <20110109121800.GA37231@icarus.home.lan> Date: Sun, 9 Jan 2011 07:22:35 -0500 Message-ID: From: Rich To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Martin Matuska Subject: Re: New ZFSv28 patchset for 8-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: Sun, 09 Jan 2011 12:54:04 -0000 Once upon a time, this was a known problem with the arcmsr driver not correctly interacting with ZFS, resulting in this behavior. Since I'm presuming that the arcmsr driver update which was intended to fix this behavior (in my case, at least) is in your nightly build, it's probably worth pinging the arcmsr driver maintainer about this. - Rich On Sun, Jan 9, 2011 at 7:18 AM, Jeremy Chadwick wrote: > On Sun, Jan 09, 2011 at 12:49:27PM +0100, Attila Nagy wrote: >> =A0On 01/09/2011 10:00 AM, Attila Nagy wrote: >> > On 12/16/2010 01:44 PM, Martin Matuska wrote: >> >>Hi everyone, >> >> >> >>following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I = am >> >>providing a ZFSv28 testing patch for 8-STABLE. >> >> >> >>Link to the patch: >> >> >> >>http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215= .patch.xz >> >> >> >> >> >I've got an IO hang with dedup enabled (not sure it's related, >> >I've started to rewrite all data on pool, which makes a heavy >> >load): >> > >> >The processes are in various states: >> >65747 =A0 1001 =A0 =A0 =A01 =A054 =A0 10 28620K 24360K tx->tx =A00 =A0 = 6:58 =A00.00% cvsup >> >80383 =A0 1001 =A0 =A0 =A01 =A054 =A0 10 40616K 30196K select =A01 =A0 = 5:38 =A00.00% rsync >> > 1501 www =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A07304K =A02504K zio->i =A0= 0 =A0 2:09 =A00.00% nginx >> > 1479 www =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A07304K =A02416K zio->i =A0= 1 =A0 2:03 =A00.00% nginx >> > 1477 www =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A07304K =A02664K zio->i =A0= 0 =A0 2:02 =A00.00% nginx >> > 1487 www =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A07304K =A02376K zio->i =A0= 0 =A0 1:40 =A00.00% nginx >> > 1490 www =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A07304K =A01852K zfs =A0 = =A0 0 =A0 1:30 =A00.00% nginx >> > 1486 www =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A07304K =A02400K zfsvfs =A0= 1 =A0 1:05 =A00.00% nginx >> > >> >And everything which wants to touch the pool is/becomes dead. >> > >> >Procstat says about one process: >> ># procstat -k 1497 >> > =A0PID =A0 =A0TID COMM =A0 =A0 =A0 =A0 =A0 =A0 TDNAME =A0 =A0 =A0 =A0 = =A0 KSTACK >> > 1497 100257 nginx =A0 =A0 =A0 =A0 =A0 =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0mi_switch >> >sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV null_lock >> >VOP_LOCK1_APV _vn_lock nullfs_root lookup namei vn_open_cred >> >kern_openat syscallenter syscall Xfast_syscall >> No, it's not related. One of the disks in the RAIDZ2 pool went bad: >> (da4:arcmsr0:0:4:0): READ(6). CDB: 8 0 2 10 10 0 >> (da4:arcmsr0:0:4:0): CAM status: SCSI Status Error >> (da4:arcmsr0:0:4:0): SCSI status: Check Condition >> (da4:arcmsr0:0:4:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered >> read error) >> and it seems it froze the whole zpool. Removing the disk by hand >> solved the problem. >> I've seen this previously on other machines with ciss. >> I wonder why ZFS didn't throw it out of the pool. > > Hold on a minute. =A0An unrecoverable read error does not necessarily mea= n > the drive is bad, it could mean that the individual LBA that was > attempted to be read resulted in ASC 0x11 (MEDIUM ERROR) (e.g. a bad > block was encountered). =A0I would check SMART stats on the disk (since > these are probably SATA given use of arcmsr(4)) and provide those. > *That* will tell you if the disk is bad. =A0I'll help you decode the > attributes values if you provide them. > > My understanding is that a single LBA read failure should not warrant > ZFS marking the disk UNAVAIL in the pool. =A0It should have incremented > the READ error counter and that's it. =A0Did you receive a *single* error > for the disk and then things went catatonic? > > If the entire system got wedged (a soft wedge, e.g. kernel is still > alive but nothing's happening in userland), that could be a different > problem -- either with ZFS or arcmsr(4). =A0Does ZFS have some sort of > timeout value internal to itself where it will literally mark a disk > UNAVAIL in the case that repeated I/O transactions takes "too long"? > What is its error recovery methodology? > > Speaking strictly about Solaris 10 and ZFS: I have seen many, many times > a system "soft wedge" after repeated I/O errors (read or write) are > spewed out on the console for a single SATA disk (via AHCI), but only > when the disk is used as a sole root filesystem disk (no mirror/raidz). > My impression is that ZFS isn't the problem in this scenario. =A0In most > cases, post-mortem debugging on my part shows that disks encountered > some CRC errors (indicating cabling issues, etc.), sometimes as few as > 2, but "something else" went crazy -- or possibly ZFS couldn't mark the > disk UNAVAIL (if it has that logic) because it's a single disk > associated with root. =A0Hardware in this scenario are Hitachi SATA disks > with an ICH ESB2 controller, software is Solaris 10 (Generic_142901-06) > with ZFS v15. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 jdc@parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountain = View, CA, USA | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP= 4BD6C0CB | > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 13:27:06 2011 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 6B911106564A for ; Sun, 9 Jan 2011 13:27:06 +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 4E0378FC14 for ; Sun, 9 Jan 2011 13:27:06 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta12.emeryville.ca.mail.comcast.net with comcast id sxSa1f0050cQ2SLACRT5ia; Sun, 09 Jan 2011 13:27:05 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta10.emeryville.ca.mail.comcast.net with comcast id tRT41f00J2tehsa8WRT4qX; Sun, 09 Jan 2011 13:27:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7525F9B427; Sun, 9 Jan 2011 05:27:04 -0800 (PST) Date: Sun, 9 Jan 2011 05:27:04 -0800 From: Jeremy Chadwick To: Attila Nagy Message-ID: <20110109132704.GA38278@icarus.home.lan> References: <4D0A09AF.3040005@FreeBSD.org> <4D297943.1040507@fsn.hu> <4D29A0C7.8050002@fsn.hu> <20110109121800.GA37231@icarus.home.lan> <4D29AD25.2030501@fsn.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D29AD25.2030501@fsn.hu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, Martin Matuska Subject: Re: New ZFSv28 patchset for 8-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: Sun, 09 Jan 2011 13:27:06 -0000 On Sun, Jan 09, 2011 at 01:42:13PM +0100, Attila Nagy wrote: > On 01/09/2011 01:18 PM, Jeremy Chadwick wrote: > >On Sun, Jan 09, 2011 at 12:49:27PM +0100, Attila Nagy wrote: > >> On 01/09/2011 10:00 AM, Attila Nagy wrote: > >>>On 12/16/2010 01:44 PM, Martin Matuska wrote: > >>>>Hi everyone, > >>>> > >>>>following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am > >>>>providing a ZFSv28 testing patch for 8-STABLE. > >>>> > >>>>Link to the patch: > >>>> > >>>>http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz > >>>> > >>>> > >>>I've got an IO hang with dedup enabled (not sure it's related, > >>>I've started to rewrite all data on pool, which makes a heavy > >>>load): > >>> > >>>The processes are in various states: > >>>65747 1001 1 54 10 28620K 24360K tx->tx 0 6:58 0.00% cvsup > >>>80383 1001 1 54 10 40616K 30196K select 1 5:38 0.00% rsync > >>>1501 www 1 44 0 7304K 2504K zio->i 0 2:09 0.00% nginx > >>>1479 www 1 44 0 7304K 2416K zio->i 1 2:03 0.00% nginx > >>>1477 www 1 44 0 7304K 2664K zio->i 0 2:02 0.00% nginx > >>>1487 www 1 44 0 7304K 2376K zio->i 0 1:40 0.00% nginx > >>>1490 www 1 44 0 7304K 1852K zfs 0 1:30 0.00% nginx > >>>1486 www 1 44 0 7304K 2400K zfsvfs 1 1:05 0.00% nginx > >>> > >>>And everything which wants to touch the pool is/becomes dead. > >>> > >>>Procstat says about one process: > >>># procstat -k 1497 > >>> PID TID COMM TDNAME KSTACK > >>>1497 100257 nginx - mi_switch > >>>sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV null_lock > >>>VOP_LOCK1_APV _vn_lock nullfs_root lookup namei vn_open_cred > >>>kern_openat syscallenter syscall Xfast_syscall > >>No, it's not related. One of the disks in the RAIDZ2 pool went bad: > >>(da4:arcmsr0:0:4:0): READ(6). CDB: 8 0 2 10 10 0 > >>(da4:arcmsr0:0:4:0): CAM status: SCSI Status Error > >>(da4:arcmsr0:0:4:0): SCSI status: Check Condition > >>(da4:arcmsr0:0:4:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered > >>read error) > >>and it seems it froze the whole zpool. Removing the disk by hand > >>solved the problem. > >>I've seen this previously on other machines with ciss. > >>I wonder why ZFS didn't throw it out of the pool. > >Hold on a minute. An unrecoverable read error does not necessarily mean > >the drive is bad, it could mean that the individual LBA that was > >attempted to be read resulted in ASC 0x11 (MEDIUM ERROR) (e.g. a bad > >block was encountered). I would check SMART stats on the disk (since > >these are probably SATA given use of arcmsr(4)) and provide those. > >*That* will tell you if the disk is bad. I'll help you decode the > >attributes values if you provide them. > You are right, and I gave incorrect information. There are a lot > more errors for that disk in the logs, and the zpool was frozen. > I tried to offline the given disk. That helped in the ciss case, > where the symptom is the same, or something similar, like there is > no IO for ages, then something small and nothing for long > seconds/minutes, and there are no errors logged. zpool status > reported no errors, and the dmesg was clear too. > There I could find the bad disk by watching gstat output and there I > saw when the very small amount of IO was done, there was one disk > with response times well above a second, while the others responded > quickly. > There the zpool offline helped. Here not, the command just got hang, > like everything else. > So what I did then: got into the areca-cli and searched for errors. > One disk was set to failed and it seemed to be the cause. I've > removed it (and did a camcontrol rescan, but I'm not sure it was > necessary or not), and suddenly the zpool offline finished and > everything went back to normal. > But there are two controllers in the system and now I see that the > above disk is on ctrl 1, while the one I have removed is on ctrl 2. > I was misleaded by their same position. So now I have an offlined > disk (which produces read errors, but I couldn't see them in the > zpool output) and another, which is shown as failed in the RAID > controller and got removed by hand (and solved the situation): > NAME STATE READ WRITE CKSUM > data DEGRADED 0 0 0 > raidz2-0 DEGRADED 0 0 0 > label/disk20-01 ONLINE 0 0 0 > label/disk20-02 ONLINE 0 0 0 > label/disk20-03 ONLINE 0 0 0 > label/disk20-04 ONLINE 0 0 0 > label/disk20-05 OFFLINE 0 0 0 > label/disk20-06 ONLINE 0 0 0 > label/disk20-07 ONLINE 0 0 0 > label/disk20-08 ONLINE 0 0 0 > label/disk20-09 ONLINE 0 0 0 > label/disk20-10 ONLINE 0 0 0 > label/disk20-11 ONLINE 0 0 0 > label/disk20-12 ONLINE 0 0 0 > raidz2-1 DEGRADED 0 0 0 > label/disk21-01 ONLINE 0 0 0 > label/disk21-02 ONLINE 0 0 0 > label/disk21-03 ONLINE 0 0 0 > label/disk21-04 ONLINE 0 0 0 > label/disk21-05 REMOVED 0 0 0 > label/disk21-06 ONLINE 0 0 0 > label/disk21-07 ONLINE 0 0 0 > label/disk21-08 ONLINE 0 0 0 > label/disk21-09 ONLINE 0 0 0 > label/disk21-10 ONLINE 0 0 0 > label/disk21-11 ONLINE 0 0 0 > label/disk21-12 ONLINE 0 0 0 > cache > ad4s2 ONLINE 0 0 0 > ad6s2 ONLINE 0 0 0 With regards to arcmsr(4) and this behaviour: I received a mail from Rich (which doesn't appear to have hit the freebsd-stable list yet, probably due to greylisting; I'm not sure if you received a copy of his mail yet), which indicates the wedging when the disks are on arcmsr(4) is a bug with arcmsr(4). One more thing: > I don't think it's cabling, it's the disks. I could repair all these > errors by replacing the disks with a new one, and these are hot swap > drives, so I wouldn't think about physical contact errors. You're probably right, but I'll share a story that hopefully you won't have the "pleasure" of experiencing. :-) Newer model servers at my workplace are SATA and backed by hot-swap enclosures. On occasion, a box will report disk I/O errors for LBAs which are scattered all across the platters (meaning they aren't even within 1,000,000 LBAs of one another). This causes our NOC to open a ticket stating the problem is a "bad disk". The prognosis is completely wrong (see below), and what ends up happening is our datacenter guys replace the disk only to find that the situation starts happening again within a few days. Meaning: even more customer impact + wasted efforts/time because everyone assumes an I/O error means a disk error. So why was the prognosis wrong? In these situations, I found SMART Attribute 199 (UDMA_CRC_Error_Count) has incremented numerous times (hundreds) during the issue. This attribute represents the number of times ATA command blocks between the disk and the controller didn't have matching CRCs, which is usually caused by a hardware issue. A few CRC errors during a system's lifetime is more than acceptable, but numbers in the hundreds or thousands isn't. The problem turned out to be a SATA backplane that had gone bad (there are some basic ASICs on those things) or SATA cabling between the backplane and the motherboard SATA ports was faulty. More than a few times, we found that the raw copper on the SATA cables had been exposed in a couple spots, a result of the vendor running the cable through the chassis and scraping it against sharp metal. "Oops". Disk troubleshooting is somewhat of an art, or at least thats what I'm starting to feel after doing it for so long. I like having concise explanations for why a storage device reports an error; blindly assuming it's the disk is a bad habit to get into. There are many pieces of hardware, and just as much firmware and software, between a disk and an operating system. Familiarising yourself with it all takes a lot of time (months/years), and *every situation is different*. Can I diagnose every situation that comes across my desk? Hell no. There are many which I simply can't determine the cause of, and in those situations I recommend everything get replaced (sans RAM and CPU). Have I recommended that only to have the same situation happen again? Yes, and I'm lead to believe chassis temperature, humidity, or PSU/voltage problems are responsible. Don't let SSDs fool you either; already in the past year I've seen literally 14 or 15 cases of people having their SSDs go bad, including 4 or 5 of our X25-Ms at work. When they die, it's pretty catastrophic; I haven't seen a "oh my SSD is acting wonky" situation yet, it's either all or nothing. YMMV. I do love using X25-Ms for OS disks on FreeBSD though. -- | 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 Sun Jan 9 15:41:45 2011 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 CA73F1065673 for ; Sun, 9 Jan 2011 15:41:45 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 768AF8FC08 for ; Sun, 9 Jan 2011 15:41:45 +0000 (UTC) Received: by qyk8 with SMTP id 8so663231qyk.13 for ; Sun, 09 Jan 2011 07:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V3bBvcJMsj0iqtcKtFkmxoP+lxsZfw2hIa8wlbnsxkk=; b=UY1VIzPBw/hYBSZqsdAdho+Q26Jq0tjU+6PtUgMHHbLb6DRfve88gugGoFAe+5WKu7 bQu8a3Mg3iDHK4Oz0yxCnucTP5wFvitC7g4ctGJjohzZz1LCd9j763yM5cxWKW9E+UDN 9IbLXKVxKBygDqQ2HR0DAPwz2sY4a/wZnPtfk= 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=chbS/+GCl7jthGy2sbCpcuJ8asd5fH6iPoy7V1OrixV+3lRXFf3jjyphHvaiVOL+jc NLzhhc19VfFsQxkYpKrJhQ6KVPxDmIVpbHScjNAtRDshdszqrTL32eUX56p4ABhQiizs g4o9m9IN2g1GhAIxlZhuKwzpOSFrobYN/lvF8= MIME-Version: 1.0 Received: by 10.229.227.8 with SMTP id iy8mr24116134qcb.182.1294587703947; Sun, 09 Jan 2011 07:41:43 -0800 (PST) Sender: tvijlbrief@gmail.com Received: by 10.229.50.209 with HTTP; Sun, 9 Jan 2011 07:41:43 -0800 (PST) In-Reply-To: <20110109122243.GA37530@icarus.home.lan> References: <20110109122243.GA37530@icarus.home.lan> Date: Sun, 9 Jan 2011 16:41:43 +0100 X-Google-Sender-Auth: 6nAW5qfEZbYl7kXmkHkMikznqxU Message-ID: From: Tom Vijlbrief To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Panic 8.2 PRERELEASE WRITE_DMA48 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, 09 Jan 2011 15:41:46 -0000 I've run many fscks on /usr in single user because I had soft update inconsistencies, no DMA errors during those repairs. smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-PRERELEASE i386] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D Model Family: SAMSUNG SpinPoint F1 DT series Device Model: SAMSUNG HD103UJ Serial Number: S13PJ9BQC02902 Firmware Version: 1AA01113 User Capacity: 1,000,204,886,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: Sun Jan 9 16:40:24 2011 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled =3D=3D=3D START OF READ SMART DATA SECTION =3D=3D=3D 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: Disab= led. Self-test execution status: ( 0) The previous self-test routine comp= leted without error or no self-test has e= ver been run. Total time to complete Offline data collection: (11811) 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: ( 198) minutes. Conveyance self-test routine recommended polling time: ( 21) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supporte= d. 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 078 078 011 Pre-fail Always - 7580 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 399 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 - 10097 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 2375 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 - 392 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 057 052 000 Old_age Always - 43 (Min/Max 42/45) 194 Temperature_Celsius 0x0022 056 050 000 Old_age Always - 44 (Min/Max 42/46) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 20728126 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 - 1 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 2361 = - # 2 Short offline Completed without error 00% 2205 = - # 3 Short offline Completed without error 00% 2138 = - # 4 Extended offline Completed without error 00% 2109 = - # 5 Short offline Completed without error 00% 2105 = - # 6 Short offline Completed without error 00% 2092 = - # 7 Short offline Completed without error 00% 2083 = - # 8 Short offline Completed without error 00% 2057 = - # 9 Extended offline Completed without error 00% 2037 = - #10 Short offline Completed without error 00% 2033 = - #11 Short offline Completed without error 00% 2009 = - #12 Short offline Completed without error 00% 1974 = - #13 Short offline Completed without error 00% 1941 = - #14 Extended offline Completed without error 00% 1920 = - #15 Short offline Completed without error 00% 1916 = - #16 Short offline Completed without error 00% 1868 = - #17 Short offline Completed without error 00% 1810 = - #18 Short offline Completed without error 00% 1655 = - #19 Short offline Completed without error 00% 1638 = - #20 Extended offline Completed without error 00% 1596 = - #21 Short offline Completed without error 00% 1591 = - 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. dmesg was in the attachment of the original mail but I'll paste it here: 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.2-PRERELEASE #0: Thu Dec 30 12:21:06 CET 2010 root@swanbsd.v7f.eu:/usr/obj/usr/src/sys/GENERIC i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.53GHz (2558.54-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf24 Family =3D f Model =3D 2 Stepp= ing =3D 4 Features=3D0x3febfbff real memory =3D 1610612736 (1536 MB) avail memory =3D 1555316736 (1483 MB) ACPI APIC Table: 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, 5ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xf2000000-0xf2ffffff,0xf4000000-0xf7ffffff,0xf3800000-0xf387ffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] uhci0: port 0xd800-0xd81f irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup =3D 0x2f00 usbus0: on uhci0 uhci1: port 0xd400-0xd41f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup =3D 0x2f00 usbus1: on uhci1 uhci2: port 0xd000-0xd01f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup =3D 0x2f00 usbus2: on uhci2 ehci0: mem 0xf1800000-0xf18003ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 rl0: port 0xb800-0xb8ff mem 0xf1000000-0xf10000ff irq 22 at device 10.0 on pci2 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:bf:e1:3b:35 rl0: [ITHREAD] atapci0: port 0xb400-0xb407,0xb000-0xb003,0xa800-0xa807,0xa400-0xa403,0xa000-0xa00f mem 0xf0800000-0xf08001ff irq 23 at device 11.0 on pci2 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcm0: port 0x9800-0x981f irq 20 at device 12.0 on pci2 pcm0: pcm0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f irq 18 at device 31.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] atrtc0: port 0x70-0x73 irq 8 on acpi0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd47ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] p4tcc0: on cpu0 Timecounter "TSC" frequency 2558535720 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 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 ad0: 76319MB at ata0-master UDMA100 acd0: DVDROM at ata0-slave UDMA33 ata1: DMA limited to UDMA33, controller found non-ATA66 cable acd1: DVDR at ata1-master UDMA33 ad4: 953869MB at ata2-master UDMA100 SATA 1.5Gb/= s uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered 2011/1/9 Jeremy Chadwick : > On Sun, Jan 09, 2011 at 12:33:10PM +0100, Tom Vijlbrief wrote: >> The last half year I've been installing FreeBSD on several machines. >> >> I installed it on my main desktop system a few weeks ago which >> normally runs Linux, but I get this panic under heavy disk I/O. >> >> It even happened during the initial sysinstall, allthough I also have >> completed several buildworlds without problems. >> >> I can trigger it easily by accessing /usr (UFS) and a linux ext >> partition simultaneously, eg by copying >> large files to the /usr partition. >> >> Just bought a serial cable to enable the serial console of the various >> FreeBSD installations, which is of good use for this problem, because >> a crash dump is not written. >> >> Full boot output in the attachment >> >> Sun Jan =A09 10:11:17 CET 2011 >> unknown: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=3D274799820^M >> ata2: timeout waiting to issue command^M >> ata2: error issuing WRITE_DMA48 command^M >> g_vfs_done():ad4s2f[WRITE(offset=3D28915105792, length=3D131072)]error = =3D 6^M >> /usr: got error 6 while accessing filesystem^M >> panic: softdep_deallocate_dependencies: unrecovered I/O error^M >> cpuid =3D 0^M >> KDB: stack backtrace:^M >> #0 0xc08e0f77 at kdb_backtrace+0x47^M >> #1 0xc08b2037 at panic+0x117^M >> #2 0xc0ae2ecd at softdep_deallocate_dependencies+0x3d^M >> #3 0xc0925590 at brelse+0x90^M >> #4 0xc092829a at bufdone_finish+0x3fa^M >> #5 0xc092830d at bufdone+0x4d^M >> #6 0xc092bdf9 at cluster_callback+0x89^M >> #7 0xc09282f7 at bufdone+0x37^M >> #8 0xc0850ad5 at g_vfs_done+0x85^M >> #9 0xc09224d9 at biodone+0xb9^M >> #10 0xc084da69 at g_io_schedule_up+0x79^M >> #11 0xc084e0a8 at g_up_procbody+0x68^M >> #12 0xc0886fc1 at fork_exit+0x91^M >> #13 0xc0bcc144 at fork_trampoline+0x8^M >> Uptime: 2h56m27s^M >> Physical memory: 1515 MB^M >> Dumping 177 MB:ata2: timeout waiting to issue command^M >> ata2: error issuing WRITE_DMA command^M >> ^M >> ** DUMP FAILED (ERROR 5) **^M >> Automatic reboot in 15 seconds - press a key on the console to abort^M >> Rebooting...^M > > Can you please provide output from the following commands (after > installing ports/sysutils/smartmontools, which should be version 5.40 or > later (in case you haven't updated your ports tree)): > > $ dmesg > $ smartctl -a /dev/ad4 > > The SMART output should act as a verifier as to whether or not you > really do have a bad block on your disk (which is what READ/WRITE_DMA48 > can sometimes indicate). > > You may also want to boot the machine in single user mode and do a > manual "fsck /dev/ad4s2f". =A0It's been proven in the past that > background_fsck doesn't manage to address all issues. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 jdc@parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountain = View, CA, USA | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP= 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 16:03:33 2011 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 49CBE106564A for ; Sun, 9 Jan 2011 16:03:33 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by mx1.freebsd.org (Postfix) with ESMTP id E73148FC12 for ; Sun, 9 Jan 2011 16:03:32 +0000 (UTC) Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id p09FZwJb077314; Sun, 9 Jan 2011 10:35:58 -0500 (EST) (envelope-from feenberg@nber.org) Received: from localhost (feenberg@localhost) by nber6.nber.org (8.14.4/8.14.4/Submit) with ESMTP id p09FWm2K029725; Sun, 9 Jan 2011 10:32:49 -0500 (EST) X-Authentication-Warning: nber6.nber.org: feenberg owned process doing -bs Date: Sun, 9 Jan 2011 10:32:48 -0500 (EST) From: Daniel Feenberg X-X-Sender: feenberg@nber6 To: freebsd-stable@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20110109 #4600404, check: 20110109 clean Subject: Specifying root mount options on diskless boot. 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, 09 Jan 2011 16:03:33 -0000 Daniel Braniss writes... > I have it pxebooting nicely and running with an NFS root > but it then reports locking problems: devd, syslogd, moused (and maybe > others) lock their PID file to protect against multiple instances. > Unfortunately, these daemons all start before statd/lockd and so the > locking fails and reports "operation not supported". Are you mounting /var via nfs? We have been running FreeBSD diskless for several years, and have never run into this problem - but we use a memory filesystem. The memory filesystem can be quite small. Our methods are documented at http://www.nber.org/sys-admin/FreeBSD-diskless.html If that isn't the problem, can you guess what we are doing differently to avoid it? I note that the response to your message from "danny" offers the ability to pass arguments to the nfs mount command, but also seems to offer a fix for the fact that "classes" are not supported under PXE: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/90368 I hope "danny" will offer a patch to mainline code - it would be an important improvement (and already promised in the documentation). (I am sorry if this doesn't thread properly - I just joined the list after seeing the message). The thread is available at: http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060854.html Daniel Feenberg From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 16:30:30 2011 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 7E8FF106566B for ; Sun, 9 Jan 2011 16:30:30 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0838FC1C for ; Sun, 9 Jan 2011 16:30:29 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta02.westchester.pa.mail.comcast.net with comcast id tSr11f0061uE5Es52UWW7c; Sun, 09 Jan 2011 16:30:30 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta16.westchester.pa.mail.comcast.net with comcast id tUWV1f0082tehsa3cUWV2D; Sun, 09 Jan 2011 16:30:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C9DA09B427; Sun, 9 Jan 2011 08:30:27 -0800 (PST) Date: Sun, 9 Jan 2011 08:30:27 -0800 From: Jeremy Chadwick To: Tom Vijlbrief Message-ID: <20110109163027.GA42562@icarus.home.lan> References: <20110109122243.GA37530@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.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Panic 8.2 PRERELEASE WRITE_DMA48 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, 09 Jan 2011 16:30:30 -0000 On Sun, Jan 09, 2011 at 04:41:43PM +0100, Tom Vijlbrief wrote: > I've run many fscks on /usr in single user because I had soft update > inconsistencies, > no DMA errors during those repairs. There's no 1:1 ratio between running fsck on a filesystem and seeing a DMA error. I should explain what I mean by that: just because you receive a read or write error from a disk during operation doesn't mean fsck will induce it. fsck simply checks filesystem tables and so on for integrity, it doesn't do the equivalent of a bad block scan, nor does it check (read) every data block referenced by an inode. So if you have a filesystem which has a bad block somewhere within a data block, fsck almost certainly won't catch this. ZFS, on the other hand (specifically a "zpool scrub"), would/should induce such. The reason I advocated booting into single-user and running a fsck manually is because there's confirmation that background fsck doesn't catch/handle all filesystem consistency errors that a foreground fsck does. This is why I continue to advocate background_fsck="no" in rc.conf(5). That's for another discussion though. Let's review the disk: > === START OF INFORMATION SECTION === > Model Family: SAMSUNG SpinPoint F1 DT series > Device Model: SAMSUNG HD103UJ > Serial Number: S13PJ9BQC02902 > Firmware Version: 1AA01113 > User Capacity: 1,000,204,886,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: Sun Jan 9 16:40:24 2011 CET > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > ... > 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 078 078 011 Pre-fail > Always - 7580 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age > Always - 399 > 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 - 10097 > 9 Power_On_Hours 0x0032 100 100 000 Old_age > Always - 2375 > 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 - 392 > 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 057 052 000 Old_age > Always - 43 (Min/Max 42/45) > 194 Temperature_Celsius 0x0022 056 050 000 Old_age > Always - 44 (Min/Max 42/46) > 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age > Always - 20728126 > 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 - 1 > 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age > Always - 0 > 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age > Always - 0 Your drive looks fine. Attribute 195 isn't anything to worry about (vendor-specific encoding makes this number appear large). Attribute 199 indicates one CRC error, but again nothing to worry about -- but could explain a single error during the lifetime of the drive (impossible to determine when it happened). > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > # 1 Short offline Completed without error 00% 2361 - > # 2 Short offline Completed without error 00% 2205 - > # 3 Short offline Completed without error 00% 2138 - > # 4 Extended offline Completed without error 00% 2109 - > # 5 Short offline Completed without error 00% 2105 - > # 6 Short offline Completed without error 00% 2092 - > # 7 Short offline Completed without error 00% 2083 - > # 8 Short offline Completed without error 00% 2057 - > # 9 Extended offline Completed without error 00% 2037 - > #10 Short offline Completed without error 00% 2033 - > #11 Short offline Completed without error 00% 2009 - > #12 Short offline Completed without error 00% 1974 - > #13 Short offline Completed without error 00% 1941 - > #14 Extended offline Completed without error 00% 1920 - > #15 Short offline Completed without error 00% 1916 - > #16 Short offline Completed without error 00% 1868 - > #17 Short offline Completed without error 00% 1810 - > #18 Short offline Completed without error 00% 1655 - > #19 Short offline Completed without error 00% 1638 - > #20 Extended offline Completed without error 00% 1596 - > #21 Short offline Completed without error 00% 1591 - Not to get off topic, but what is causing this? It looks like you have a cron job or something very aggressive doing a "smartctl -t short /dev/ad4" or equivalent. If you have such, please disable this immediately. You shouldn't be doing SMART tests with such regularity; it accomplishes absolutely nothing, especially the "short" tests. Let the drive operate normally, otherwise run smartd and watch logs instead. If you want to scan the disk for bad blocks, you need to do a selective LBA test. Your drive does support selective scanning, as shown here: > Offline data collection > capabilities: > ... > Selective Self-test supported. You can do this with "smartctl -t select,0-max /dev/ad4", and safely while the drive is in operation. You can check the status of the scan (assuming the Samsung supports it) by using "smartctl -c /dev/ad4" and look at the percentage of completion. However, I would expect that if your drive had bad blocks, or even blocks which the drive consisted suspect, that Attributes 196 and 197 would be non-zero. I'm more familiar with Western Digital and Seagate disks though. > dmesg was in the attachment of the original mail but I'll paste it here: I apologise, I missed that -- sometimes the mailing list software removes attachments, so I've grown accustomed to not looking for them. My bad. > atapci0: port 0xb400-0xb407,0xb000-0xb003,0xa800-0xa807,0xa400-0xa403,0xa000-0xa00f mem 0xf0800000-0xf08001ff irq 23 at device 11.0 on pci2 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ad4: 953869MB at ata2-master UDMA100 SATA 1.5Gb/s Using that information and circling back to the original error: > unknown: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=274799820^M > ata2: timeout waiting to issue command^M > ata2: error issuing WRITE_DMA48 command^M > g_vfs_done():ad4s2f[WRITE(offset=28915105792, length=131072)]error = 6^M > /usr: got error 6 while accessing filesystem^M > panic: softdep_deallocate_dependencies: unrecovered I/O error^M > cpuid = 0^M > KDB: stack backtrace:^M errno 6 is "device not configured". ad4 is on a Silicon Image controller (thankfully a reliable model). Sadly AHCI (ahci.ko) isn't in use here; I would advocate switching to it (your device names will change however) and see if these errors continue (they'll appear as SCSI CAM errors though). ahci_load="yes" in /boot/loader.conf should be enough. smartmontools does know to talk ATA to /dev/adaX (that's not a typo) disks. Am I advocating use of ahci.ko as a workaround for the problem? Sort of. I know that Alexander Motin has a lot of good experience with the Silicon Image controllers and would also advocate use of AHCI when one has such. Possibly what you're seeing is a bug or quirk of some kind in the ata(4) driver. These kinds of quirks ("I got an error but the disk itself looks fine") have concerned me on FreeBSD for many, many years now. I would recommend using ahci.ko first, then doing the selective scan only if more errors continue/show up after the fact. So in summary, at this point your drive looks fine, but I'd feel better after a selective scan had a chance to run. Purely speculative: there's always the possibility the Samsung disks do something similar to what IBM ATA drives circa 1999-2000 did: a feature called "ADM" (Automatic Drive Maintenance), where the drive would literally drop to standby mode to perform whatever. If it received an ATA command from the controller while doing this, would spin back up and respond to the command. The whole down/up process took so long that FreeBSD reported the issue as a timeout, as well as a DMA error if it was trying to do a read/write operation. You could literally hear the drive powering down then going "thunk" and powering back up when it received an ATA command. I mailed IBM about this and they confirmed it. The feature also existed on SCSI drives (and still does, I think), but is disabled by default. Here's relevant reading material: http://jdc.parodius.com/freebsd/ibm_email_aware_of_adm.txt http://www.mail-archive.com/freebsd-current@freebsd.org/msg07222.html The ATA drives that came out in 2001 and beyond had this feature *completely removed*, so it's pretty obvious it was causing problems, probably as more people started using the drives in servers vs. standard Windows desktops (well-known for hiding such I/O conditions). I imagine if Samsung drives did this we'd be seeing a lot more reports about it here on the lists. I'd pay close attention to the timestamps on the timeouts. -- | 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 Sun Jan 9 18:38:47 2011 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 CAD3A106564A for ; Sun, 9 Jan 2011 18:38:47 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (unknown [IPv6:2001:418:3fd::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9D27A8FC16 for ; Sun, 9 Jan 2011 18:38:47 +0000 (UTC) Received: from m5p.com (wonderland.m5p.com [IPv6:2001:418:3fd::19]) by mailhost.m5p.com (8.14.3/8.14.3) with ESMTP id p09IcfI3019712 for ; Sun, 9 Jan 2011 13:38:46 -0500 (EST) (envelope-from george@m5p.com) Received: (from george@localhost) by m5p.com (8.14.4/8.13.7/Submit) id p09Icfdo010086; Sun, 9 Jan 2011 13:38:41 -0500 (EST) Date: Sun, 9 Jan 2011 13:38:41 -0500 (EST) Message-Id: <201101091838.p09Icfdo010086@m5p.com> From: george+freebsd@m5p.com To: freebsd-stable@freebsd.org In-Reply-To: <954019999.13143.1294579897823.JavaMail.root@erie.cs.uoguelph.ca> X-Spam-Score: -0.9 () BAYES_00,J_CHICKENPOX_28 X-Scanned-By: MIMEDefang 2.67 on IPv6:2001:418:3fd::f7 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Sun, 09 Jan 2011 13:38:46 -0500 (EST) Subject: Re; NFS performance 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, 09 Jan 2011 18:38:47 -0000 It has been suggested that I move this thread to freebsd-stable. The thread so far (deficient NFS performance in FreeBSD 8): http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034006.html I updated my kernel to FreeBSD 8.2-PRERELEASE. This improved my throughput, but still not to the level I got from 7.3-STABLE. Here's an updated table from my original message: Observed bytes per second (dd if=filename of=/dev/null bs=65536): Source machine: mattapan scollay sullivan Destination machine: wonderland/7.3-STABLE 870K 5.2M 1.8M wonderland/8.1-STABLE 496K 690K 420K wonderland/8.2-PRERELEASE 800K 1.2M 447K Furthermore, I was still able to induce the NFS "server not responding" message with 8.2-PRERELEASE. So I applied the patch from Rick Macklem. The throughput did not change, but I haven't seen the NFS "server not responding" message yet. As to an earlier question about NFS options: I'm not setting any, so they are whatever the automounter uses by default. -- George From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 18:44:05 2011 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 E779C106564A for ; Sun, 9 Jan 2011 18:44:05 +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 A6F4F8FC18 for ; Sun, 9 Jan 2011 18:44:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAEGRKU2DaFvO/2dsb2JhbACEA6EuriKMS4EhgVaBYXQEhGeGIw X-IronPort-AV: E=Sophos;i="4.60,296,1291611600"; d="scan'208";a="106434706" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 09 Jan 2011 13:44:04 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id ABB65B3F24; Sun, 9 Jan 2011 13:44:04 -0500 (EST) Date: Sun, 9 Jan 2011 13:44:04 -0500 (EST) From: Rick Macklem To: Daniel Feenberg Message-ID: <535791711.18255.1294598644612.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: Specifying root mount options on diskless boot. 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, 09 Jan 2011 18:44:06 -0000 > Daniel Braniss writes... > > > I have it pxebooting nicely and running with an NFS root > > but it then reports locking problems: devd, syslogd, moused (and > > maybe > > others) lock their PID file to protect against multiple instances. > > Unfortunately, these daemons all start before statd/lockd and so the > > locking fails and reports "operation not supported". > > Are you mounting /var via nfs? You can use the "nolockd" mount option to make locking happen locally in the client. (Only a problem if the file(s) being locked are concurrently shared with other clients.) I don't know if this would fix your diskless problem. rick From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 19:06:53 2011 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 C6705106566B for ; Sun, 9 Jan 2011 19:06:53 +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 8A3BB8FC0C for ; Sun, 9 Jan 2011 19:06:53 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAOaVKU2DaFvO/2dsb2JhbACEApIsjwKuHIxNgSGDN3QEhGeFL3Q X-IronPort-AV: E=Sophos;i="4.60,296,1291611600"; d="scan'208";a="104746139" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 09 Jan 2011 14:06:52 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CA3D0B3F65; Sun, 9 Jan 2011 14:06:52 -0500 (EST) Date: Sun, 9 Jan 2011 14:06:52 -0500 (EST) From: Rick Macklem To: george+freebsd@m5p.com Message-ID: <70510313.18875.1294600012817.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201101091838.p09Icfdo010086@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: Re; NFS performance 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, 09 Jan 2011 19:06:53 -0000 > It has been suggested that I move this thread to freebsd-stable. The > thread so far (deficient NFS performance in FreeBSD 8): > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034006.html > > I updated my kernel to FreeBSD 8.2-PRERELEASE. This improved my > throughput, but still not to the level I got from 7.3-STABLE. Here's > an updated table from my original message: > > Observed bytes per second (dd if=filename of=/dev/null bs=65536): > Source machine: mattapan scollay sullivan > Destination machine: > wonderland/7.3-STABLE 870K 5.2M 1.8M > wonderland/8.1-STABLE 496K 690K 420K > wonderland/8.2-PRERELEASE 800K 1.2M 447K > > Furthermore, I was still able to induce the NFS "server not > responding" > message with 8.2-PRERELEASE. So I applied the patch from Rick Macklem. > The throughput did not change, but I haven't seen the NFS "server not > responding" message yet. So, did the patch get rid of the 1min + stalls you reported earlier? Beyond that, all I can suggest is trying to fiddle with some of the options on the net device driver, such as rxcsum, txcsum and tso. (I think tso has had some issues for some drivers, but I don't know any specifics.) When I've seen poor NFS perf. it has usually been a problem at the network device driver level. (If you have a different kind of network card handy, you could try swapping them. Basically one with a different net chipset so that it uses a different net device driver.) rick From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 20:02:18 2011 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 16DDD106564A for ; Sun, 9 Jan 2011 20:02:18 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id B5BFD8FC20 for ; Sun, 9 Jan 2011 20:02:17 +0000 (UTC) Received: by qwj9 with SMTP id 9so18463539qwj.13 for ; Sun, 09 Jan 2011 12:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bzwrsYzH/wJtdUuKcOvOp0pkkvqdO2SMuSP4MJfSayk=; b=HJGLN5bBMXd2rGGUq06N1YcXCdxWcTROgeVzUkCiNfZzSl5Km4sFwG3llGsK+Lo/m6 ElzEHeCYTYaCXCw8sG4WtjIBfiV+Gwx3sA7r5j61fnmpdcjOdcXXS1sX2H7G4CT8ryWl vQsTZfgBVzJOOceUXFtiouK87FnTlmZIgjKMk= 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=b3nLYenwcC1J23dAWxbEJdIF3YckukioyFFxRTw1DxKtpzkVZ4xp9IsUSi8cB2YGxP IPkzfmCwQwMcS5rPhp9t9Brz3twYXtXiivVgIF3OHw+VxKxbAa50DJv9075k2pKNgvkg U7VhQMzg3S9Z277vLGKR7La3igG9lxJ6Rj/X0= MIME-Version: 1.0 Received: by 10.229.90.196 with SMTP id j4mr23765944qcm.144.1294603336751; Sun, 09 Jan 2011 12:02:16 -0800 (PST) Sender: tvijlbrief@gmail.com Received: by 10.229.50.209 with HTTP; Sun, 9 Jan 2011 12:02:16 -0800 (PST) In-Reply-To: <20110109163027.GA42562@icarus.home.lan> References: <20110109122243.GA37530@icarus.home.lan> <20110109163027.GA42562@icarus.home.lan> Date: Sun, 9 Jan 2011 21:02:16 +0100 X-Google-Sender-Auth: 5k_yn9bQ8ZPFrxyEiTP2fCEAJ8k Message-ID: From: Tom Vijlbrief To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Panic 8.2 PRERELEASE WRITE_DMA48 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, 09 Jan 2011 20:02:18 -0000 2011/1/9 Jeremy Chadwick : > > errno 6 is "device not configured". =A0ad4 is on a Silicon Image > controller (thankfully a reliable model). =A0Sadly AHCI (ahci.ko) isn't i= n > use here; I would advocate switching to it (your device names will > change however) and see if these errors continue (they'll appear as SCSI > CAM errors though). =A0ahci_load=3D"yes" in /boot/loader.conf should be > enough. =A0smartmontools does know to talk ATA to /dev/adaX (that's not a > typo) disks. > Made that change, ahci is loaded [tom@swanbsd /usr/home/tom]$ kldstat Id Refs Address Size Name 1 16 0xc0400000 bd9998 kernel 2 1 0xc0fda000 88a8 snd_emu10k1.ko 3 3 0xc0fe3000 579b0 sound.ko 4 1 0xc103b000 4df90c nvidia.ko 5 1 0xc151b000 c108 ahci.ko [tom@swanbsd /usr/home/tom]$ cat /boot/loader.conf snd_emu10k1_load=3D"YES" nvidia_load=3D"YES" ahci_load=3D"YES" #console=3D"comconsole" [tom@swanbsd /usr/home/tom]$ But the device naming is unchanged: [tom@swanbsd /usr/home/tom]$ ls /dev/a* /dev/acd0 /dev/ad0s2 /dev/ad4s1 /dev/ad4s2e /dev/apm0 /dev/acd1 /dev/ad0s5 /dev/ad4s2 /dev/ad4s2f /dev/ata /dev/acpi /dev/ad0s6 /dev/ad4s2a /dev/ad4s3 /dev/atkbd0 /dev/ad0 /dev/ad0s7 /dev/ad4s2b /dev/ad4s4 /dev/audit /dev/ad0s1 /dev/ad4 /dev/ad4s2d /dev/ad4s5 From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 20:20:10 2011 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 35EAC106566B for ; Sun, 9 Jan 2011 20:20:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id CECDD8FC0C for ; Sun, 9 Jan 2011 20:20:09 +0000 (UTC) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id tWxu1f0060QuhwU57YL9fP; Sun, 09 Jan 2011 20:20:09 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta02.westchester.pa.mail.comcast.net with comcast id tYL81f00N2tehsa3NYL9ax; Sun, 09 Jan 2011 20:20:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 96AF29B427; Sun, 9 Jan 2011 12:20:07 -0800 (PST) Date: Sun, 9 Jan 2011 12:20:07 -0800 From: Jeremy Chadwick To: Tom Vijlbrief Message-ID: <20110109202007.GA48054@icarus.home.lan> References: <20110109122243.GA37530@icarus.home.lan> <20110109163027.GA42562@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Panic 8.2 PRERELEASE WRITE_DMA48 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, 09 Jan 2011 20:20:10 -0000 On Sun, Jan 09, 2011 at 09:02:16PM +0100, Tom Vijlbrief wrote: > 2011/1/9 Jeremy Chadwick : > > > > > errno 6 is "device not configured".  ad4 is on a Silicon Image > > controller (thankfully a reliable model).  Sadly AHCI (ahci.ko) isn't in > > use here; I would advocate switching to it (your device names will > > change however) and see if these errors continue (they'll appear as SCSI > > CAM errors though).  ahci_load="yes" in /boot/loader.conf should be > > enough.  smartmontools does know to talk ATA to /dev/adaX (that's not a > > typo) disks. > > > > Made that change, ahci is loaded > > [tom@swanbsd /usr/home/tom]$ kldstat > Id Refs Address Size Name > 1 16 0xc0400000 bd9998 kernel > 2 1 0xc0fda000 88a8 snd_emu10k1.ko > 3 3 0xc0fe3000 579b0 sound.ko > 4 1 0xc103b000 4df90c nvidia.ko > 5 1 0xc151b000 c108 ahci.ko > [tom@swanbsd /usr/home/tom]$ cat /boot/loader.conf > snd_emu10k1_load="YES" > nvidia_load="YES" > ahci_load="YES" > #console="comconsole" > [tom@swanbsd /usr/home/tom]$ > > But the device naming is unchanged: > > [tom@swanbsd /usr/home/tom]$ ls /dev/a* > /dev/acd0 /dev/ad0s2 /dev/ad4s1 /dev/ad4s2e /dev/apm0 > /dev/acd1 /dev/ad0s5 /dev/ad4s2 /dev/ad4s2f /dev/ata > /dev/acpi /dev/ad0s6 /dev/ad4s2a /dev/ad4s3 /dev/atkbd0 > /dev/ad0 /dev/ad0s7 /dev/ad4s2b /dev/ad4s4 /dev/audit > /dev/ad0s1 /dev/ad4 /dev/ad4s2d /dev/ad4s5 I'm sorry, I gave you incorrect advice; I'm used to Intel controllers with AHCI, not Silicon Image controllers. Silicon Image controllers have their own driver: siis(4). Please change ahci_load="yes" to siis_load="yes". -- | 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 Sun Jan 9 22:07:02 2011 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 A12AB106566C for ; Sun, 9 Jan 2011 22:07:02 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta04.eastlink.ca (mta04.eastlink.ca [24.224.136.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5C1A28FC19 for ; Sun, 9 Jan 2011 22:07:02 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from ip01.eastlink.ca ([unknown] [24.222.39.10]) by mta04.eastlink.ca (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)) with ESMTP id <0LES00DBP03PS5B0@mta04.eastlink.ca> for freebsd-stable@freebsd.org; Sun, 09 Jan 2011 18:07:01 -0400 (AST) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=mORQtGzMSGJSBwuMSvVfB0MKjPGmXehAuj88Uvu04o4= c=1 sm=1 a=tZDC3L0OECsA:10 a=8nJEP1OIZ-IA:10 a=vNmoZVmIAAAA:8 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=CYHHQ_cAAAAA:8 a=eK3PI9EcAAAA:8 a=4Fl5IS_IAAAA:8 a=GQ2g13N_AAAA:8 a=UZZ4REbu0Gdqlnn5YLQA:9 a=6Jm289b_5GFUZSlYqokA:7 a=EwuxOvjK6YE9n6d9V7bC0ltyf1cA:4 a=wPNLvfGTeEIA:10 a=ejTeHdhWsb0A:10 a=kAxpFDoqt_QA:10 a=SV7veod9ZcQA:10 a=Uf46NRAMALYA:10 a=gA6IeH5FQcgA:10 a=NWVoK91CQyQA:10 a=wQyIZ9_OPoaBy-Zk:21 a=2gFHOeQMgqgwCP6O:21 a=E/PVjAe7IbPkHCM0BPV0xg==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip01.eastlink.ca with ESMTP; Sun, 09 Jan 2011 18:07:00 -0400 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Sun, 09 Jan 2011 18:07:00 -0400 From: Chris Forgeron To: "freebsd-stable@freebsd.org" Date: Sun, 09 Jan 2011 18:06:58 -0400 Thread-topic: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks Thread-index: AcuuZybY8//wLuxhTWe205Epf6R42gB4H4aA Message-id: References: <4D1C6F90.3080206@my.gd> <4D21E679.80002@my.gd> <84882169-0461-480F-8B4C-58E794BCC8E6@my.gd> <488AE93A-97B9-4F01-AD0A-0098E4B329C3@my.gd> <20110107014249.GA3719@icarus.home.lan> In-reply-to: Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-transfer-encoding: quoted-printable Subject: RE: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 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, 09 Jan 2011 22:07:02 -0000 >> On 6 January 2011 22:26, Chris Forgeron wrote: >> > You know, these days I'm not as happy with SSD's for ZIL. I may blog a= bout some of the speed results I've been getting over the last 6mo-1yr that= I've been running them with ZFS. I think people should be using hardware R= AM drives. You can get old Gigabyte i-RAM drives with 4 gig of memory for t= he cost of a 60 gig SSD, and it will trounce the SSD for speed. >> > (I'm making an updated comment on my previous comment. Sorry for the topic = drift, but I think this is important to consider) I decided to do some tests between my Gigabyte i-RAM and OCZ Vertex 2 SSD. = I've found that they are both very similar for Random 4K-aligned Write spee= d (I was receiving around 17,000 IOPS on both, slightly faster ms access ti= me for the i-RAM). Now, if you're talking 512b aligned writes (which is wha= t ZFS is unless you've tweaked the ashift value) you're going to win with a= n i-RAM device. The OCZ Drops down to ~6000 IOPS for 512b random writes. Please note, that's on a used Vertex 2. A fresh Vertex 2 was giving me 28,0= 00 IOPS on 4k aligned writes - Faster than the i-RAM. But with more time, i= t will be slower than the i-RAM due to SSD fade.=20 I'm seriously considering trading in my ZIL SSD's for i-RAM devices, they a= re around the same price if you can still find them, and they won't degrade= like an SSD does. ZIL doesn't need much storage space. I think 12 gig (3 I= -RAM's) would do nicely, and would give me an aggregate IOPS close to a ddr= drive for under $500.=20 I did some testing with SSD Fade recently, here's the link to my blog on it= if anyone cares for more detail - http://christopher-technicalmusings.blog= spot.com/2011/01/ssd-fade-its-real-and-why-you-may-not.html I'm still using SSDs for my ZIL, but I think I'll be switching over to some= sort of RAM device shortly. I wish the i-RAM in 3.5" format had proper SAT= A power connectors on the back so it could plug into my SAS backplane like = the OCZ 3.5" SSDs do. As it stands, I'd have to rig something, as my SAN he= ad doesn't have any PCI controller slots for the other i-RAM format. -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd= .org] On Behalf Of Markiyan Kushnir Sent: Friday, January 07, 2011 8:10 AM To: Jeremy Chadwick Cc: Chris Forgeron; freebsd-stable@freebsd.org; Artem Belevich; Jean-Yves A= venard Subject: Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks 2011/1/7 Jeremy Chadwick : > On Fri, Jan 07, 2011 at 12:29:17PM +1100, Jean-Yves Avenard wrote: >> On 6 January 2011 22:26, Chris Forgeron wrote: >> > You know, these days I'm not as happy with SSD's for ZIL. I may blog a= bout some of the speed results I've been getting over the last 6mo-1yr that= I've been running them with ZFS. I think people should be using hardware R= AM drives. You can get old Gigabyte i-RAM drives with 4 gig of memory for t= he cost of a 60 gig SSD, and it will trounce the SSD for speed. >> > >> > I'd put your SSD to L2ARC (cache). >> >> Where do you find those though. >> >> I've looked and looked and all references I could find was that >> battery-powered RAM card that Sun used in their test setup, but it's >> not publicly available.. > > DDRdrive: > =A0http://www.ddrdrive.com/ > =A0http://www.engadget.com/2009/05/05/ddrdrives-ram-based-ssd-is-snappy-c= ostly/ > > ACard ANS-9010: > =A0http://techreport.com/articles.x/16255 > > GC-RAMDISK (i-RAM) products: > =A0http://us.test.giga-byte.com/Products/Storage/Default.aspx > > Be aware these products are absurdly expensive for what they offer (the > cost isn't justified), not to mention in some cases a bottleneck is > imposed by use of a SATA-150 interface. =A0I'm also not sure if all of > them offer BBU capability. > > In some respects you might be better off just buying more RAM for your > system and making md(4) memory disks that are used by L2ARC (cache). > I've mentioned this in the past (specifically "back in the days" when > the ARC piece of ZFS on FreeBSD was causing havok, and asked if one > could work around the complexity by using L2ARC with md(4) drives > instead). > Once you have got extra RAM, why not just reserve it directly to ARC (via vm.kmem_size[_max] and vfs.zfs.arc_max)? Markiyan. > I tried this, but couldn't get rc.d/mdconfig2 to do what I wanted on > startup WRT the aforementioned. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 jdc@parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountain = View, CA, USA | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 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" > _______________________________________________ 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 Mon Jan 10 03:35:37 2011 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 C032A1065670 for ; Mon, 10 Jan 2011 03:35:37 +0000 (UTC) (envelope-from labeachgeek@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7328FC15 for ; Mon, 10 Jan 2011 03:35:36 +0000 (UTC) Received: by ewy24 with SMTP id 24so8851797ewy.13 for ; Sun, 09 Jan 2011 19:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=0Vma/ZXKQfg/QHqwMzWsfKtlNU2qM8plSGKYOkLYUQU=; b=RXIkQmJr4GLBdnI3TDcAnw+XZKCpOljQ0fI8asQEz9iSOcMasfdqjUgRRa7nRkKFcV ahTXWNTYQtNuYw+/B1+aQISSqKUyN6Mn7TeL3jOeRDHGEPVOHk3P+GwcH7O4DsxB5fKt sKiWyf9rJkWhC7BtGsKYHipjJ39XtVhj7qKRE= 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=H6TGQdxoLMsGfC0Q6pn0JnVXKGMv9MuRYb0X1UPt6JMAVUVj1hthU9FQDgEYDz9rS0 o810mNb1jfjcVOdHurFxY8Pu8cS0XgtCMoPgPSOIB4cpr6e4RFxuWzKrzxpNr5tJxGYD mdx+qmy2i5D1FzYtVlbnKp0FETiP3vSecK+Sw= MIME-Version: 1.0 Received: by 10.213.104.140 with SMTP id p12mr19747073ebo.76.1294630535137; Sun, 09 Jan 2011 19:35:35 -0800 (PST) Received: by 10.213.29.19 with HTTP; Sun, 9 Jan 2011 19:35:35 -0800 (PST) Received: by 10.213.29.19 with HTTP; Sun, 9 Jan 2011 19:35:35 -0800 (PST) In-Reply-To: References: <20110105063827.GA28092@icarus.home.lan> Date: Sun, 9 Jan 2011 21:35:35 -0600 Message-ID: From: Beach Geek To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" Subject: Re: usb errors with 8 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: Mon, 10 Jan 2011 03:35:37 -0000 It's looking more like a hardware failure. I connected the phone to a friends HP Pavilion dv8xxx running FreeBSD 8 r217175 and it detected it & created da devices. I've upgraded to r217175 and still doesn't work. When I get back to lab, I'll test hardware and go from there. Thanks for the suggestions, and I'll post an update when I know more. Beach Geek On Jan 5, 2011 12:38 AM, "Jeremy Chadwick" wrote: On Tue, Jan 04, 2011 at 11:37:48PM -0600, Beach Geek wrote: > Compaq Presario 5xxx 2GHz > FreeBSD 8 ... I would start by reviewing the commits for RELENG_8 between the two timeframes and try to narrow down which commit may have caused your problem. http://www.freshbsd.org/?branch=RELENG_8&project=freebsd -- | 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 Jan 10 05:10:14 2011 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 92D20106566C for ; Mon, 10 Jan 2011 05:10:14 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3B94E8FC14 for ; Mon, 10 Jan 2011 05:10:13 +0000 (UTC) Received: by qyk8 with SMTP id 8so981564qyk.13 for ; Sun, 09 Jan 2011 21:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0iagRDZ6pGYSrjpOndGZbMF4Yrl+FA8wcFB7GxoJKwo=; b=D2MaCeSCKt37/5VShnHT9asnLj+vxUM1q+85NwIWnafnnQwBxoF3xSnipoyeHn1x9F 1efeNxxp8mo2x9PgDRSA5qAbj30FI1X2+FhJZ8/eKwB3AJBOltx4F/jj27mWvbORkwAP GqIf0RhyShuOevNj5oY4os9seOruKqa6zv0bA= 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:content-type :content-transfer-encoding; b=eWIgyGd8g9qy+H8ciGt403r/VwNC+eRZcXgDDpi9LquNgPU+sEyuCQKazpQuYoqLVV nHj/HoYLUfI6c7zrlg26N4fOr/P4AuT7cZngn8KYfy+d25SZBZkaRG0+jaYB9wctpK9c Oyo1pnDwZB3zuYPuwF0pnOLBwrdXepxdNTrZY= MIME-Version: 1.0 Received: by 10.229.90.196 with SMTP id j4mr24077970qcm.144.1294636213285; Sun, 09 Jan 2011 21:10:13 -0800 (PST) Sender: tvijlbrief@gmail.com Received: by 10.229.50.209 with HTTP; Sun, 9 Jan 2011 21:10:13 -0800 (PST) In-Reply-To: References: <20110109122243.GA37530@icarus.home.lan> <20110109163027.GA42562@icarus.home.lan> <20110109202007.GA48054@icarus.home.lan> Date: Mon, 10 Jan 2011 06:10:13 +0100 X-Google-Sender-Auth: GBj2dfczwHw19MVM4rJB4j5MxBA Message-ID: From: Tom Vijlbrief To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Panic 8.2 PRERELEASE WRITE_DMA48 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, 10 Jan 2011 05:10:14 -0000 2011/1/9 Jeremy Chadwick : > > I'm sorry, I gave you incorrect advice; I'm used to Intel controllers > with AHCI, not Silicon Image controllers. =A0Silicon Image controllers > have their own driver: siis(4). > > Please change ahci_load=3D"yes" to siis_load=3D"yes". > Tried it, but no change, the siis driver does not support the 3512 according to its man page, so I'm probably stuck with the default driver. Did the full disk scan, "smartctl -t select,0-max /dev/ad4". It completed this night, no errors, so the disk is fine. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 06:13:58 2011 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 73D50106564A for ; Mon, 10 Jan 2011 06:13:58 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 207448FC16 for ; Mon, 10 Jan 2011 06:13:57 +0000 (UTC) Received: by qwj9 with SMTP id 9so18698818qwj.13 for ; Sun, 09 Jan 2011 22:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=hprUh5WtZ2G5e0DDoWxB2UwFhF5KhwP88Nfv5POZjGM=; b=uHJs4ysx5S+42Rj/fmHoqIYuav8NwwbqfLtn26CtqoANEZWk9oYWjFWK0cCLxZtab4 poa+GIE5i8GnMAe2lA1wa6YJW9opTquS/7uiSIitaB2OBjVt3Dr3MhzTVRvdOq5/5muS bUutos3ZuXr8Vkg+C+ExBnQw/mUi/XR47YBOI= 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=CJtfNdH6XbSStISzsWrHgveOfGFBIdDbVww92fI+vfN1Ty5OYINznxrpwGwjKUXzeV uqUfU/DGwgIdadbrUX4RHi8wt45SCAC63MuvxZmGsXv90+/S98S40xz4hq976COSUyMg ttprwlai3DHdqILFW/w6i+ZwBcAwIQ7/CNA2M= MIME-Version: 1.0 Received: by 10.229.250.135 with SMTP id mo7mr24771186qcb.30.1294640037270; Sun, 09 Jan 2011 22:13:57 -0800 (PST) Sender: tvijlbrief@gmail.com Received: by 10.229.50.209 with HTTP; Sun, 9 Jan 2011 22:13:57 -0800 (PST) In-Reply-To: <20110109163027.GA42562@icarus.home.lan> References: <20110109122243.GA37530@icarus.home.lan> <20110109163027.GA42562@icarus.home.lan> Date: Mon, 10 Jan 2011 07:13:57 +0100 X-Google-Sender-Auth: ntptgSjCl-xWVN0qOCxKWGqXp0g Message-ID: From: Tom Vijlbrief To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Panic 8.2 PRERELEASE WRITE_DMA48 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, 10 Jan 2011 06:13:58 -0000 2011/1/9 Jeremy Chadwick : > > Not to get off topic, but what is causing this? =A0It looks like you have > a cron job or something very aggressive doing a "smartctl -t short > /dev/ad4" or equivalent. =A0If you have such, please disable this > immediately. =A0You shouldn't be doing SMART tests with such regularity; > it accomplishes absolutely nothing, especially the "short" tests. =A0Let > the drive operate normally, otherwise run smartd and watch logs instead. > I have this default entry (from the author of that file) in smartd.conf and enabled it on many machines over the years. Is it a bad practice? # First (primary) ATA/IDE hard disk. Monitor all attributes, enable # automatic online data collection, automatic Attribute autosave, and # start a short self-test every day between 2-3am, and a long self test # Saturdays between 3-4am. /dev/hda -a -o on -S on -s (S/../.././02|L/../../6/03) Thanks for all your feedback From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 06:51:17 2011 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 8F51A106566B for ; Mon, 10 Jan 2011 06:51:17 +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 6B2358FC0A for ; Mon, 10 Jan 2011 06:51:17 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta06.emeryville.ca.mail.comcast.net with comcast id tXXa1f0051HpZEsA6irAMq; Mon, 10 Jan 2011 06:51:10 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta14.emeryville.ca.mail.comcast.net with comcast id tir91f0022tehsa8air9ZH; Mon, 10 Jan 2011 06:51:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 23D3A9B427; Sun, 9 Jan 2011 22:51:09 -0800 (PST) Date: Sun, 9 Jan 2011 22:51:09 -0800 From: Jeremy Chadwick To: Tom Vijlbrief Message-ID: <20110110065109.GA61075@icarus.home.lan> References: <20110109122243.GA37530@icarus.home.lan> <20110109163027.GA42562@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Panic 8.2 PRERELEASE WRITE_DMA48 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, 10 Jan 2011 06:51:17 -0000 On Mon, Jan 10, 2011 at 07:13:57AM +0100, Tom Vijlbrief wrote: > 2011/1/9 Jeremy Chadwick : > > > > > Not to get off topic, but what is causing this?  It looks like you have > > a cron job or something very aggressive doing a "smartctl -t short > > /dev/ad4" or equivalent.  If you have such, please disable this > > immediately.  You shouldn't be doing SMART tests with such regularity; > > it accomplishes absolutely nothing, especially the "short" tests.  Let > > the drive operate normally, otherwise run smartd and watch logs instead. > > > > I have this default entry (from the author of that file) in > smartd.conf and enabled it on many machines over the years. > Is it a bad practice? > > # First (primary) ATA/IDE hard disk. Monitor all attributes, enable > # automatic online data collection, automatic Attribute autosave, and > # start a short self-test every day between 2-3am, and a long self test > # Saturdays between 3-4am. > /dev/hda -a -o on -S on -s (S/../.././02|L/../../6/03) I'll have to talk to Bruce Allen about that. Those entries in smartd.conf are pretty old (meaning they've existed for a very long time, and chances are Bruce hasn't gone back to revamp them or reconsider the logic/justification behind them). I'm an opponent of running SMART tests automatically, given what some do to drives. It's important to remember that most SMART tests can be done while the drive is in operation, and some of theses tests stress the drive, which could potentially cause timeouts or other I/O anomalies (data loss is unlikely, but odd errors may occur; it all depends on the firmware). This is especially important WRT "long" tests. For example, on newer 2TB Western Digital Caviar Black drives, a long test does something that I haven't heard (yes, heard) any other drive do -- it emits a noise that's almost identical to that of a head crash. It could be scanning a very specific region of LBAs (possibly out-of-range sectors, e.g. spares) repetitively, but it sounds nothing like a selective LBA scan. Honestly it does sound like a head crash. Is this something you'd really want to be running every 7 days? I've always advocated that people run smartd only if they want to monitor attributes -- which ultimately are the most important things to keep an eye on anyway. It's even more important to know how to read them. :-) 90% of drives out there update their attributes at set intervals or when the SMART READ DATA command is encountered. And honestly I've never seen a SMART short test do anything useful, on any drive I've used (SATA or SCSI; WD, Seagate, Maxtor, Hitachi, Fujitsu). Long test are different in this regard. I'm fully aware that the terms "short" and "long" are vague in nature and don't really tell a person what the drive is doing behind the scenes. Sadly that's the nature of SMART; they're just tests that are defined on a per-vendor (or per-disk-model!) basis. But as my 2nd paragraph above implies, the behaviour is not consistent. So when people ask me "how do I monitor my disks reliably with SMART then?", I tell them to either do it by hand (which is what I do), or run smartd(8) and keep an eye on their logs. This requires some tuning, and familiarity with what attribute means what, and again on a per-drive or per-vendor basis. It's great that there's no actual standard for these, isn't 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 Mon Jan 10 08:52:38 2011 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 0BDD8106564A for ; Mon, 10 Jan 2011 08:52:38 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id B91118FC0A for ; Mon, 10 Jan 2011 08:52:36 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PcDUQ-00016i-NB; Mon, 10 Jan 2011 10:52:34 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Daniel Feenberg In-reply-to: References: Comments: In-reply-to Daniel Feenberg message dated "Sun, 09 Jan 2011 10:32:48 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jan 2011 10:52:34 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: classes and kernel_cookie was Re: Specifying root mount options on diskless boot. 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, 10 Jan 2011 08:52:38 -0000 ... > I note that the response to your message from "danny" offers the ability > to pass arguments to the nfs mount command, but also seems to offer a fix > for the fact that "classes" are not supported under PXE: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/90368 > > I hope "danny" will offer a patch to mainline code - it would be an > important improvement (and already promised in the documentation). ... I'm willing to try and add the missing pieces, but I need some better explanantion as to what they are, for example, I have no clue what the kernel_cookie is used for, nor what the ${class} is all about. BTW, it would be kind if the line in the pxeboot(8): As PXE is still in its infancy ... can be changed :-) "danny" From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 09:09:30 2011 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 5E25A106566B; Mon, 10 Jan 2011 09:09:30 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mx2.wheel.pl (grom.wheel.pl [91.121.70.66]) by mx1.freebsd.org (Postfix) with ESMTP id CF6CB8FC13; Mon, 10 Jan 2011 09:09:29 +0000 (UTC) Received: from mx1.whl (wheel-vpn [9.1.1.6]) by mx2.wheel.pl (Postfix) with ESMTP id BFFE32B2; Mon, 10 Jan 2011 10:02:11 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) by mx1.whl (Postfix) with ESMTPSA id 043E22EC; Mon, 10 Jan 2011 10:00:52 +0100 (CET) Date: Mon, 10 Jan 2011 10:02:05 +0100 From: Pawel Jakub Dawidek To: Attila Nagy Message-ID: <20110110090205.GB1744@garage.freebsd.pl> References: <4D0A09AF.3040005@FreeBSD.org> <4D297943.1040507@fsn.hu> <4D29A0C7.8050002@fsn.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline In-Reply-To: <4D29A0C7.8050002@fsn.hu> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, Martin Matuska Subject: Re: New ZFSv28 patchset for 8-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: Mon, 10 Jan 2011 09:09:30 -0000 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 09, 2011 at 12:49:27PM +0100, Attila Nagy wrote: > No, it's not related. One of the disks in the RAIDZ2 pool went bad: > (da4:arcmsr0:0:4:0): READ(6). CDB: 8 0 2 10 10 0 > (da4:arcmsr0:0:4:0): CAM status: SCSI Status Error > (da4:arcmsr0:0:4:0): SCSI status: Check Condition > (da4:arcmsr0:0:4:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read= =20 > error) > and it seems it froze the whole zpool. Removing the disk by hand solved= =20 > the problem. > I've seen this previously on other machines with ciss. > I wonder why ZFS didn't throw it out of the pool. Such hangs happen when I/O never returns. ZFS doesn't timeout I/O requests on its own, this is driver's responsibility. It is still strange that the driver didn't pass I/O error up to ZFS or it might as well be ZFS bug, but I don't think so. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk0qywwACgkQForvXbEpPzSojwCffanIRz1LN1MTmc/Jf3qur4cG M70An36Qn84voWMQ8pBF3Cc4KPDU13gw =o2Bn -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 09:14:30 2011 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 A8A14106564A; Mon, 10 Jan 2011 09:14:30 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mx2.wheel.pl (grom.wheel.pl [91.121.70.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2E02A8FC13; Mon, 10 Jan 2011 09:14:29 +0000 (UTC) Received: from mx1.whl (wheel-vpn [9.1.1.6]) by mx2.wheel.pl (Postfix) with ESMTP id 5BB812AF; Mon, 10 Jan 2011 09:58:02 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) by mx1.whl (Postfix) with ESMTPSA id 7B91B2EA; Mon, 10 Jan 2011 09:56:42 +0100 (CET) Date: Mon, 10 Jan 2011 09:57:56 +0100 From: Pawel Jakub Dawidek To: Attila Nagy Message-ID: <20110110085756.GA1744@garage.freebsd.pl> References: <4D0A09AF.3040005@FreeBSD.org> <4D1F7008.3050506@fsn.hu> <4D29A198.4070107@fsn.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <4D29A198.4070107@fsn.hu> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Artem Belevich Subject: Re: New ZFSv28 patchset for 8-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: Mon, 10 Jan 2011 09:14:30 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 09, 2011 at 12:52:56PM +0100, Attila Nagy wrote: [...] > I've finally found the time to read the v28 patch and figured out the=20 > problem: vfs.zfs.l2arc_noprefetch was changed to 1, so it doesn't use=20 > the prefetched data on the L2ARC devices. > This is a major hit in my case. Enabling this again restored the=20 > previous hit rates and lowered the load on the hard disks significantly. Well, not storing prefetched data on L2ARC vdevs is the default is Solaris. For some reason it was changed by kmacy@ in r205231. Not sure why and we can't ask him now, I'm afraid. I just sent an e-mail to Brendan Gregg from Oracle who originally implemented L2ARC in ZFS why this is turned off by default. Once I get answer we can think about turning it on again. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk0qyhMACgkQForvXbEpPzT7qACeM1nQ4x8dyLpt81dkOLtwBeCn H4wAn3qFwe2SESI5WQ3JMPjreqx5krnb =Knhp -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 11:58:21 2011 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 8AD321065674 for ; Mon, 10 Jan 2011 11:58:21 +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 E1C428FC1A for ; Mon, 10 Jan 2011 11:58:20 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 6E9A519E031 for ; Mon, 10 Jan 2011 12:58:19 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id A663519E036 for ; Mon, 10 Jan 2011 12:58:09 +0100 (CET) Message-ID: <4D2AF451.7060609@quip.cz> Date: Mon, 10 Jan 2011 12:58:09 +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.16) Gecko/20101123 SeaMonkey/2.0.11 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: 8.2-BETA1 / 8.2-RC1 ACPI and other errors in dmesg after upgrade from 7.2 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, 10 Jan 2011 11:58:21 -0000 Hi, I have a few machines Sun Fire X2100 M2. I upgraded from FreeBSD 7.2 to 8.2-BETA1 and 8.2-RC1 and now I see following errors in dmesg: acpi0: on motherboard ACPI Error: Invalid type (Alias) for target of Scope operator [CPU1] (Cannot override) (20101013/dswload-324) ACPI Exception: AE_AML_OPERAND_TYPE, During name lookup/catalog (20101013/psloop-326) . acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed . . uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 And then in /var/log/messages pid 3802 (sshd) is using legacy pty devices - not logging anymore pid 38796 (try), uid 0: exited on signal 10 (core dumped) Except these messages, system and services are running fine. So this is just a report of something suspected. Full dmesg: 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.2-RC1 #0: Wed Dec 22 17:34:20 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual-Core AMD Opteron(tm) Processor 1210 (1811.10-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Family = f Model = 43 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 4294967296 (4096 MB) avail memory = 4114534400 (3923 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 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard ACPI Error: Invalid type (Alias) for target of Scope operator [CPU1] (Cannot override) (20101013/dswload-324) ACPI Exception: AE_AML_OPERAND_TYPE, During name lookup/catalog (20101013/psloop-326) acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfcffb000-0xfcffbfff irq 21 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfcffac00-0xfcffacff irq 22 at device 2.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 4.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem 0xfcff9000-0xfcff9fff irq 23 at device 5.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib1: at device 6.0 on pci0 pci1: on pcib1 vgapci0: port 0xec00-0xec7f mem 0xfd000000-0xfd7fffff,0xfdee0000-0xfdefffff irq 16 at device 5.0 on pci1 nfe0: port 0xc880-0xc887 mem 0xfcff8000-0xfcff8fff,0xfcffa800-0xfcffa8ff,0xfcffa400-0xfcffa40f irq 20 at device 8.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 2 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow nfe0: Ethernet address: 00:1b:24:bd:e2:0f nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xc800-0xc807 mem 0xfcff7000-0xfcff7fff,0xfcffa000-0xfcffa0ff,0xfcff6c00-0xfcff6c0f irq 21 at device 9.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 3 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow nfe1: Ethernet address: 00:1b:24:bd:e2:10 nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib2: at device 10.0 on pci0 pci2: on pcib2 pcib3: at device 11.0 on pci0 pci3: on pcib3 pcib4: at device 12.0 on pci0 pci4: on pcib4 pcib5: at device 13.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 bge0: mem 0xfdff0000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 17 at device 4.0 on pci6 bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X miibus2: on bge0 brgphy0: PHY 1 on miibus2 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:1b:24:bd:e2:0d bge0: [ITHREAD] bge1: mem 0xfdfc0000-0xfdfcffff,0xfdfb0000-0xfdfbffff irq 18 at device 4.1 on pci6 bge1: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X miibus3: on bge1 brgphy1: PHY 1 on miibus3 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:1b:24:bd:e2:0e bge1: [ITHREAD] pcib7: at device 14.0 on pci0 pci7: on pcib7 pcib8: at device 15.0 on pci0 pci8: on pcib8 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] orm0: at iomem 0xc0000-0xc7fff,0xcb000-0xcc7ff,0xcc800-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: CGA <16 virtual consoles, flags=0x300> vga0: at port 0x3d0-0x3db iomem 0xb8000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range powernow0: on cpu0 device_attach: powernow0 attach returned 6 powernow1: on cpu1 device_attach: powernow1 attach returned 6 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 476940MB at ata2-master UDMA100 SATA 3Gb/s ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ad6: 476940MB at ata3-master UDMA100 SATA 3Gb/s SMP: AP CPU #1 Launched! GEOM_MIRROR: Device mirror/gms1 launched (2/2). Root mount waiting for: usbus1 usbus0 uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 uhub1: 8 ports with 8 removable, self powered Root mount waiting for: usbus1 ugen0.2: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 Trying to mount root from ufs:/dev/mirror/gms1a ZFS filesystem version 4 ZFS storage pool version 15 Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 12:21:03 2011 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 1B8BF106564A for ; Mon, 10 Jan 2011 12:21:03 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id B8BD88FC08 for ; Mon, 10 Jan 2011 12:21:01 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id BBA8B45CA0; Mon, 10 Jan 2011 12:57:01 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id B645E45685; Mon, 10 Jan 2011 12:56:56 +0100 (CET) Date: Mon, 10 Jan 2011 12:56:51 +0100 From: Pawel Jakub Dawidek To: Krzysztof Dajka Message-ID: <20110110115651.GH1744@garage.freebsd.pl> References: <4D0A09AF.3040005@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U3BNvdZEnlJXqmh+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Martin Matuska Subject: Re: New ZFSv28 patchset for 8-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: Mon, 10 Jan 2011 12:21:03 -0000 --U3BNvdZEnlJXqmh+ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 18, 2010 at 10:00:11AM +0100, Krzysztof Dajka wrote: > Hi, > I applied patch against evening 2010-12-16 STABLE. I did what Martin aske= d: >=20 > On Thu, Dec 16, 2010 at 1:44 PM, Martin Matuska wrote: > > =A0 =A0# cd /usr/src > > =A0 =A0# fetch > > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.= patch.xz > > =A0 =A0# xz -d stable-8-zfsv28-20101215.patch.xz > > =A0 =A0# patch -E -p0 < stable-8-zfsv28-20101215.patch > > =A0 =A0# rm sys/cddl/compat/opensolaris/sys/sysmacros.h > > > Patch applied cleanly. >=20 > #make buildworld > #make buildkernel > #make installkernel > Reboot into single user mode. > #mergemaster -p > #make installworld > #mergemaster > Reboot. >=20 >=20 > Rebooting with old world and new kernel went fine. But after reboot > with new world I got: > ZFS: zfs_alloc()/zfs_free() mismatch > Just before loading kernel modules, after that my system hangs. Could you tell me more about you pool configuration? 'zpool status' output might be helpful. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --U3BNvdZEnlJXqmh+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk0q9AMACgkQForvXbEpPzTyLgCfRI+ljotibqDlGghSUXzlqggY 2r0AoIzlrlGkJP4Toc41fGOnMJ97uYby =5RaX -----END PGP SIGNATURE----- --U3BNvdZEnlJXqmh+-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 12:56:24 2011 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 07CF11065696 for ; Mon, 10 Jan 2011 12:56: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 ABF468FC14 for ; Mon, 10 Jan 2011 12:56:22 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PcHIL-0005Mh-L4 for freebsd-stable@freebsd.org; Mon, 10 Jan 2011 13:56:21 +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, 10 Jan 2011 13:56:21 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Jan 2011 13:56:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 10 Jan 2011 13:56:09 +0100 Lines: 9 Message-ID: References: <204344488.20110108214457@serebryakov.spb.ru> <20110108190232.GU12599@deviant.kiev.zoral.com.ua> <1792026896.20110108222909@serebryakov.spb.ru> <20110108195613.GW12599@deviant.kiev.zoral.com.ua> <1544327450.20110108231021@serebryakov.spb.ru> <20110108202028.GY12599@deviant.kiev.zoral.com.ua> <959936032.20110109010601@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.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.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <959936032.20110109010601@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Subject: Re: 8.2-PRERELEASE: live deadlock, almost all processes in "pfault" state 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, 10 Jan 2011 12:56:24 -0000 On 08/01/2011 23:06, Lev Serebryakov wrote: > > I need to look how raid3 and vinum/raid5 lives with that situation. One other standard solution is to spawn a thread and offload the job to that thread, instead of within GEOM start(). This is what most current complex GEOM classes to. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 13:00:20 2011 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 A3A331065696 for ; Mon, 10 Jan 2011 13:00:20 +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 5161E8FC14 for ; Mon, 10 Jan 2011 13:00:09 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PcHLw-000767-D4 for freebsd-stable@freebsd.org; Mon, 10 Jan 2011 14:00:04 +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, 10 Jan 2011 14:00:04 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Jan 2011 14:00:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 10 Jan 2011 13:58:34 +0100 Lines: 21 Message-ID: References: <204344488.20110108214457@serebryakov.spb.ru> <20110108190232.GU12599@deviant.kiev.zoral.com.ua> <427356441.20110108224219@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.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.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <427356441.20110108224219@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Subject: Re: 8.2-PRERELEASE: live deadlock, almost all processes in "pfault" state 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, 10 Jan 2011 13:00:20 -0000 On 08/01/2011 20:42, Lev Serebryakov wrote: > Hello, Kostik. > You wrote 8 ÑÐ½Ð²Ð°Ñ€Ñ 2011 г., 22:02:32: > > >> If I am guessing right, this creature has a classic deadlock when >> bio processing requires memory allocation. It seems that tid 100079 >> is sleeping not even due to the free page shortage, but due to address >> space exhaustion. As result, read/write requests are stalled. > I want to say, that ZFS, for example, could allocate much more > memory, and, yes, it had problems on i386 with this, but not on amd64, > AFAIK... > > So, I'm (geom_radi5) doing something wrong... geom_raid5 (I'm assuming you're talking about the module that was written some time ago by an external developer) does serveral things wrong - that's why it wasn't included in FreeBSD. IIRC, one of those things is that it aggressively caches writes below the file system layer, which is a no-no. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 16:51:08 2011 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 656AC10656C7 for ; Mon, 10 Jan 2011 16:51:08 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (unknown [IPv6:2001:418:3fd::3]) by mx1.freebsd.org (Postfix) with ESMTP id 092858FC15 for ; Mon, 10 Jan 2011 16:51:07 +0000 (UTC) Received: from m5p.com (wonderland.m5p.com [IPv6:2001:418:3fd::19]) by mailhost.m5p.com (8.14.3/8.14.3) with ESMTP id p0AGp1Kq028688 for ; Mon, 10 Jan 2011 11:51:07 -0500 (EST) (envelope-from george@m5p.com) Received: (from george@localhost) by m5p.com (8.14.4/8.13.7/Submit) id p0AGp12d001683; Mon, 10 Jan 2011 11:51:01 -0500 (EST) Date: Mon, 10 Jan 2011 11:51:01 -0500 (EST) Message-Id: <201101101651.p0AGp12d001683@m5p.com> From: george+freebsd@m5p.com To: freebsd-stable@freebsd.org In-Reply-To: <70510313.18875.1294600012817.JavaMail.root@erie.cs.uoguelph.ca> X-Spam-Score: -1.5 () BAYES_00 X-Scanned-By: MIMEDefang 2.67 on IPv6:2001:418:3fd::f7 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Mon, 10 Jan 2011 11:51:07 -0500 (EST) Subject: Re: NFS performance 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, 10 Jan 2011 16:51:08 -0000 > > So, did the patch get rid of the 1min + stalls you reported earlier? > Yes. The stalls (and the "server not responding" log messages are gone. Thanks! -- George From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 17:23:48 2011 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 E00DC106567A; Mon, 10 Jan 2011 17:23:48 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id CD4E38FC18; Mon, 10 Jan 2011 17:23:47 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 4624270614E; Mon, 10 Jan 2011 18:23:45 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 15.8155] X-CRM114-CacheID: sfid-20110110_18234_6D48A357 X-CRM114-Status: Good ( pR: 15.8155 ) X-Spambayes-Classification: ham; 0.00 Message-ID: <4D2B40A0.20008@fsn.hu> Date: Mon, 10 Jan 2011 18:23:44 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4D0A09AF.3040005@FreeBSD.org> <4D297943.1040507@fsn.hu> <4D29A0C7.8050002@fsn.hu> <20110110090205.GB1744@garage.freebsd.pl> In-Reply-To: <20110110090205.GB1744@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, Martin Matuska Subject: Re: New ZFSv28 patchset for 8-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: Mon, 10 Jan 2011 17:23:49 -0000 On 01/10/2011 10:02 AM, Pawel Jakub Dawidek wrote: > On Sun, Jan 09, 2011 at 12:49:27PM +0100, Attila Nagy wrote: >> No, it's not related. One of the disks in the RAIDZ2 pool went bad: >> (da4:arcmsr0:0:4:0): READ(6). CDB: 8 0 2 10 10 0 >> (da4:arcmsr0:0:4:0): CAM status: SCSI Status Error >> (da4:arcmsr0:0:4:0): SCSI status: Check Condition >> (da4:arcmsr0:0:4:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read >> error) >> and it seems it froze the whole zpool. Removing the disk by hand solved >> the problem. >> I've seen this previously on other machines with ciss. >> I wonder why ZFS didn't throw it out of the pool. > Such hangs happen when I/O never returns. ZFS doesn't timeout I/O > requests on its own, this is driver's responsibility. It is still > strange that the driver didn't pass I/O error up to ZFS or it might as > well be ZFS bug, but I don't think so. > Indeed, it may to be a controller/driver bug. The newly released (last december) firmware says something about a similar problem. I've upgraded, we'll see whether it will help next time a drive goes awry. I've only seen these errors in dmesg, not in zpool status, there everything was clear (all zeroes). BTW, I've swapped those bad drives (da4, which reported the above errors, and da16, which didn't reported anything to the OS, it was just plain bad according to the controller firmware -and after its deletion, I could offline da4, so it seems it's the real cause, see my previous e-mail), and zpool replaced first da4, but after some seconds of thinking all IO on all disks deceased. After waiting some minutes, it was still the same, so I've rebooted. Then I noticed that a scrub is going on, so I stopped it. Then the zpool replace da4 went fine, it started to resilver the disk. But another zpool replace (for da16) causes the same error: some seconds of IO, then nothing and it stuck in that. Has anybody tried replacing two drives simultaneously with the zfs v28 patch? (this is a stripe of two raidz2s and da4 and da16 are in different raidz2) From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 17:30:42 2011 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 71AC21065672; Mon, 10 Jan 2011 17:30:42 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id BCB428FC12; Mon, 10 Jan 2011 17:30:41 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 2717C7061F7; Mon, 10 Jan 2011 18:30:40 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 14.1618] X-CRM114-CacheID: sfid-20110110_18303_780BD314 X-CRM114-Status: Good ( pR: 14.1618 ) X-Spambayes-Classification: ham; 0.00 Message-ID: <4D2B423F.2000403@fsn.hu> Date: Mon, 10 Jan 2011 18:30:39 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4D0A09AF.3040005@FreeBSD.org> <4D1F7008.3050506@fsn.hu> <4D29A198.4070107@fsn.hu> <20110110085756.GA1744@garage.freebsd.pl> In-Reply-To: <20110110085756.GA1744@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Artem Belevich Subject: Re: New ZFSv28 patchset for 8-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: Mon, 10 Jan 2011 17:30:42 -0000 On 01/10/2011 09:57 AM, Pawel Jakub Dawidek wrote: > On Sun, Jan 09, 2011 at 12:52:56PM +0100, Attila Nagy wrote: > [...] >> I've finally found the time to read the v28 patch and figured out the >> problem: vfs.zfs.l2arc_noprefetch was changed to 1, so it doesn't use >> the prefetched data on the L2ARC devices. >> This is a major hit in my case. Enabling this again restored the >> previous hit rates and lowered the load on the hard disks significantly. > Well, not storing prefetched data on L2ARC vdevs is the default is > Solaris. For some reason it was changed by kmacy@ in r205231. Not sure > why and we can't ask him now, I'm afraid. I just sent an e-mail to What happened to him? > Brendan Gregg from Oracle who originally implemented L2ARC in ZFS why > this is turned off by default. Once I get answer we can think about > turning it on again. > I think it makes some sense as a stupid form of preferring random IO in the L2ARC instead of sequential. But if I rely on auto tuning and let prefetch enabled, even a busy mailserver will prefetch a lot of blocks and I think that's a fine example of random IO (also, it makes the system unusable, but that's another story). Having this choice is good, and in this case enabling this makes sense for me. I don't know any reasons about why you wouldn't use all of your L2ARC space (apart from sparing the quickly wearing out flash space and move disk heads instead), but I'm sure Brendan made this choice with a good reason. If you get an answer, please tell us. :) Thanks, From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 17:48:35 2011 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 AB6A41065698 for ; Mon, 10 Jan 2011 17:48:35 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8C88FC15 for ; Mon, 10 Jan 2011 17:48:35 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out0.tiscali.nl with esmtp (Exim) (envelope-from ) id 1PcLr8-0003Z9-5A; Mon, 10 Jan 2011 18:48:34 +0100 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id DA23DA1A7; Mon, 10 Jan 2011 18:48:26 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Rick Macklem" , "Kostik Belousov" References: <1542786719.258389.1294429045433.JavaMail.root@erie.cs.uoguelph.ca> <20110107195257.GF12599@deviant.kiev.zoral.com.ua> Date: Mon, 10 Jan 2011 18:48:26 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <20110107195257.GF12599@deviant.kiev.zoral.com.ua> User-Agent: Opera Mail/11.00 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Hang in VOP_LOCK1_APV on 8-STABLE with NFS. 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, 10 Jan 2011 17:48:35 -0000 On Fri, 07 Jan 2011 20:52:57 +0100, Kostik Belousov = =20 wrote: > On Fri, Jan 07, 2011 at 02:37:25PM -0500, Rick Macklem wrote: >> > Hi, >> > >> > OpenOffice hangs on NFS when I try to save a file or even when I try >> > to >> > open the save dialog in this case. >> > >> > >> > $ 17:25:35 ronald@ronald [~] >> > procstat -kk 85575 >> > PID TID COMM TDNAME KSTACK >> > 85575 100322 soffice.bin initial thread mi_switch+0x176 >> > sleepq_wait+0x3b __lockmgr_args+0x655 vop_stdlock+0x39 >> > VOP_LOCK1_APV+0x46 >> > _vn_lock+0x44 vget+0x67 vfs_hash_get+0xeb nfs_nget+0xa8 >> > nfs_lookup+0x65e >> > VOP_LOOKUP_APV+0x40 lookup+0x48a namei+0x518 kern_statat_vnhook+0x82 >> > kern_statat+0x15 lstat+0x22 syscallenter+0x186 syscall+0x40 >> > 85575 100502 soffice.bin - mi_switch+0x176 >> > sleepq_catch_signals+0x309 sleepq_timedwait_sig+0x12 _sleep+0x1a0 >> > do_cv_wait+0x639 __umtx_op_cv_wait+0x51 syscallenter+0x186 >> > syscall+0x40 >> > Xfast_syscall+0xe2 >> > 85575 100576 soffice.bin - mi_switch+0x176 >> > sleepq_catch_signals+0x309 sleepq_timedwait_sig+0x12 _sleep+0x1a0 >> > do_cv_wait+0x639 __umtx_op_cv_wait+0x51 syscallenter+0x186 >> > syscall+0x40 >> > Xfast_syscall+0xe2 >> > 85575 100577 soffice.bin - mi_switch+0x176 >> > sleepq_catch_signals+0x309 sleepq_wait_sig+0xc _sleep+0x25d >> > kern_accept+0x19c accept+0xfe syscallenter+0x186 syscall+0x40 >> > Xfast_syscall+0xe2 >> > 85575 100578 soffice.bin - mi_switch+0x176 >> > sleepq_catch_signals+0x309 sleepq_wait_sig+0xc _cv_wait_sig+0x10e >> > seltdwait+0xed poll+0x457 syscallenter+0x186 syscall+0x40 >> > Xfast_syscall+0xe2 >> > 85575 100579 soffice.bin - mi_switch+0x176 >> > sleepq_catch_signals+0x309 sleepq_timedwait_sig+0x12 >> > _cv_timedwait_sig+0x11d seltdwait+0x79 poll+0x457 syscallenter+0x186 >> > syscall+0x40 Xfast_syscall+0xe2 >> > >> > $ 17:25:35 ronald@ronald [~] >> > uname -a >> > FreeBSD ronald.office.base.nl 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE >> > #6: >> > Mon Dec 27 23:49:30 CET 2010 >> > root@ronald.office.base.nl:/usr/obj/usr/src/sys/GENERIC amd64 >> > >> I think all the above tells us is that the thread is waiting for >> a vnode lock. The question then becomes "what is holding a lock >> on that vnode and why?". >> >> > It is not possible to exit or kill soffice.bin. I had a slighty >> > different >> > procstat stack before, but that was fixed a couple of days ago. >> >> Yea, it will be in an uniterruptible sleep when waiting for a vnode =20 >> lock. >> >> > Any thoughts? Enabling local locks in NFS doesn't fix it. >> >> Here's some things you could try: >> 1 - apply the attached patch. It fixes a known problem w.r.t. the >> client side of the krpc. Not likely to fix this, but I can hope:-) > 1a - Look around of other processes in the uninterruptible sleep state, > quite possible, one of them also owns the lock the openoffice is waitin= g > for. Also see > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke= rneldebug-deadlocks.html > > Of the particular interest are the witness output and backtraces for > all threads that are reported by witness as owning the vnode locks. > >> 2 - If #1 doesn't fix the problem: >> - before making it hang, start capturing packets via: >> # tcpdump -s 0 -w xxx host server >> - then make it hang, kill the above and >> # procstat -ka >> # ps axHlww >> and capture the output of both of these. Hopefully these 2 command= s >> will indicate what is holding the vnode lock and maybe, why. The >> "xxx" file can be looked at in wireshark to see what/if any NFS >> traffic is happening. >> If you aren't comfortable looking at the above, you can email them >> to me and I'll take a stab at them someday. >> 3 - Try the experimental client to see if it behaves differently. The >> mount command is: >> # mount -t newnfs -o nfsv3, =20 >> server:/path /mntpath >> (This might ideantify if the regular client has an infrequently =20 >> executed code >> path that forgets to unlock the vnode, since it uses a somewhat =20 >> different RPC >> layer. The buffer cache handling etc are almost the same, but the= =20 >> RPC stuff is >> fairly different.) >> >> > The nfs server is an up-to-date Linux Debian 5 with kernel 2.6.26. >> > >> I'm afraid I can't blame Linux (at least not until we have more info;-= ). >> >> > If more info is needed. I can easily reproduce this. >> >> See above #2. >> >> Good luck with it and let us know how it goes, rick Hi, I have got the first steps set up. No solution yet. 1. With the patch OpenOffice opens my homedir (yeah!), but it gives an I/= O =20 error when saving a file and everything hangs after that. 2. I have dumps and stuff. I will mail some links in private e-mail. 3. Didn't work. It mount, but ls -l /home gives "Operation not permitted"= . I didn't see other processes in uninterruptable state. But maybe you guys= =20 see more than I do. If you don't see anything in wireshark I will try WITNESS and friends =20 later this week. Already 2 hours busy with this during work hours. Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 20:24:11 2011 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 EB9BF106566C for ; Mon, 10 Jan 2011 20:24:11 +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 A0FFB8FC13 for ; Mon, 10 Jan 2011 20:24:11 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEACf6Kk2DaFvO/2dsb2JhbACECKE2rUiNdIEhgzd0BIRnhiOFKg X-IronPort-AV: E=Sophos;i="4.60,302,1291611600"; d="scan'208";a="106560793" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 10 Jan 2011 15:24:10 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 78FF6B3FA3; Mon, 10 Jan 2011 15:24:10 -0500 (EST) Date: Mon, 10 Jan 2011 15:24:10 -0500 (EST) From: Rick Macklem To: Ronald Klop Message-ID: <484784150.100302.1294691050401.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: Kostik Belousov , freebsd-stable@freebsd.org Subject: Re: Hang in VOP_LOCK1_APV on 8-STABLE with NFS. 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, 10 Jan 2011 20:24:12 -0000 > > Hi, > > I have got the first steps set up. No solution yet. > 1. With the patch OpenOffice opens my homedir (yeah!), but it gives an > I/O > error when saving a file and everything hangs after that. Hmm, I don't think you mentioned what server you were using. It wouldn't happen to be a FreeBSD one exported ZFS? If so, make sure you have this patch in it: http://people.freebsd.org/~rmacklem/freebsd8.0-patches/freebsd8-nfsserver-estale.patch (With it a stale file handle can result in EIO from a server exporting ZFS and that can make the client loop around, retrying the RPC.) > 2. I have dumps and stuff. I will mail some links in private e-mail. I'll take a look at some point. > 3. Didn't work. It mount, but ls -l /home gives "Operation not > permitted". > It should work. This hints at a server issue. Anyhow, I'll look at the dumps at some point, rick From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 20:30:56 2011 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 105971065673 for ; Mon, 10 Jan 2011 20:30:56 +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 B67EA8FC17 for ; Mon, 10 Jan 2011 20:30:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAF37Kk2DaFvO/2dsb2JhbACECKE2rU+NdYEhgzd0BIRnhiOFKg X-IronPort-AV: E=Sophos;i="4.60,303,1291611600"; d="scan'208";a="106561694" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 10 Jan 2011 15:30:55 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 02643B3FA5; Mon, 10 Jan 2011 15:30:55 -0500 (EST) Date: Mon, 10 Jan 2011 15:30:55 -0500 (EST) From: Rick Macklem To: Ronald Klop Message-ID: <115302716.101223.1294691454949.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <484784150.100302.1294691050401.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: Kostik Belousov , freebsd-stable@freebsd.org Subject: Re: Hang in VOP_LOCK1_APV on 8-STABLE with NFS. 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, 10 Jan 2011 20:30:56 -0000 > > > > Hi, > > > > I have got the first steps set up. No solution yet. > > 1. With the patch OpenOffice opens my homedir (yeah!), but it gives > > an > > I/O > > error when saving a file and everything hangs after that. > > Hmm, I don't think you mentioned what server you were using. It > wouldn't happen to be a FreeBSD one exported ZFS? If so, make > sure you have this patch in it: > http://people.freebsd.org/~rmacklem/freebsd8.0-patches/freebsd8-nfsserver-estale.patch > (With it a stale file handle can result in EIO from a server exporting Oops, I meant "Without the patch a stale file handle...", rick From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 21:06:56 2011 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 2BCC81065695 for ; Mon, 10 Jan 2011 21:06:56 +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 D42218FC15 for ; Mon, 10 Jan 2011 21:06:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAMMDK02DaFvO/2dsb2JhbACECKE2rUyNf4Ehgzd0BIRnhiOFKg X-IronPort-AV: E=Sophos;i="4.60,303,1291611600"; d="scan'208";a="104869523" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 10 Jan 2011 16:06:54 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B9786B414C; Mon, 10 Jan 2011 16:06:54 -0500 (EST) Date: Mon, 10 Jan 2011 16:06:54 -0500 (EST) From: Rick Macklem To: Robert Schulze Message-ID: <309373846.105893.1294693614702.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4D29DC1C.8040909@bytecamp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: nfsd stuck in *rc_lock state 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, 10 Jan 2011 21:06:56 -0000 > Hello Rick, > > Am 11.11.2010 23:54, schrieb Rick Macklem: > > That patch is "self contained", so I think it should be fine to > > apply it > > to an 8.0 server. > > > > You might also want > > http://people.freebsd.org/~rmacklem/freebsd8.0-patches/freebsd8-svc-mbufleak.patch > > which plugged an mbuf leak in the regular FreeBSD8.0 server. > > > > Good luck with it, rick > > the patch fixes the 100% cpu utilization, but we now had two times the > issue, that all boxes lost connection to the nfs server (/home not > responding), but nfsd was at about 1%. > > Top did not show a strange behaviour here: > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 703 root 55 0 4772K 1384K RUN 5 329:12 1.37% > {nfsd: service} > 703 root 56 0 4772K 1384K rpcsvc 0 326:41 0.59% > {nfsd: service} > 703 root 52 0 4772K 1384K rpcsvc 6 326:28 0.29% > {nfsd: service} > 703 root 60 0 4772K 1384K rpcsvc 5 328:42 0.00% > {nfsd: master} > 703 root 54 0 4772K 1384K rpcsvc 0 327:44 0.00% > {nfsd: service} > 703 root 53 0 4772K 1384K rpcsvc 1 327:37 0.00% > {nfsd: service} > 703 root 54 0 4772K 1384K rpcsvc 6 326:51 0.00% > {nfsd: service} > 703 root 57 0 4772K 1384K rpcsvc 2 326:44 0.00% > {nfsd: service} > 703 root 50 0 4772K 1384K rpcsvc 1 326:20 0.00% > {nfsd: service} > 703 root 71 0 4772K 1384K rpcsvc 2 323:11 0.00% > {nfsd: service} > 703 root 47 0 4772K 1384K rpcsvc 7 321:11 0.00% > {nfsd: service} > 703 root 46 0 4772K 1384K tx->tx 2 320:00 0.00% > {nfsd: service} > > there was nothing special in the logfiles, too. > How to debug such a situation? > First off, I hope you don't mind me adding the mailing list as a cc. I'd like this stuff captured in the archive for others to see. (If people don't like the noise, I'll take the heat:-) Ok, I'm sure others have better techniques, but here's how I would start trying to resolve the above, done when the server is stuck. 1 - Make sure the network is still functioning for other things like ssh. 2 - Do a "ps axHlww" and look at all the nfsd threads. I am primarily interested in the MWCHAN field. If it is: rpcsvc - the thread is just waiting for an RPC-->normal ufs or zfs - waiting for a vnode lock on the underlying file system anything else - I need to look in the kernel sources for the "sleep" with that argument. If I can't easily explain what all the nfsd threads are waiting for, wading through a "procstat -ka" is my next step. (I find this rather painful, so I tend to delay doing this as long as possible.:-) 3 - Do a "nfsstat -s" repeatedly and see if any of the counters are increasing. 4 - Fire up a "tcpdump" and see if there is any NFS traffic. (If there is, I'll capture it and put it in wireshark.) 5 - Do a "vmstat -z | fgrep mbuf" and look at the mbuf allocation. (If the machine is running out of mbufs, all sorts of quirky behaviour is possible.) What top shows above isn't much, although I'd wonder what mbuf usage looks like? If you haven't applied the patch mentioned in the above message, you should do that. I don't know if this helps, but... rick From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 21:40:06 2011 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 877E91065672; Mon, 10 Jan 2011 21:40:06 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 19F7A8FC08; Mon, 10 Jan 2011 21:40:05 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p0ALe4j3025070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 22:40:05 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1294695605; bh=eO0umeTj4bnkBz8tYJIJZgZlaa7Fkwt9zyGnoEdptZc=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=kMiDPUYQuXtncdlZdqDp97bnfpXfSS0NR5WnaHH5bL6o+RQjcUdn30QDw357rg3WT mabpcATZ1wou7hlUP5ux7uscciBSuOyJ8Juk8G4u00TBfaRGuo8IF4lbf3te/bbJZU GiVpLAfsGekTa4WUEOnIpAYdqGaMQLEUJlAN3UwQ= Date: Mon, 10 Jan 2011 22:40:04 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: stable@FreeBSD.org Message-ID: <20110110214004.GI23329@acme.spoerlein.net> Mail-Followup-To: stable@FreeBSD.org, avg@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: avg@FreeBSD.org Subject: tmpfs regression in recent -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: Mon, 10 Jan 2011 21:40:06 -0000 Hey, the following line in fstab used to work just fine for my /tmp: tmpfs /tmp tmpfs rw,size=1g,mode=1777 0 0 But since I upgraded to 8.2-PRERELEASE, /tmp will soon run out of space (usually after leaving the box overnight). % df /tmp Filesystem 1K-blocks Used Avail Capacity Mounted on tmpfs 12 12 0 100% /tmp Yes, what you see here, is not "stuff" filling up the /tmp partition, *BUT* the /tmp partition shrinking to a ridiculous size. /tmp only has the usual stuff on it, as I can now no longer create temporary files there: % du /tmp 4 /tmp/.X11-unix 0 /tmp/.XIM-unix 0 /tmp/.ICE-unix 0 /tmp/.font-unix 4 /tmp/ssh-tEgl0QxQHp 4 /tmp/ksocket-uqs 12 /tmp/kde-uqs 4 /tmp/fam-uqs 8 /tmp/.vbox-uqs-ipc 0 /tmp/worker-uqs 44 /tmp Anything I could try? Uli From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 21:42:27 2011 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 BD750106564A; Mon, 10 Jan 2011 21:42:27 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id A8DA58FC12; Mon, 10 Jan 2011 21:42:26 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 0ECED7071B6; Mon, 10 Jan 2011 22:42:25 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 15.7484] X-CRM114-CacheID: sfid-20110110_22422_0F9498C7 X-CRM114-Status: Good ( pR: 15.7484 ) X-Spambayes-Classification: ham; 0.00 Message-ID: <4D2B7D40.4000604@fsn.hu> Date: Mon, 10 Jan 2011 22:42:24 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Martin Matuska References: <4D0A09AF.3040005@FreeBSD.org> In-Reply-To: <4D0A09AF.3040005@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: New ZFSv28 patchset for 8-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: Mon, 10 Jan 2011 21:42:27 -0000 On 12/16/2010 01:44 PM, Martin Matuska wrote: > Hi everyone, > > following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am > providing a ZFSv28 testing patch for 8-STABLE. > > Link to the patch: > > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz > > Link to mfsBSD ISO files for testing (i386 and amd64): > http://mfsbsd.vx.sk/iso/zfs-v28/8.2-beta-zfsv28-amd64.iso > http://mfsbsd.vx.sk/iso/zfs-v28/8.2-beta-zfsv28-i386.iso > > The root password for the ISO files: "mfsroot" > The ISO files work on real systems and in virtualbox. > They conatin a full install of FreeBSD 8.2-PRERELEASE with ZFS v28, > simply use the provided "zfsinstall" script. > > The patch is against FreeBSD 8-STABLE as of 2010-12-15. > > When applying the patch be sure to use correct options for patch(1) > and make sure the file sys/cddl/compat/opensolaris/sys/sysmacros.h gets > deleted: > > # cd /usr/src > # fetch > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz > # xz -d stable-8-zfsv28-20101215.patch.xz > # patch -E -p0< stable-8-zfsv28-20101215.patch > # rm sys/cddl/compat/opensolaris/sys/sysmacros.h I've just got a panic: http://people.fsn.hu/~bra/freebsd/20110101-zfsv28-fbsd/IMAGE_006.jpg The panic line for google: panic: solaris assert: task->ost_magic == TASKQ_MAGIC, file: /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_taskq.c, line: 150 I hope this is enough for debugging, if it's not yet otherwise known. If not, I will try to catch it againt and make a dump. Thanks, From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 21:45:54 2011 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 A9A3510656AB; Mon, 10 Jan 2011 21:45:54 +0000 (UTC) (envelope-from jack.vogel@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 883F18FC1F; Mon, 10 Jan 2011 21:45:54 +0000 (UTC) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 10 Jan 2011 13:17:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.60,303,1291622400"; d="scan'208";a="645391387" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by fmsmga002.fm.intel.com with ESMTP; 10 Jan 2011 13:17:29 -0800 Received: from orsmsx508.amr.corp.intel.com ([10.22.226.46]) by orsmsx602.amr.corp.intel.com ([10.22.226.211]) with mapi; Mon, 10 Jan 2011 13:17:29 -0800 From: "Vogel, Jack" To: TAKAHASHI Yoshihiro , "jfvogel@gmail.com" Date: Mon, 10 Jan 2011 13:17:29 -0800 Thread-Topic: Supermicro Bladeserver Thread-Index: Acuu5cvMyZ5NemA1SYe02R9/WkZ0agCJaEbQ Message-ID: <1DB50624F8348F48840F2E2CF6040A9D014BC5519A@orsmsx508.amr.corp.intel.com> References: <20110108.124018.59640143160055980.nyan@FreeBSD.org> In-Reply-To: <20110108.124018.59640143160055980.nyan@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: RE: Supermicro Bladeserver 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, 10 Jan 2011 21:45:54 -0000 We attempted to repro this problem with the 82566DM (ich8 btw) in house and= failed, it worked correctly for my testers. Oh, and just so the mailing lists have an update, the SM Blade problem was = not an issue in the driver, it was a local change in the loader.conf that c= aused the problem. Regards, Jack -----Original Message----- From: TAKAHASHI Yoshihiro [mailto:nyan@FreeBSD.org]=20 Sent: Friday, January 07, 2011 7:40 PM To: jfvogel@gmail.com Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org; Vogel, Jack Subject: Re: Supermicro Bladeserver In article Jack Vogel writes: > I am trying to track down a problem being experienced at icir.org using > SuperMicro > bladeservers, the SERDES 82575 interfaces are having connectivity or perh= aps > autoneg problems, resulting in link transitions and watchdog resets. >=20 > The closest hardware my org at Intel has is a Fujitsu server who's blades > also have > this device, but testing on that has failed to repro the problem. >=20 > I was wondering if anyone else out there has this hardware, if so could y= ou > let me > know your experience, have you had problems or not, etc etc? My machine has the following em(4) device and it has a autoneg problem. When I was using 8-stable kernel at 2010/11/01, it has no problem. But I update to 8-stable at 2010/12/01, the kernel is only linked up as 10M. em0@pci0:0:25:0: class=3D0x020000 card=3D0x13d510cf chip=3D0x104a8086 re= v=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82566DM Gigabit Network Connection' class =3D network subclass =3D ethernet --- TAKAHASHI Yoshihiro From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 21:49:27 2011 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 460E0106566B; Mon, 10 Jan 2011 21:49:27 +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 19E5C8FC15; Mon, 10 Jan 2011 21:49:27 +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 B66FC46B35; Mon, 10 Jan 2011 16:49:26 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 921478A01D; Mon, 10 Jan 2011 16:49:25 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 10 Jan 2011 16:49:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <20110110214004.GI23329@acme.spoerlein.net> In-Reply-To: <20110110214004.GI23329@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101101649.14385.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 10 Jan 2011 16:49:25 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ulrich =?iso-8859-1?q?Sp=F6rlein?= , stable@freebsd.org, avg@freebsd.org Subject: Re: tmpfs regression in recent -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: Mon, 10 Jan 2011 21:49:27 -0000 On Monday, January 10, 2011 4:40:04 pm Ulrich Sp=F6rlein wrote: > Hey, >=20 > the following line in fstab used to work just fine for my /tmp: >=20 > tmpfs /tmp tmpfs rw,size=3D1g,mode=3D1777 0 0 I thought there was a thread recently about tmpfs not supporting things lik= e=20 "1g" for size? =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 21:49:27 2011 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 460E0106566B; Mon, 10 Jan 2011 21:49:27 +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 19E5C8FC15; Mon, 10 Jan 2011 21:49:27 +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 B66FC46B35; Mon, 10 Jan 2011 16:49:26 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 921478A01D; Mon, 10 Jan 2011 16:49:25 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 10 Jan 2011 16:49:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <20110110214004.GI23329@acme.spoerlein.net> In-Reply-To: <20110110214004.GI23329@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101101649.14385.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 10 Jan 2011 16:49:25 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ulrich =?iso-8859-1?q?Sp=F6rlein?= , stable@freebsd.org, avg@freebsd.org Subject: Re: tmpfs regression in recent -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: Mon, 10 Jan 2011 21:49:27 -0000 On Monday, January 10, 2011 4:40:04 pm Ulrich Sp=F6rlein wrote: > Hey, >=20 > the following line in fstab used to work just fine for my /tmp: >=20 > tmpfs /tmp tmpfs rw,size=3D1g,mode=3D1777 0 0 I thought there was a thread recently about tmpfs not supporting things lik= e=20 "1g" for size? =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 22:11:37 2011 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 B03CE1065679 for ; Mon, 10 Jan 2011 22:11:37 +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 6572D8FC1F for ; Mon, 10 Jan 2011 22:11:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8FAP4SK02DaFvO/2dsb2JhbACECJIzjwOtQ44JgSGDN3QEhGeGIw X-IronPort-AV: E=Sophos;i="4.60,303,1291611600"; d="scan'208";a="104878783" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 10 Jan 2011 17:11:36 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 80540B3FC0; Mon, 10 Jan 2011 17:11:36 -0500 (EST) Date: Mon, 10 Jan 2011 17:11:36 -0500 (EST) From: Rick Macklem To: george+freebsd@m5p.com Message-ID: <1472694795.111713.1294697496463.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201101101651.p0AGp12d001683@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: NFS performance 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, 10 Jan 2011 22:11:37 -0000 > > > > So, did the patch get rid of the 1min + stalls you reported earlier? > > > Yes. The stalls (and the "server not responding" log messages are > gone. Thanks! -- George > Ok, thats a start anyhow. Maybe someday we can explain the slow read rates you are still observing. Thanks for letting us know, rick From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 22:14:25 2011 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 CE5BC106564A; Mon, 10 Jan 2011 22:14:25 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 60F498FC13; Mon, 10 Jan 2011 22:14:25 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p0AMEOhQ025803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 23:14:24 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1294697664; bh=Tn5JYgjrfK3YCUgLp/cFJ9Kpn7WCq6ob7dtN40nU27g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=GF5zEH0I0u7KiXjAMQqSNmuPaTIvjuCGiYnKudsHwAQgLspFeMtsMJJGcl7/auTuq vTkTTleVYsVFuon9ki6b/ippMQPMZcd/oUSCJLhWhiqtt9FvhSeZ2d9b2K1WkP/pfr yKQ7xsV6bIYCcxzHCPu8z2YnYHeW8qHUbKmyhaRo= Date: Mon, 10 Jan 2011 23:14:24 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: John Baldwin Message-ID: <20110110221424.GK23329@acme.spoerlein.net> Mail-Followup-To: John Baldwin , freebsd-stable@freebsd.org, avg@freebsd.org References: <20110110214004.GI23329@acme.spoerlein.net> <201101101649.14385.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201101101649.14385.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, avg@freebsd.org Subject: Re: tmpfs regression in recent -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: Mon, 10 Jan 2011 22:14:25 -0000 On Mon, 10.01.2011 at 16:49:14 -0500, John Baldwin wrote: > On Monday, January 10, 2011 4:40:04 pm Ulrich Spörlein wrote: > > Hey, > > > > the following line in fstab used to work just fine for my /tmp: > > > > tmpfs /tmp tmpfs rw,size=1g,mode=1777 0 0 > > I thought there was a thread recently about tmpfs not supporting things like > "1g" for size? Nah, this must be some leak of another kind. Luckily I could bandaid this by unionfs mounting an mfs disk over /tmp so programs continue to run. But, tmpfs really is out of resources, as I cannot create new tmpfs's for example: root@elmar: ~# mount -t tmpfs tmpfs /media mount: tmpfs : No space left on device And besides, the /tmp mount comes up fine and shows enough free space (I checked this the last time, after I had rebooted the box). Cheers, Uli From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 22:22:56 2011 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 A3642106564A for ; Mon, 10 Jan 2011 22:22:56 +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 59E388FC1B for ; Mon, 10 Jan 2011 22:22:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8FAFgVK02DaFvO/2dsb2JhbACECJIzjwOtSo4QgSGDN3QEhGeGIw X-IronPort-AV: E=Sophos;i="4.60,303,1291611600"; d="scan'208";a="104880046" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 10 Jan 2011 17:22:56 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 14614B403E for ; Mon, 10 Jan 2011 17:22:56 -0500 (EST) Date: Mon, 10 Jan 2011 17:22:56 -0500 (EST) From: Rick Macklem To: freebsd-stable@freebsd.org Message-ID: <717625949.112359.1294698176010.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Subject: important NFS client patch for FreeBSD8.n 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, 10 Jan 2011 22:22:56 -0000 I just commited a patch (r217242) to head. Anyone who is using client side NFS on FreeBSD8.n should apply this patch. It is also available at: http://people.freebsd.org/~rmacklem/krpc.patch It fixes a problem where the kernel rpc assumes that 4 bytes of data exists in the first mbuf without checking. If the data straddles multiple mbufs, it uses garbage and then a typical case will wedge for a minute or so until it times out and establishes a new TCP connection. It also replaces m_pullup() with m_copydata(), since m_pullup() can fail for rare cases when there is data available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail when mbuf allocation is constrainted, for example.) Thanks to john.gemignani at isilon.com for spotting this problem, rick From owner-freebsd-stable@FreeBSD.ORG Mon Jan 10 22:27:56 2011 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 4F54D10656AE for ; Mon, 10 Jan 2011 22:27:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) 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 0FEA38FC1B for ; Mon, 10 Jan 2011 22:27:55 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id tp151f00A0mv7h05ByTosQ; Mon, 10 Jan 2011 22:27:48 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta11.westchester.pa.mail.comcast.net with comcast id tyTm1f00h2tehsa3XyTnMi; Mon, 10 Jan 2011 22:27:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C09C09B427; Mon, 10 Jan 2011 14:27:45 -0800 (PST) Date: Mon, 10 Jan 2011 14:27:45 -0800 From: Jeremy Chadwick To: John Baldwin , freebsd-stable@freebsd.org, avg@freebsd.org Message-ID: <20110110222745.GA80716@icarus.home.lan> References: <20110110214004.GI23329@acme.spoerlein.net> <201101101649.14385.jhb@freebsd.org> <20110110221424.GK23329@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110110221424.GK23329@acme.spoerlein.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: tmpfs regression in recent -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: Mon, 10 Jan 2011 22:27:56 -0000 On Mon, Jan 10, 2011 at 11:14:24PM +0100, Ulrich Spörlein wrote: > On Mon, 10.01.2011 at 16:49:14 -0500, John Baldwin wrote: > > On Monday, January 10, 2011 4:40:04 pm Ulrich Spörlein wrote: > > > Hey, > > > > > > the following line in fstab used to work just fine for my /tmp: > > > > > > tmpfs /tmp tmpfs rw,size=1g,mode=1777 0 0 > > > > I thought there was a thread recently about tmpfs not supporting things like > > "1g" for size? > > Nah, this must be some leak of another kind. Luckily I could bandaid > this by unionfs mounting an mfs disk over /tmp so programs continue to > run. > > But, tmpfs really is out of resources, as I cannot create new tmpfs's > for example: > > root@elmar: ~# mount -t tmpfs tmpfs /media > mount: tmpfs : No space left on device > > And besides, the /tmp mount comes up fine and shows enough free space (I > checked this the last time, after I had rebooted the box). Are you using ZFS on the same machine? If so, ZFS and tmpfs don't play well together, don't use tmpfs. Please search the below page for "tmpfs runs out of space" for all relevant posts: http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/thread.html -- | 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 Jan 10 22:59:33 2011 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 B0C861065670 for ; Mon, 10 Jan 2011 22:59:33 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4E85D8FC12 for ; Mon, 10 Jan 2011 22:59:32 +0000 (UTC) Received: by bwz12 with SMTP id 12so12223425bwz.13 for ; Mon, 10 Jan 2011 14:59:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.66.79 with SMTP id m15mr5712325bki.124.1294698888921; Mon, 10 Jan 2011 14:34:48 -0800 (PST) Received: by 10.204.151.212 with HTTP; Mon, 10 Jan 2011 14:34:48 -0800 (PST) X-Originating-IP: [209.66.78.50] Date: Mon, 10 Jan 2011 17:34:48 -0500 Message-ID: From: Mark Saad To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: Enabling DDB prevent kernel from panicing 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, 10 Jan 2011 22:59:33 -0000 All This was originally posted to hackers@ I have a good question that I cant find an answer for. I believe found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bit kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page fault while in kernel mode " . The hardware works fine in 7.2-RELEASE amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using the stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if this issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC kernel using patches sources and tried to boot and I got the same crash. Next I rebuilt the kernel with KDB and DDB to see if I could get a core-dump of the system. I also set loader.conf to kernel="kernel.DEBUG" kern.dumpdev="/dev/da0s1b" Next I pxebooted the box and the system does not crash on boot up, it will easily load a nfs root and work fine. So I copied my debug kernel, and loader.conf to the local disk and rebooted and it boots fine from the local disk . Rebooting the server and running off the local disks and debug kernel, I cant find any issues. Reboot the box into a GENERIC 7.3-RELEASE-p4 kernel and it crashes With this error Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff800070fa stack pointer = 0x10:0xffffffff8153cbe0 frame pointer = 0x10:0xffffffff8153cc50 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 = 0 (swapper) [thread pid 0 tid 100000 ] Stopped at bzero+0xa: repe stosq %es:(%rdi) It was recommended to comment out the sio hints in /boot/device.hints I did this and I can properly boot a GENERIC 7.3-RELEASE kernel. I reran this same test using 7.4-RC1 the system boots with out any changes to anything. So my question, does anyone know what changed in stable/7 after the creation of 7.3-RELEASE that could have fixed this or does anyone know what could be causing this issue. The sio code does not look like its been changed in a long while . Do we still need s the hits for the sio ports anyway does omitting them from the hints file cause any major issues, I can use the serial port for a console and to connect to to other serial devices with out any issues. -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 00:24:20 2011 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 3CC45106566B for ; Tue, 11 Jan 2011 00:24:20 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C46088FC19 for ; Tue, 11 Jan 2011 00:24:19 +0000 (UTC) Received: by ewy24 with SMTP id 24so9397384ewy.13 for ; Mon, 10 Jan 2011 16:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fKba1GNZpCdNaao6oQam2U7ycZt0LwM/QANmoGrOQqo=; b=sjlnONqqiBOj2RVRKCYsWql/Fu0P7IAnrmCPglyrr8G75out1NL+ygXB+nKGCEPCnm IUz2rEqGB7vZYCA8hfzf2ThFp3T5PfYe+80ESpZ+H3RCRDClTB+N0Ix0U/4uVSHZEYLb pfhZJO54SADBfBknKvaekHBuiryo3aSZEE6VI= 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=AG/AJ9khXiE1ffT/Iq3ostLX1bHG4xz0/uJIl854E2htFATn6bCHY12n2kh9xO07fW guB/6r+1gJQtQB1cKiQHbOuMr5pRxZBOMW8rpoc2OPdTqONQy2Rdw9WtOvHpG7sklP4M 3fm7bLnKln6sxZu1V1pd2jl5CNrqzBbqrhESM= MIME-Version: 1.0 Received: by 10.213.30.3 with SMTP id s3mr11442257ebc.22.1294703945179; Mon, 10 Jan 2011 15:59:05 -0800 (PST) Received: by 10.213.8.134 with HTTP; Mon, 10 Jan 2011 15:59:05 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Jan 2011 01:59:05 +0200 Message-ID: From: nickolasbug@gmail.com To: Mark Saad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: Enabling DDB prevent kernel from panicing 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, 11 Jan 2011 00:24:20 -0000 Hello, Mark 2011/1/11 Mark Saad : > All > This was originally posted to hackers@ > > I have a good question that I cant find an answer for. I believe > found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bit > kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page > fault while in kernel mode " . The hardware works fine in 7.2-RELEASE > amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . > > In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using the > stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if this > issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC > kernel using patches sources and tried to boot and I got the same > crash. > > =A0Next I rebuilt the kernel with KDB and DDB to see if I could get a > core-dump of the system. I also set loader.conf to > > kernel=3D"kernel.DEBUG" > kern.dumpdev=3D"/dev/da0s1b" > > Next I pxebooted =A0the box and the system does not crash on boot up, it > will easily load a nfs root and work fine. So I copied my debug > kernel, and loader.conf to the local disk and rebooted and it boots > fine from the local disk . Looks like a race condition. Well, you don't need to compile KDB and DDB, just add makeoptions DEBUG=3D-g into your kernel config file and rebuild kernel. Then after you got a crash dump you can easy debug it (see FreeBSD Developers Handbok): http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.htm= l wbr, Nickolas From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 00:42:24 2011 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 E5A80106564A for ; Tue, 11 Jan 2011 00:42:24 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 808E98FC16 for ; Tue, 11 Jan 2011 00:42:24 +0000 (UTC) Received: by bwz12 with SMTP id 12so12274558bwz.13 for ; Mon, 10 Jan 2011 16:42:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.55.129 with SMTP id u1mr374736bkg.43.1294706541692; Mon, 10 Jan 2011 16:42:21 -0800 (PST) Received: by 10.204.151.212 with HTTP; Mon, 10 Jan 2011 16:42:21 -0800 (PST) X-Originating-IP: [68.239.206.210] In-Reply-To: References: Date: Mon, 10 Jan 2011 19:42:21 -0500 Message-ID: From: Mark Saad To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Enabling DDB prevent kernel from panicing 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, 11 Jan 2011 00:42:25 -0000 On Mon, Jan 10, 2011 at 6:59 PM, wrote: > Hello, Mark > > 2011/1/11 Mark Saad : >> All >> This was originally posted to hackers@ >> >> I have a good question that I cant find an answer for. I believe >> found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bit >> kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page >> fault while in kernel mode " . The hardware works fine in 7.2-RELEASE >> amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . >> >> In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using the >> stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if this >> issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC >> kernel using patches sources and tried to boot and I got the same >> crash. >> >> =C2=A0Next I rebuilt the kernel with KDB and DDB to see if I could get a >> core-dump of the system. I also set loader.conf to >> >> kernel=3D"kernel.DEBUG" >> kern.dumpdev=3D"/dev/da0s1b" >> >> Next I pxebooted =C2=A0the box and the system does not crash on boot up,= it >> will easily load a nfs root and work fine. So I copied my debug >> kernel, and loader.conf to the local disk and rebooted and it boots >> fine from the local disk . > > Looks like a race condition. > Well, you don't need to compile KDB and DDB, just add > > makeoptions DEBUG=3D-g > > into your kernel config file and rebuild kernel. > > Then after you got a crash dump you can easy debug it (see FreeBSD > Developers Handbok): > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.h= tml > > > wbr, > Nickolas > Sorry let me clarify the issue, When you install a generic 7.3-RELEASE amd64 on some of the HP servers I use, the kernel panics in boot up when it probes the sio driver . Here is a part of my dmesg.boot file atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio0: [FILTER] Say about here in the boot up , is where the box crashes with the above noted error. If I then boot the same box off a 7.1-RELEASE amd64 netboot server , mount the local disks of the 7.3-RELEASE install and edit the /boot/device.hints and comment out the sio hints like this hint.vga.0.at=3D"isa" hint.sc.0.at=3D"isa" hint.sc.0.flags=3D"0x100" #hint.sio.0.at=3D"isa" #hint.sio.0.port=3D"0x3F8" #hint.sio.0.flags=3D"0x10" #hint.sio.0.irq=3D"4" #hint.sio.1.at=3D"isa" #hint.sio.1.port=3D"0x2F8" #hint.sio.1.irq=3D"3" #hint.sio.2.at=3D"isa" #hint.sio.2.disabled=3D"1" #hint.sio.2.port=3D"0x3E8" #hint.sio.2.irq=3D"5" #hint.sio.3.at=3D"isa" #hint.sio.3.disabled=3D"1" #hint.sio.3.port=3D"0x2E8" #hint.sio.3.irq=3D"9" hint.ppc.0.at=3D"isa" hint.ppc.0.irq=3D"7" then boot the server off the local disks , the server boots correctly. The odd thing was, I rebuilt a debug 7.3-RELEASE amd64 kernel on another working server, and installed it on the broken server and booted it off the local disks, with out any changes to the hints file and the server booted correctly and I was able to manually break out into the debugger , but nothing looked wrong . So to sum this up there is something broken in 7.3-RELEASE but I cant figure out what. This server works with a generic install of 7.1-RELEASE 7.2-RELEASE , 6.1-RELEASE, 6.2-RELEASE and 6.4-RELEASE in both amd64 and i386 , but not 7.3-RELEASE in amd64 . It also worked in 7.4-RC1 . avg recommended I see what changed from r212964 to r212994 I am currently looking into this . Has anyone seen this before ? --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 02:26:46 2011 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 7ADE2106566B for ; Tue, 11 Jan 2011 02:26:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2200D8FC08 for ; Tue, 11 Jan 2011 02:26:45 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id tsnw1f0051wpRvQ532DKFM; Tue, 11 Jan 2011 02:13:19 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta18.westchester.pa.mail.comcast.net with comcast id u2DH1f00S2tehsa3e2DJm8; Tue, 11 Jan 2011 02:13:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6ECF29B427; Mon, 10 Jan 2011 18:13:16 -0800 (PST) Date: Mon, 10 Jan 2011 18:13:16 -0800 From: Jeremy Chadwick To: Mark Saad Message-ID: <20110111021316.GA84376@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: Enabling DDB prevent kernel from panicing 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, 11 Jan 2011 02:26:46 -0000 On Mon, Jan 10, 2011 at 07:42:21PM -0500, Mark Saad wrote: > On Mon, Jan 10, 2011 at 6:59 PM, wrote: > > Hello, Mark > > > > 2011/1/11 Mark Saad : > >> All > >> This was originally posted to hackers@ > >> > >> I have a good question that I cant find an answer for. I believe > >> found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bit > >> kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page > >> fault while in kernel mode " . The hardware works fine in 7.2-RELEASE > >> amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . > >> > >> In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using the > >> stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if this > >> issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC > >> kernel using patches sources and tried to boot and I got the same > >> crash. > >> > >>  Next I rebuilt the kernel with KDB and DDB to see if I could get a > >> core-dump of the system. I also set loader.conf to > >> > >> kernel="kernel.DEBUG" > >> kern.dumpdev="/dev/da0s1b" > >> > >> Next I pxebooted  the box and the system does not crash on boot up, it > >> will easily load a nfs root and work fine. So I copied my debug > >> kernel, and loader.conf to the local disk and rebooted and it boots > >> fine from the local disk . > > > > Looks like a race condition. > > Well, you don't need to compile KDB and DDB, just add > > > > makeoptions DEBUG=-g > > > > into your kernel config file and rebuild kernel. > > > > Then after you got a crash dump you can easy debug it (see FreeBSD > > Developers Handbok): > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html > > > > > > wbr, > > Nickolas > > > > Sorry let me clarify the issue, When you install a generic > 7.3-RELEASE amd64 on some of the HP servers I use, the kernel panics > in boot up > when it probes the sio driver . Here is a part of my dmesg.boot file > > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: port 0x3f8-0x3ff irq 4 on acpi0 > sio0: type 16550A > sio0: [FILTER] > Say about here in the boot up , is where the box crashes with the > above noted error. > > If I then boot the same box off a 7.1-RELEASE amd64 netboot server , > mount the local disks of the 7.3-RELEASE install and edit the > /boot/device.hints and comment out the sio hints like this > > hint.vga.0.at="isa" > hint.sc.0.at="isa" > hint.sc.0.flags="0x100" > #hint.sio.0.at="isa" > #hint.sio.0.port="0x3F8" > #hint.sio.0.flags="0x10" > #hint.sio.0.irq="4" > #hint.sio.1.at="isa" > #hint.sio.1.port="0x2F8" > #hint.sio.1.irq="3" > #hint.sio.2.at="isa" > #hint.sio.2.disabled="1" > #hint.sio.2.port="0x3E8" > #hint.sio.2.irq="5" > #hint.sio.3.at="isa" > #hint.sio.3.disabled="1" > #hint.sio.3.port="0x2E8" > #hint.sio.3.irq="9" > hint.ppc.0.at="isa" > hint.ppc.0.irq="7" > > then boot the server off the local disks , the server boots correctly. > > The odd thing was, I rebuilt a debug 7.3-RELEASE amd64 kernel on > another working server, and installed it on the broken server and > booted it off the local disks, with out any changes to the hints file > and the server booted correctly and I was able to manually break out > into the debugger , but nothing looked wrong . The sio(4) driver has been deprecated in RELENG_8, which uses uart(4). uart(4) is better in a lot of regards, and should also be available for use on RELENG_7 but you'll need to adjust /etc/ttys to refer to the new device names (ttyuX vs. ttydX), plus add the uart entries to /boot/device.hints. I'm mentioning this as a workaround. Also worth considering is that the sio(4) ISA probe may be touching something Bad(tm) as a result, so you might try adding the following lines to your loader.conf (not a typo) to disable sio(4) entries entirely: hint.sio.0.disabled="1" hint.sio.1.disabled="1" And see if that improves things. If it does, remove the sio.1.disabled entry and see if that suffices. > So to sum this up there is something broken in 7.3-RELEASE but I cant > figure out what. This server works with a generic install of > 7.1-RELEASE 7.2-RELEASE , 6.1-RELEASE, 6.2-RELEASE and 6.4-RELEASE in > both amd64 and i386 , but not 7.3-RELEASE in amd64 . It also worked in > 7.4-RC1 . > > avg recommended I see what changed from r212964 to r212994 I am > currently looking into this . Has anyone seen this before ? If the server works fine with 7.4-PRERELEASE/RC1, why are you caring about 7.3? Upgrade. :-) -- | 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 Jan 11 03:29:14 2011 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 8006B1065675 for ; Tue, 11 Jan 2011 03:29:14 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 022018FC15 for ; Tue, 11 Jan 2011 03:29:13 +0000 (UTC) Received: by bwz12 with SMTP id 12so12364358bwz.13 for ; Mon, 10 Jan 2011 19:29:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.140.208 with SMTP id j16mr3822725bku.151.1294716551487; Mon, 10 Jan 2011 19:29:11 -0800 (PST) Received: by 10.204.151.212 with HTTP; Mon, 10 Jan 2011 19:29:11 -0800 (PST) X-Originating-IP: [68.239.206.210] In-Reply-To: <20110111021316.GA84376@icarus.home.lan> References: <20110111021316.GA84376@icarus.home.lan> Date: Mon, 10 Jan 2011 22:29:11 -0500 Message-ID: From: Mark Saad To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: Enabling DDB prevent kernel from panicing 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, 11 Jan 2011 03:29:14 -0000 On Mon, Jan 10, 2011 at 9:13 PM, Jeremy Chadwick wrote: > On Mon, Jan 10, 2011 at 07:42:21PM -0500, Mark Saad wrote: >> On Mon, Jan 10, 2011 at 6:59 PM, =C2=A0 wrote: >> > Hello, Mark >> > >> > 2011/1/11 Mark Saad : >> >> All >> >> This was originally posted to hackers@ >> >> >> >> I have a good question that I cant find an answer for. I believe >> >> found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bi= t >> >> kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page >> >> fault while in kernel mode " . The hardware works fine in 7.2-RELEASE >> >> amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . >> >> >> >> In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using th= e >> >> stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if thi= s >> >> issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC >> >> kernel using patches sources and tried to boot and I got the same >> >> crash. >> >> >> >> =C2=A0Next I rebuilt the kernel with KDB and DDB to see if I could ge= t a >> >> core-dump of the system. I also set loader.conf to >> >> >> >> kernel=3D"kernel.DEBUG" >> >> kern.dumpdev=3D"/dev/da0s1b" >> >> >> >> Next I pxebooted =C2=A0the box and the system does not crash on boot = up, it >> >> will easily load a nfs root and work fine. So I copied my debug >> >> kernel, and loader.conf to the local disk and rebooted and it boots >> >> fine from the local disk . >> > >> > Looks like a race condition. >> > Well, you don't need to compile KDB and DDB, just add >> > >> > makeoptions DEBUG=3D-g >> > >> > into your kernel config file and rebuild kernel. >> > >> > Then after you got a crash dump you can easy debug it (see FreeBSD >> > Developers Handbok): >> > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gd= b.html >> > >> > >> > wbr, >> > Nickolas >> > >> >> =C2=A0 Sorry let me clarify the issue, When you install a generic >> 7.3-RELEASE amd64 on some of the HP servers I use, the kernel panics >> in boot up >> when it probes the sio driver . Here is a part of my dmesg.boot file >> >> atkbd0: [ITHREAD] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: [ITHREAD] >> psm0: model Generic PS/2 mouse, device ID 0 >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: port 0x3f8-0x3ff irq 4 on acpi0 >> sio0: type 16550A >> sio0: [FILTER] >> Say about here in the boot up , is where the box crashes with the >> above noted error. >> >> If I then boot the same box off a 7.1-RELEASE amd64 netboot server , >> mount the local disks of the 7.3-RELEASE install and edit the >> /boot/device.hints and comment out the sio hints like this >> >> hint.vga.0.at=3D"isa" >> hint.sc.0.at=3D"isa" >> hint.sc.0.flags=3D"0x100" >> #hint.sio.0.at=3D"isa" >> #hint.sio.0.port=3D"0x3F8" >> #hint.sio.0.flags=3D"0x10" >> #hint.sio.0.irq=3D"4" >> #hint.sio.1.at=3D"isa" >> #hint.sio.1.port=3D"0x2F8" >> #hint.sio.1.irq=3D"3" >> #hint.sio.2.at=3D"isa" >> #hint.sio.2.disabled=3D"1" >> #hint.sio.2.port=3D"0x3E8" >> #hint.sio.2.irq=3D"5" >> #hint.sio.3.at=3D"isa" >> #hint.sio.3.disabled=3D"1" >> #hint.sio.3.port=3D"0x2E8" >> #hint.sio.3.irq=3D"9" >> hint.ppc.0.at=3D"isa" >> hint.ppc.0.irq=3D"7" >> >> then boot the server off the local disks , the server boots correctly. >> >> The odd thing was, I rebuilt a debug 7.3-RELEASE amd64 kernel on >> another working server, and installed it on the broken server and >> booted it off the local disks, with out any changes to the hints file >> and the server booted correctly and I was able to manually break out >> into the debugger , but nothing looked wrong . > > The sio(4) driver has been deprecated in RELENG_8, which uses uart(4). > uart(4) is better in a lot of regards, and should also be available for > use on RELENG_7 but you'll need to adjust /etc/ttys to refer to the new > device names (ttyuX vs. ttydX), plus add the uart entries to > /boot/device.hints. > I found that too, and I was thinking about the change but its going to require a source build of the kernel to fix that along with a bunch of manual work on my side that I would rather not do . > I'm mentioning this as a workaround. > > Also worth considering is that the sio(4) ISA probe may be touching > something Bad(tm) as a result, so you might try adding the following > lines to your loader.conf (not a typo) to disable sio(4) entries > entirely: > > hint.sio.0.disabled=3D"1" > hint.sio.1.disabled=3D"1" > > And see if that improves things. =C2=A0If it does, remove the sio.1.disab= led > entry and see if that suffices. I'll try the hint disabling but how is that different from removing the hint outright ? > >> So to sum this up there is something broken in 7.3-RELEASE but I cant >> figure out what. This server works with a generic install of >> 7.1-RELEASE 7.2-RELEASE , 6.1-RELEASE, 6.2-RELEASE and 6.4-RELEASE in >> both amd64 and i386 , but not 7.3-RELEASE in amd64 . It also worked in >> 7.4-RC1 . >> >> avg recommended I see what changed from r212964 =C2=A0to r212994 I am >> currently looking into this . Has anyone seen this before ? > > If the server works fine with 7.4-PRERELEASE/RC1, why are you caring > about 7.3? =C2=A0Upgrade. =C2=A0:-) > Can't just upgrade we did a bunch of work on 7.3-RELEASE and we are going to stay on 7.3-RELEASE until 2012 for various reasons. > -- > | Jeremy Chadwick =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 jdc@parodiu= s.com | > | Parodius Networking =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.parodius.com/ | > | UNIX Systems Administrator =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Mountain View, CA, USA | > | Making life hard for others since 1977. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 PGP 4BD6C0CB | > > So anyone what to take a stab on flying with out a device.hints ? --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 03:38:16 2011 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 EA854106566B for ; Tue, 11 Jan 2011 03:38:15 +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 BF9C58FC14 for ; Tue, 11 Jan 2011 03:38:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id E630A508AC; Tue, 11 Jan 2011 03:38:14 +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 eVrIKNIJwo3d; Tue, 11 Jan 2011 03:38:14 +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 6864F50852 ; Tue, 11 Jan 2011 03:38:14 +0000 (GMT) Message-ID: <4D2BD0A7.9060003@langille.org> Date: Mon, 10 Jan 2011 22:38:15 -0500 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Hawkes-Reed References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> In-Reply-To: <4D23504D.8060103@libeljournal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: ZFS - hot spares : automatic or 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: Tue, 11 Jan 2011 03:38:16 -0000 On 1/4/2011 11:52 AM, John Hawkes-Reed wrote: > On 04/01/2011 03:08, Dan Langille wrote: >> Hello folks, >> >> I'm trying to discover if ZFS under FreeBSD will automatically pull in a >> hot spare if one is required. >> >> This raised the issue back in March 2010, and refers to a PR opened in >> May 2009 >> >> * http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007943.html >> * http://www.freebsd.org/cgi/query-pr.cgi?pr=134491 >> >> In turn, the PR refers to this March 2010 post referring to using devd >> to accomplish this task. >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055686.html >> >> Does the above represent the the current state? >> >> I ask because I just ordered two more HDD to use as spares. Whether they >> sit on the shelf or in the box is open to discussion. > > As far as our testing could discover, it's not automatic. > > I wrote some Ugly Perl that's called by devd when it spots a drive-fail > event, which seemed to DTRT when simulating a failure by pulling a drive. Without such a script, what is the value in creating hot spares? -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 07:40:41 2011 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 48ED21065670 for ; Tue, 11 Jan 2011 07:40:41 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [168.103.150.6]) by mx1.freebsd.org (Postfix) with ESMTP id E74878FC14 for ; Tue, 11 Jan 2011 07:40:40 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id p0B7duII057684; Mon, 10 Jan 2011 23:40:07 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Mon, 10 Jan 2011 23:40:37 -0800 (PST) Message-ID: <6bb74cb2fa23167e22f88b716d18510e.HRCIM@webmail.1command.com> In-Reply-To: <717625949.112359.1294698176010.JavaMail.root@erie.cs.uoguelph.ca> References: <717625949.112359.1294698176010.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 10 Jan 2011 23:40:37 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Rick Macklem Subject: Re: important NFS client patch for FreeBSD8.n 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, 11 Jan 2011 07:40:41 -0000 Greetings, and thank you for the "heads up". On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote: > I just commited a patch (r217242) to head. Anyone who is using client > side NFS on FreeBSD8.n should apply this patch. It is also available at: > http://people.freebsd.org/~rmacklem/krpc.patch > > > It fixes a problem where the kernel rpc assumes that 4 bytes of data > exists in the first mbuf without checking. If the data straddles multiple mbufs, > it uses garbage and then a typical case will wedge for a minute or so until it > times out and establishes a new TCP connection. It also replaces m_pullup() with > m_copydata(), since m_pullup() can fail for rare cases when there is data > available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail when mbuf > allocation is constrainted, for example.) > > Thanks to john.gemignani at isilon.com for spotting this problem, rick I just fired a message off to @amd64 && @net because I am seeing messages like: nfe0: tx v2 error 0x6204 on a recent 8.1/amd64 install which is connected to an 8.0/i386 via NFS. They both run NFS client && server, and they both utilize mount points on each other. They are only 2 of several interconnected servers. The others are all 7x/i386. But I only see these messages on the 8.1/amd64, and only when connected to, and utilizing mounts on the 8.0/i386, and even then, only when the data exceeds ~1.5Mb. I guess I'm asking if the messages I'm receiving are related to the corrections your patch provides. Or should I keep looking for the answer for the messages I am seeing. Thank you for all your time and consideration. --Chris > _______________________________________________ > 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 Jan 11 08:17:08 2011 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 1E6C21065670 for ; Tue, 11 Jan 2011 08:17:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id BDB438FC08 for ; Tue, 11 Jan 2011 08:17:07 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id u8Fh1f0031c6gX8598H7LA; Tue, 11 Jan 2011 08:17:07 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta23.westchester.pa.mail.comcast.net with comcast id u8H61f0042tehsa3j8H6b1; Tue, 11 Jan 2011 08:17:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 079B49B427; Tue, 11 Jan 2011 00:17:05 -0800 (PST) Date: Tue, 11 Jan 2011 00:17:05 -0800 From: Jeremy Chadwick To: Chris H Message-ID: <20110111081705.GA93322@icarus.home.lan> References: <717625949.112359.1294698176010.JavaMail.root@erie.cs.uoguelph.ca> <6bb74cb2fa23167e22f88b716d18510e.HRCIM@webmail.1command.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6bb74cb2fa23167e22f88b716d18510e.HRCIM@webmail.1command.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Yong-Hyeon Pyun , Rick Macklem , freebsd-stable@freebsd.org Subject: Re: important NFS client patch for FreeBSD8.n 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, 11 Jan 2011 08:17:08 -0000 On Mon, Jan 10, 2011 at 11:40:37PM -0800, Chris H wrote: > Greetings, and thank you for the "heads up". > On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote: > > I just commited a patch (r217242) to head. Anyone who is using client > > side NFS on FreeBSD8.n should apply this patch. It is also available at: > > http://people.freebsd.org/~rmacklem/krpc.patch > > > > > > It fixes a problem where the kernel rpc assumes that 4 bytes of data > > exists in the first mbuf without checking. If the data straddles multiple mbufs, > > it uses garbage and then a typical case will wedge for a minute or so until it > > times out and establishes a new TCP connection. It also replaces m_pullup() with > > m_copydata(), since m_pullup() can fail for rare cases when there is data > > available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail when mbuf > > allocation is constrainted, for example.) > > > > Thanks to john.gemignani at isilon.com for spotting this problem, rick > > I just fired a message off to @amd64 && @net because I am seeing messages like: > > nfe0: tx v2 error 0x6204 > > on a recent 8.1/amd64 install which is connected to an 8.0/i386 via NFS. > They both run NFS client && server, and they both utilize mount points > on each other. They are only 2 of several interconnected servers. The > others are all 7x/i386. But I only see these messages on the 8.1/amd64, > and only when connected to, and utilizing mounts on the 8.0/i386, and even > then, only when the data exceeds ~1.5Mb. > I guess I'm asking if the messages I'm receiving are related to the > corrections your patch provides. Or should I keep looking for the answer > for the messages I am seeing. The above message is coming from the nfe(4) NIC driver, not from NFS. It's possible that NFS tickles some kind of I/O throughput quirk in drivers such as nfe(4), given that they're intended for cheap desktops. CC'ing Yong-Hyeon Pyun to assist in debugging/explaining the above error. In the interim, can you please provide output from the following commands: # uname -a # dmesg (please include relevant nfe details and miibus) # pciconf -lvcb (please only include nfe-related output) # netstat -ind (you can XX-out MACs and/or IPs) # ifconfig -a (you can XX-out MACs and/or IPs) 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 Tue Jan 11 12:20:38 2011 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 524BC1065675 for ; Tue, 11 Jan 2011 12:20:38 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [168.103.150.6]) by mx1.freebsd.org (Postfix) with ESMTP id 390228FC0A for ; Tue, 11 Jan 2011 12:20:36 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id p0BCJxdq067081; Tue, 11 Jan 2011 04:20:05 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Tue, 11 Jan 2011 04:20:35 -0800 (PST) Message-ID: In-Reply-To: <20110111081705.GA93322@icarus.home.lan> References: <717625949.112359.1294698176010.JavaMail.root@erie.cs.uoguelph.ca> <6bb74cb2fa23167e22f88b716d18510e.HRCIM@webmail.1command.com> <20110111081705.GA93322@icarus.home.lan> Date: Tue, 11 Jan 2011 04:20:35 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20110111042005_78835" Cc: pyunyh@gmail.com, rmacklem@uoguelph.ca, freebsd@jdc.parodius.com Subject: Re: important NFS client patch for FreeBSD8.n 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, 11 Jan 2011 12:20:38 -0000 ------=_20110111042005_78835 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello Jeremy, and thank you for your reply. On Tue, January 11, 2011 12:17 am, Jeremy Chadwick wrote: > On Mon, Jan 10, 2011 at 11:40:37PM -0800, Chris H wrote: > >> Greetings, and thank you for the "heads up". >> On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote: >> >>> I just commited a patch (r217242) to head. Anyone who is using client >>> side NFS on FreeBSD8.n should apply this patch. It is also available at: >>> http://people.freebsd.org/~rmacklem/krpc.patch >>> >>> >>> >>> It fixes a problem where the kernel rpc assumes that 4 bytes of data >>> exists in the first mbuf without checking. If the data straddles multiple >>> mbufs, it uses garbage and then a typical case will wedge for a minute or so >>> until it times out and establishes a new TCP connection. It also replaces >>> m_pullup() with m_copydata(), since m_pullup() can fail for rare cases when >>> there is data available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail >>> when mbuf allocation is constrainted, for example.) >>> >>> Thanks to john.gemignani at isilon.com for spotting this problem, rick >>> >> >> I just fired a message off to @amd64 && @net because I am seeing messages >> like: >> >> >> nfe0: tx v2 error 0x6204 >> >> >> on a recent 8.1/amd64 install which is connected to an 8.0/i386 via NFS. They >> both run NFS client && server, and they both utilize mount points on each >> other. They are only 2 of several interconnected servers. The others are all >> 7x/i386. But I only see these messages on the 8.1/amd64, >> and only when connected to, and utilizing mounts on the 8.0/i386, and even >> then, only when the data exceeds ~1.5Mb. I guess I'm asking if the messages >> I'm receiving are related to the >> corrections your patch provides. Or should I keep looking for the answer for >> the messages I am seeing. > > The above message is coming from the nfe(4) NIC driver, not from NFS. > It's possible that NFS tickles some kind of I/O throughput quirk in > drivers such as nfe(4), given that they're intended for cheap desktops. Well, I'd argue that point given I'm happily running an AM3 XIII 6-core 4Ghz motherboard that is military grade, which /also/ sports the nfe(4). Oh, and it wasn't cheap. :) However, the one I'm working with here is only an AM2 with a 2-core. > > CC'ing Yong-Hyeon Pyun to assist in debugging/explaining the above > error. Yong-Hyeon Pyun kindly responded to my message to @amd64 || @net, and requested much the same info - which I provided. I /assumed/ that it was an amd64 issue, as this box is the only amd64 of the lot, that, or because it was the only 8.1 - the others are all <= 8.0. After posting/ responding @amd64 && @net, I noticed the NFS patch in the @stable, and figured it worth asking about. > > In the interim, can you please provide output from the following > commands: > > > # uname -a > # dmesg (please include relevant nfe details and miibus) SEE ATTACHED FILE: dmesg.boot.udns0 > # pciconf -lvcb (please only include nfe-related output) nfe0@pci0:0:10:0: class=0x068000 card=0x73101462 chip=0x005710de rev=0xf3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA Network Bus Enumerator (CK804)' class = bridge bar [10] = type Memory, range 32, base 0xf9ffb000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xc080, size 8, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > # netstat -ind (you can XX-out MACs and/or IPs) Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop nfe0 1500 00:19:db:22:74:87 729801 0 0 529029 182 0 0 nfe0 1500 XXX.XXX.XXX.0 XXX.XXX.XXX.26 695750 - - 631781 - - - nfe0 1500 fe80:1::219:d fe80:1::219:dbff: 0 - - 6 - - - plip0 1500 0 0 0 0 0 0 0 lo0 16384 315 0 0 315 0 0 0 lo0 16384 127.0.0.0/8 127.0.0.1 313 - - 313 - - - lo0 16384 ::1/128 ::1 0 - - 2 - - - lo0 16384 fe80:3::1/64 fe80:3::1 0 - - 0 - - - > # ifconfig -a (you can XX-out MACs and/or IPs) nfe0: flags=8843 metric 0 mtu 1500 options=8010b ether 00:19:db:22:74:87 inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 inet6 fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 nd6 options=3 > > > Thanks. Thank you again Jeremy, for your thoughtful reply. --Chris > > > -- > | 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" > > -- ------=_20110111042005_78835 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello Jeremy, and thank you for your reply. On Tue, January 11, 2011 12:17 am, Jeremy Chadwick wrote: > On Mon, Jan 10, 2011 at 11:40:37PM -0800, Chris H wrote: > >> Greetings, and thank you for the "heads up". >> On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote: >> >>> I just commited a patch (r217242) to head. Anyone who is using client >>> side NFS on FreeBSD8.n should apply this patch. It is also available at: >>> http://people.freebsd.org/~rmacklem/krpc.patch >>> >>> >>> >>> It fixes a problem where the kernel rpc assumes that 4 bytes of data >>> exists in the first mbuf without checking. If the data straddles multiple >>> mbufs, it uses garbage and then a typical case will wedge for a minute or so >>> until it times out and establishes a new TCP connection. It also replaces >>> m_pullup() with m_copydata(), since m_pullup() can fail for rare cases when >>> there is data available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail >>> when mbuf allocation is constrainted, for example.) >>> >>> Thanks to john.gemignani at isilon.com for spotting this problem, rick >>> >> >> I just fired a message off to @amd64 && @net because I am seeing messages >> like: >> >> >> nfe0: tx v2 error 0x6204 >> >> >> on a recent 8.1/amd64 install which is connected to an 8.0/i386 via NFS. They >> both run NFS client && server, and they both utilize mount points on each >> other. They are only 2 of several interconnected servers. The others are all >> 7x/i386. But I only see these messages on the 8.1/amd64, >> and only when connected to, and utilizing mounts on the 8.0/i386, and even >> then, only when the data exceeds ~1.5Mb. I guess I'm asking if the messages >> I'm receiving are related to the >> corrections your patch provides. Or should I keep looking for the answer for >> the messages I am seeing. > > The above message is coming from the nfe(4) NIC driver, not from NFS. > It's possible that NFS tickles some kind of I/O throughput quirk in > drivers such as nfe(4), given that they're intended for cheap desktops. Well, I'd argue that point given I'm happily running an AM3 XIII 6-core 4Ghz motherboard that is military grade, which /also/ sports the nfe(4). Oh, and it wasn't cheap. :) However, the one I'm working with here is only an AM2 with a 2-core. > > CC'ing Yong-Hyeon Pyun to assist in debugging/explaining the above > error. Yong-Hyeon Pyun kindly responded to my message to @amd64 || @net, and requested much the same info - which I provided. I /assumed/ that it was an amd64 issue, as this box is the only amd64 of the lot, that, or because it was the only 8.1 - the others are all <= 8.0. After posting/ responding @amd64 && @net, I noticed the NFS patch in the @stable, and figured it worth asking about. > > In the interim, can you please provide output from the following > commands: > > > # uname -a > # dmesg (please include relevant nfe details and miibus) SEE ATTACHED FILE: dmesg.boot.udns0 > # pciconf -lvcb (please only include nfe-related output) nfe0@pci0:0:10:0: class=0x068000 card=0x73101462 chip=0x005710de rev=0xf3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA Network Bus Enumerator (CK804)' class = bridge bar [10] = type Memory, range 32, base 0xf9ffb000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xc080, size 8, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > # netstat -ind (you can XX-out MACs and/or IPs) Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop nfe0 1500 00:19:db:22:74:87 729801 0 0 529029 182 0 0 nfe0 1500 XXX.XXX.XXX.0 XXX.XXX.XXX.26 695750 - - 631781 - - - nfe0 1500 fe80:1::219:d fe80:1::219:dbff: 0 - - 6 - - - plip0 1500 0 0 0 0 0 0 0 lo0 16384 315 0 0 315 0 0 0 lo0 16384 127.0.0.0/8 127.0.0.1 313 - - 313 - - - lo0 16384 ::1/128 ::1 0 - - 2 - - - lo0 16384 fe80:3::1/64 fe80:3::1 0 - - 0 - - - > # ifconfig -a (you can XX-out MACs and/or IPs) nfe0: flags=8843 metric 0 mtu 1500 options=8010b ether 00:19:db:22:74:87 inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 inet6 fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 nd6 options=3 > > > Thanks. Thank you again Jeremy, for your thoughtful reply. --Chris > > > -- > | 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" > > -- ------=_20110111042005_78835 Content-Type: application/octet-stream; name="dmesg.boot.udns0" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot.udns0" Q29weXJpZ2h0IChjKSAxOTkyLTIwMTAgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjEtUkVMRUFTRS1wMiAjMDogRnJpIERlYyAzMSAx OTowNzoyNSBQU1QgMjAxMAogICAgcm9vdEB1ZG5zMDovdXNyL29iai91c3Ivc3JjL3N5cy9YSUkg YW1kNjQKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4ZmZm ZmZmZmY4MGE0NjAwMC4KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDIyMTEzMzkzMDcg SHoKQ1BVOiBBTUQgQXRobG9uKHRtKSA2NCBYMiBEdWFsIENvcmUgUHJvY2Vzc29yIDQyMDArICgz NTExLjM0LU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkF1dGhlbnRpY0FNRCIgIElkID0g MHg0MGZiMiAgRmFtaWx5ID0gZiAgTW9kZWwgPSA0YiAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9 MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1U UlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4K ICBGZWF0dXJlczI9MHgyMDAxPFNTRTMsQ1gxNj4KICBBTUQgRmVhdHVyZXM9MHhlYTUwMDgwMDxT WVNDQUxMLE5YLE1NWCssRkZYU1IsUkRUU0NQLExNLDNETm93ISssM0ROb3chPgogIEFNRCBGZWF0 dXJlczI9MHgxZjxMQUhGLENNUCxTVk0sRXh0QVBJQyxDUjg+CkwxIDJNQiBkYXRhIFRMQjogOCBl bnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpMMSAyTUIgaW5zdHJ1Y3Rpb24gVExCOiA4IGVudHJp ZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDRLQiBkYXRhIFRMQjogMzIgZW50cmllcywgZnVsbHkg YXNzb2NpYXRpdmUKTDEgNEtCIGluc3RydWN0aW9uIFRMQjogMzIgZW50cmllcywgZnVsbHkgYXNz b2NpYXRpdmUKTDEgZGF0YSBjYWNoZTogNjQga2J5dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVz L3RhZywgMi13YXkgYXNzb2NpYXRpdmUKTDEgaW5zdHJ1Y3Rpb24gY2FjaGU6IDY0IGtieXRlcywg NjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDItd2F5IGFzc29jaWF0aXZlCkwyIDJNQiB1bmlm aWVkIFRMQjogMCBlbnRyaWVzLCBkaXNhYmxlZC9ub3QgcHJlc2VudApMMiA0S0IgZGF0YSBUTEI6 IDUxMiBlbnRyaWVzLCA0LXdheSBhc3NvY2lhdGl2ZQpMMiA0S0IgaW5zdHJ1Y3Rpb24gVExCOiA1 MTIgZW50cmllcywgNC13YXkgYXNzb2NpYXRpdmUKTDIgdW5pZmllZCBjYWNoZTogNTEyIGtieXRl cywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDE2LXdheSBhc3NvY2lhdGl2ZQpyZWFsIG1l bW9yeSAgPSAxMDczNzQxODI0ICgxMDI0IE1CKQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6CjB4 MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5YmZmZiwgNjM0ODgwIGJ5dGVzICgxNTUg cGFnZXMpCjB4MDAwMDAwMDAwMGE3NDAwMCAtIDB4MDAwMDAwMDAzZTE4MGZmZiwgMTAzMDgwMzQ1 NiBieXRlcyAoMjUxNjYxIHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAxMDIzMDM3NDQwICg5NzUgTUIp CkFDUEkgQVBJQyBUYWJsZTogPEEgTSBJICBPRU1BUElDID4KSU5UUjogQWRkaW5nIGxvY2FsIEFQ SUMgMSBhcyBhIHRhcmdldApGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVj dGVkOiAyIENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShzKQogY3B1MCAo QlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKQVBJQzogQ1BVIDAgaGFz IEFDUEkgSUQgMQpBUElDOiBDUFUgMSBoYXMgQUNQSSBJRCAyCng4NmJpb3M6ICAgSVZUIDB4MDAw MDAwLTB4MDAwNGZmIGF0IDB4ZmZmZmZmMDAwMDAwMDAwMAp4ODZiaW9zOiAgU1NFRyAweDAxMDAw MC0weDAxZmZmZiBhdCAweGZmZmZmZjgwMDAwMGUwMDAKeDg2YmlvczogIEVCREEgMHgwOWYwMDAt MHgwOWZmZmYgYXQgMHhmZmZmZmYwMDAwMDlmMDAwCng4NmJpb3M6ICAgUk9NIDB4MGEwMDAwLTB4 MGVmZmZmIGF0IDB4ZmZmZmZmMDAwMDBhMDAwMApVTEU6IHNldHVwIGNwdSAwClVMRTogc2V0dXAg Y3B1IDEKQUNQSTogUlNEUCAweGY5MWEwIDAwMDE0ICh2MCBBQ1BJQU0pCkFDUEk6IFJTRFQgMHgz ZmZkMDAwMCAwMDAzOCAodjEgQSBNIEkgIE9FTVJTRFQgIDEwMDAwNzIyIE1TRlQgMDAwMDAwOTcp CkFDUEk6IEZBQ1AgMHgzZmZkMDIwMCAwMDA4NCAodjIgQSBNIEkgIE9FTUZBQ1AgIDEwMDAwNzIy IE1TRlQgMDAwMDAwOTcpCkFDUEk6IERTRFQgMHgzZmZkMDQ0MCAwNDUxMiAodjEgIDFBREpUIDFB REpUMDA3IDAwMDAwMDA3IElOVEwgMjAwNTExMTcpCkFDUEk6IEZBQ1MgMHgzZmZkZTAwMCAwMDA0 MApBQ1BJOiBBUElDIDB4M2ZmZDAzOTAgMDAwNzAgKHYxIEEgTSBJICBPRU1BUElDICAxMDAwMDcy MiBNU0ZUIDAwMDAwMDk3KQpBQ1BJOiBNQ0ZHIDB4M2ZmZDA0MDAgMDAwM0MgKHYxIEEgTSBJICBP RU1NQ0ZHICAxMDAwMDcyMiBNU0ZUIDAwMDAwMDk3KQpBQ1BJOiBPRU1CIDB4M2ZmZGUwNDAgMDAw NjAgKHYxIEEgTSBJICBBTUlfT0VNICAxMDAwMDcyMiBNU0ZUIDAwMDAwMDk3KQpBQ1BJOiBTU0RU IDB4M2ZmZDQ5NjAgMDAyMDYgKHYxIEEgTSBJICBQT1dFUk5PVyAwMDAwMDAwMSBBTUQgIDAwMDAw MDAxKQpNQURUOiBGb3VuZCBJTyBBUElDIElEIDIsIEludGVycnVwdCAwIGF0IDB4ZmVjMDAwMDAK aW9hcGljMDogQ2hhbmdpbmcgQVBJQyBJRCB0byAyCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwg ODI1OUEncyAtPiBpbnRwaW4gMApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSAwLCBp cnEgMApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEgOQppb2FwaWMwOiBp bnRwaW4gOSB0cmlnZ2VyOiBsZXZlbApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSAx NCwgaXJxIDE0Ck1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDE1LCBpcnEgMTUKaW9h cGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAg ICBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAw eGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAw MDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEw MDAwIGVycjogMHgwMDAwMDBmMCBwbWM6IDB4MDAwMTA0MDAKc25kX3VuaXRfaW5pdCgpIHU9MHgw MGZmODAwMCBbNTEyXSBkPTB4MDAwMDdjMDAgWzMyXSBjPTB4MDAwMDAzZmYgWzEwMjRdCmZlZWRl cl9yZWdpc3Rlcjogc25kX3VuaXQ9LTEgc25kX21heGF1dG92Y2hhbnM9MTYgbGF0ZW5jeT01IGZl ZWRlcl9yYXRlX21pbj0xIGZlZWRlcl9yYXRlX21heD0yMDE2MDAwIGZlZWRlcl9yYXRlX3JvdW5k PTI1CndsYW46IDw4MDIuMTEgTGluayBMYXllcj4Ka2JkOiBuZXcgYXJyYXkgc2l6ZSA0CmtiZDEg YXQga2JkbXV4MAptZW06IDxtZW1vcnk+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKbnVsbDogPG51 bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJl LCBZYXJyb3c+CmNwdWN0bDogYWNjZXNzIHRvIE1TUiByZWdpc3RlcnMvY3B1aWQgaW5mby4KVkVT QTogaW5mb3JtYXRpb24gYmxvY2sKMDAwMCAgIDU2IDQ1IDUzIDQxIDAwIDAzIDAwIDAxIDAwIDAx IDAxIDAwIDAwIDAwIDIyIDAwCjAwMTAgICAwMCAwMSBlMCAwMCA5OCA2MiAwNyAwMSAwMCAwMSAx YSAwMSAwMCAwMSAyZiAwMQowMDIwICAgMDAgMDEgMDAgMDEgMDEgMDEgMDIgMDEgMDMgMDEgMDQg MDEgMDUgMDEgMDYgMDEKMDAzMCAgIDA3IDAxIDBlIDAxIDBmIDAxIDExIDAxIDEyIDAxIDE0IDAx IDE1IDAxIDE3IDAxCjAwNDAgICAxOCAwMSAxYSAwMSAxYiAwMSAzMCAwMSAzMSAwMSAzMiAwMSAz MyAwMSAzNCAwMQowMDUwICAgMzUgMDEgMzYgMDEgM2QgMDEgM2UgMDEgNDUgMDEgNDYgMDEgNGEg MDEgZmYgZmYKMDA2MCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwCjAwNzAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMAowMDgwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAKMDA5MCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CjAwYTAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAow MGIwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDBj MCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwZDAg ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMGUwICAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDBmMCAgIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxMDAgICA0ZSA1 NiA0OSA0NCA0OSA0MSAwMCA0ZSA1NiA0OSA0NCA0OSA0MSAyMCA0MyA2ZgowMTEwICAgNzIgNzAg NmYgNzIgNjEgNzQgNjkgNmYgNmUgMDAgNDcgMzkgMzggMjAgNDIgNmYKMDEyMCAgIDYxIDcyIDY0 IDIwIDJkIDIwIDMwIDM1IDM2IDMxIDMwIDMwIDMwIDMyIDAwIDQzCjAxMzAgICA2OCA2OSA3MCAy MCA1MiA2NSA3NiAyMCAyMCAyMCAwMCAwMCAwMCAwMCAwMCAwMAowMTQwICAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDE1MCAgIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxNjAgICAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMTcwICAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDE4MCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxOTAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMWEwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDFiMCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAxYzAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMAowMWQwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAKMDFlMCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwCjAxZjAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMApWRVNBOiAzMCBtb2RlKHMpIGZvdW5kClZFU0E6IHYzLjAsIDE0MzM2ayBt ZW1vcnksIGZsYWdzOjB4MSwgbW9kZSB0YWJsZToweGZmZmZmZjgwMDAwNWYwMjIgKDEwMDAwMjIp ClZFU0E6IE5WSURJQQpWRVNBOiBOVklESUEgQ29ycG9yYXRpb24gRzk4IEJvYXJkIC0gMDU2MTAw MDIgQ2hpcCBSZXYgICAKaW86IDxJL08+CmhwdHJyOiBSb2NrZXRSQUlEIDE3eHgvMnh4eCBTQVRB IGNvbnRyb2xsZXIgZHJpdmVyIHYxLjIKYWNwaTA6IDxBIE0gSSBPRU1SU0RUPiBvbiBtb3RoZXJi b2FyZApQQ0llOiBNZW1vcnkgTWFwcGVkIGNvbmZpZ3VyYXRpb24gYmFzZSBAIDB4ZTAwMDAwMDAK aW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBsYXBpYyAwIHZlY3RvciA0 OAphY3BpMDogW01QU0FGRV0KYWNwaTA6IFtJVEhSRUFEXQpBQ1BJOiBFeGVjdXRlZCAxIGJsb2Nr cyBvZiBtb2R1bGUtbGV2ZWwgZXhlY3V0YWJsZSBBTUwgY29kZQphY3BpMDogUG93ZXIgQnV0dG9u IChmaXhlZCkKYWNwaTA6IHdha2V1cCBjb2RlIHZhIDB4ZmZmZmZmODAwMDAwMzAwMCBwYSAweDQw MDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLlNCUkcuUElNQyAtPiBidXMgMCBkZXYg MSBmdW5jIDAKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6 IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgM2ZmMDAwMDAgKDMpIGZhaWxlZApBQ1BJIHRpbWVyOiAx LzIgMS8yIDEvMiAxLzIgMS8yIDEvMiAxLzIgMS8yIDEvMiAxLzIgLT4gMTAKVGltZWNvdW50ZXIg IkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIw OiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NDAwOC0weDQwMGIgb24gYWNw aTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUwOiBzd2l0Y2hpbmcgdG8gZ2VuZXJpYyBD eCBtb2RlCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKcGNpX2xpbmswOiAgICAgICAgSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDE2IDE3IDE4IDE5CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAx NiAxNyAxOCAxOQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcg MTggMTkKcGNpX2xpbmsxOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0 aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CiAgVmFsaWRhdGlv biAgICAgICAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQogIEFmdGVyIERpc2FibGUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKcGNpX2xpbmsyOiAgICAgICAgSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4g ICAgIDAgIDE2IDE3IDE4IDE5CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAw ICAxNiAxNyAxOCAxOQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYg MTcgMTggMTkKcGNpX2xpbmszOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJ bml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CiAgVmFsaWRh dGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQogIEFmdGVyIERpc2Fi bGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKcGNpX2xpbms0OiAgICAgICAg SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAgNSAg IE4gICAgIDAgIDIwIDIxIDIyIDIzCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAg ICAwICAyMCAyMSAyMiAyMwogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MjAgMjEgMjIgMjMKcGNpX2xpbms1OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxNSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCiAgVmFs aWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwogIEFmdGVyIERp c2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbms2OiAgICAg ICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAx MCAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBO ICAgICAwICAyMCAyMSAyMiAyMwogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMjAgMjEgMjIgMjMKcGNpX2xpbms3OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAgMyAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCiAg VmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbms4OiAg ICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUg ICBOICAgICAwICAyMCAyMSAyMiAyMwogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbms5OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDIwIDIxIDIyIDIz CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwogIEFm dGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbmsx MDogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAg IDAgICAgNiAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAy NTUgICBOICAgICAwICAyMCAyMSAyMiAyMwogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xpbmsxMTogICAgICAgSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIy IDIzCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwog IEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpX2xp bmsxMjogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzCiAgVmFsaWRhdGlvbiAgICAgICAgICAw ICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMwogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9y dCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2kw OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgw MDVlLCByZXZpZD0weGE0Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0w NS04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4 MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRl dj0weDAwNTAsIHJldmlkPTB4ZjEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xLCBmdW5jPTAKCWNs YXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMGYsIHN0YXRy ZWc9MHgwMGEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTBk ZSwgZGV2PTB4MDA1MiwgcmV2aWQ9MHhhMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTEsIGZ1bmM9 MQoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMSwg c3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCglpbnRwaW49YSwg aXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZGMwMCwgc2l6ZSAgNSwgZW5hYmxlZAoJ bWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg1MDAwLCBzaXplICA2LCBl bmFibGVkCgltYXBbMjRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDYwMDAsIHNp emUgIDYsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBIChzcmMgXFxf U0JfLkxTTUI6MCkKcGNpX2xpbms5OiBQaWNrZWQgSVJRIDIwIHdpdGggd2VpZ2h0IDAKcGNpYjA6 IHNsb3QgMSBJTlRBIHJvdXRlZCB0byBpcnEgMjAgdmlhIFxcX1NCXy5MU01CCmZvdW5kLT4JdmVu ZG9yPTB4MTBkZSwgZGV2PTB4MDA1YSwgcmV2aWQ9MHhhMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTIsIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVn PTB4MDAwNywgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0w eDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCglp bnRwaW49YSwgaXJxPTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVu dCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjlmZmYwMDAsIHNp emUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMi5JTlRBIChzcmMgXFxf U0JfLkxVQjA6MCkKcGNpX2xpbms0OiBQaWNrZWQgSVJRIDIxIHdpdGggd2VpZ2h0IDAKcGNpYjA6 IHNsb3QgMiBJTlRBIHJvdXRlZCB0byBpcnEgMjEgdmlhIFxcX1NCXy5MVUIwCnVua25vd246IFJl c2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZjlmZmYwMDAKb2hj aSBlYXJseTogU01NIGFjdGl2ZSwgcmVxdWVzdCBvd25lciBjaGFuZ2UKZm91bmQtPgl2ZW5kb3I9 MHgxMGRlLCBkZXY9MHgwMDViLCByZXZpZD0weGE0Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9Miwg ZnVuYz0xCgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgw MDA2LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBp bj1iLCBpcnE9MTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBE MAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjlmZmVjMDAsIHNpemUg IDgsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMi5JTlRCIChzcmMgXFxfU0Jf LkxVQjI6MCkKcGNpX2xpbms1OiBQaWNrZWQgSVJRIDIyIHdpdGggd2VpZ2h0IDAKcGNpYjA6IHNs b3QgMiBJTlRCIHJvdXRlZCB0byBpcnEgMjIgdmlhIFxcX1NCXy5MVUIyCnVua25vd246IFJlc2Vy dmVkIDB4MTAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmOWZmZWMwMApmb3VuZC0+ CXZlbmRvcj0weDEwZGUsIGRldj0weDAwNTksIHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD00LCBmdW5jPTAKCWNsYXNzPTA0LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNt ZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwNSAoMTI1MCBu cykKCWludHBpbj1hLCBpcnE9MwoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBj dXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQ0MDAs IHNpemUgIDgsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNl IDB4ZDAwMCwgc2l6ZSAgOCwgZW5hYmxlZAoJbWFwWzE4XTogdHlwZSBNZW1vcnksIHJhbmdlIDMy LCBiYXNlIDB4ZjlmZmQwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuNC5JTlRBIChzcmMgXFxfU0JfLkxBQ0k6MCkKcGNpX2xpbms3OiBQaWNrZWQgSVJRIDIz IHdpdGggd2VpZ2h0IDAKcGNpYjA6IHNsb3QgNCBJTlRBIHJvdXRlZCB0byBpcnEgMjMgdmlhIFxc X1NCXy5MQUNJCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDA1MywgcmV2aWQ9MHhmMwoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTYsIGZ1bmM9MAoJY2xhc3M9MDEtMDEtOGEsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1h eGxhdD0weDAxICgyNTAgbnMpCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmZhMCwgc2l6ZSAg NCwgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAwNTQsIHJldmlkPTB4ZjMK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD03LCBmdW5jPTAKCWNsYXNzPTAxLTAxLTg1LCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBt YXhsYXQ9MHgwMSAoMjUwIG5zKQoJaW50cGluPWEsIGlycT02Cglwb3dlcnNwZWMgMiAgc3VwcG9y dHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4Y2MwMCwgc2l6ZSAgMywgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFu Z2UgMzIsIGJhc2UgMHhjODgwLCBzaXplICAyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIEkvTyBQ b3J0LCByYW5nZSAzMiwgYmFzZSAweGM4MDAsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxY106IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4YzQ4MCwgc2l6ZSAgMiwgZW5hYmxlZAoJbWFw WzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhjNDAwLCBzaXplICA0LCBlbmFi bGVkCgltYXBbMjRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmOWZmYzAwMCwgc2l6 ZSAxMiwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC43LklOVEEgKHNyYyBcXF9T Ql8uTFNBMDowKQpwY2lfbGluazEwOiBQaWNrZWQgSVJRIDIwIHdpdGggd2VpZ2h0IDEKcGNpYjA6 IHNsb3QgNyBJTlRBIHJvdXRlZCB0byBpcnEgMjAgdmlhIFxcX1NCXy5MU0EwCmZvdW5kLT4JdmVu ZG9yPTB4MTBkZSwgZGV2PTB4MDA1YywgcmV2aWQ9MHhmMgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTksIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVn PTB4MDAwNCwgc3RhdHJlZz0weDAwYTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0w eDAwICgwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDAyICg1MDAgbnMpCmZv dW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDA1NywgcmV2aWQ9MHhmMwoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTEwLCBmdW5jPTAKCWNsYXNzPTA2LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAxICgyNTAgbnMpLCBtYXhsYXQ9MHgxNCAo NTAwMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBE MiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4 ZjlmZmIwMDAsIHNpemUgMTIsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdl IDMyLCBiYXNlIDB4YzA4MCwgc2l6ZSAgMywgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBm b3IgMC4xMC5JTlRBIChzcmMgXFxfU0JfLkxNQUM6MCkKcGNpX2xpbms2OiBQaWNrZWQgSVJRIDIx IHdpdGggd2VpZ2h0IDEKcGNpYjA6IHNsb3QgMTAgSU5UQSByb3V0ZWQgdG8gaXJxIDIxIHZpYSBc XF9TQl8uTE1BQwpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAwNWQsIHJldmlkPTB4ZjMK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xMSwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlw ZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA0LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6 PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBE MAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdApmb3VuZC0+CXZlbmRvcj0weDEwZGUs IGRldj0weDAwNWQsIHJldmlkPTB4ZjMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xMiwgZnVuYz0w CgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA0LCBz dGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJp dApmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAwNWQsIHJldmlkPTB4ZjMKCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0xMywgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBt ZmRldj0wCgljbWRyZWc9MHgwMDA0LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1 cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdApmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAw NWQsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xNCwgZnVuYz0wCgljbGFzcz0w Ni0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4 MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MTggKDYwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdApmb3Vu ZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDExMDAsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9 MCwgc2xvdD0yNCwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0x CgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDExMDEsIHJldmlkPTB4MDAKCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0yNCwgZnVuYz0xCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDExMDIsIHJldmlkPTB4MDAKCWRv bWFpbj0wLCBidXM9MCwgc2xvdD0yNCwgZnVuYz0yCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDExMDMsIHJldmlkPTB4 MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNCwgZnVuYz0zCgljbGFzcz0wNi0wMC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpwY2kwOiA8bWVtb3J5PiBhdCBkZXZpY2UgMC4wIChubyBkcml2 ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNp MAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBk ZXZpY2UgMS4xIChubyBkcml2ZXIgYXR0YWNoZWQpCm9oY2kwOiA8T0hDSSAoZ2VuZXJpYykgVVNC IGNvbnRyb2xsZXI+IG1lbSAweGY5ZmZmMDAwLTB4ZjlmZmZmZmYgaXJxIDIxIGF0IGRldmljZSAy LjAgb24gcGNpMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMSAoUENJIElSUSAyMSkgdG8gbGFw aWMgMCB2ZWN0b3IgNDkKb2hjaTA6IFtNUFNBRkVdCm9oY2kwOiBbSVRIUkVBRF0KdXNidXMwOiA8 T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCmVoY2kwOiA8TlZJRElBIG5G b3JjZTQgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmOWZmZWMwMC0weGY5ZmZlY2ZmIGlycSAy MiBhdCBkZXZpY2UgMi4xIG9uIHBjaTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjIgKFBDSSBJ UlEgMjIpIHRvIGxhcGljIDAgdmVjdG9yIDUwCmVoY2kwOiBbTVBTQUZFXQplaGNpMDogW0lUSFJF QURdCmVoY2kwOiBEb29yYmVsbCB3b3JrYXJvdW5kIGVuYWJsZWQKdXNidXMxOiBFSENJIHZlcnNp b24gMS4wCnVzYnVzMTogPE5WSURJQSBuRm9yY2U0IFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhj aTAKcGNpMDogPG11bHRpbWVkaWEsIGF1ZGlvPiBhdCBkZXZpY2UgNC4wIChubyBkcml2ZXIgYXR0 YWNoZWQpCmF0YXBjaTA6IDxuVmlkaWEgbkZvcmNlIENLODA0IFVETUExMzMgY29udHJvbGxlcj4g cG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGZmYTAtMHhmZmFmIGF0 IGRldmljZSA2LjAgb24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQg MHgyMCB0eXBlIDQgYXQgMHhmZmEwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0 YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MWYwCmF0 YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2CmF0 YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMDogc3RhdDA9MHg1 MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiBzdGF0MT0weDAwIGVycj0weDAxIGxz Yj0weDAwIG1zYj0weDAwCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2Vz PTB4MQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gbGFwaWMgMCB2 ZWN0b3IgNTEKYXRhMDogW01QU0FGRV0KYXRhMDogW0lUSFJFQURdCmF0YTE6IDxBVEEgY2hhbm5l bCAxPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTgg dHlwZSA0IGF0IDB4MTcwCmF0YXBjaTA6IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMg dHlwZSA0IGF0IDB4Mzc2CmF0YTE6IHJlc2V0IHRwMSBtYXNrPTAwIG9zdGF0MD1mZiBvc3RhdDE9 ZmYKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTUgKElTQSBJUlEgMTUpIHRvIGxhcGljIDAgdmVj dG9yIDUyCmF0YTE6IFtNUFNBRkVdCmF0YTE6IFtJVEhSRUFEXQphdGFwY2kxOiA8blZpZGlhIG5G b3JjZSBDSzgwNCBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHhjYzAwLTB4Y2MwNywweGM4ODAt MHhjODgzLDB4YzgwMC0weGM4MDcsMHhjNDgwLTB4YzQ4MywweGM0MDAtMHhjNDBmIG1lbSAweGY5 ZmZjMDAwLTB4ZjlmZmNmZmYgaXJxIDIwIGF0IGRldmljZSA3LjAgb24gcGNpMAphdGFwY2kxOiBS ZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhjNDAwCmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDIwIChQQ0kgSVJRIDIwKSB0byBsYXBpYyAwIHZlY3RvciA1MwphdGFw Y2kxOiBbTVBTQUZFXQphdGFwY2kxOiBbSVRIUkVBRF0KYXRhcGNpMTogUmVzZXJ2ZWQgMHgxMDAw IGJ5dGVzIGZvciByaWQgMHgyNCB0eXBlIDMgYXQgMHhmOWZmYzAwMAphdGEyOiA8QVRBIGNoYW5u ZWwgMD4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEw IHR5cGUgNCBhdCAweGNjMDAKYXRhcGNpMTogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgx NCB0eXBlIDQgYXQgMHhjODgwCmF0YTI6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAw MDAxMjMKYXRhMjogcmVzZXQgdHAxIG1hc2s9MDEgb3N0YXQwPTUwIG9zdGF0MT0wMAphdGEyOiBz dGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTI6IHJlc2V0IHRwMiBzdGF0 MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MQphdGEyOiBbTVBTQUZFXQphdGEyOiBbSVRIUkVBRF0K YXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTEKYXRhcGNpMTogUmVzZXJ2ZWQgMHg4IGJ5 dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHhjODAwCmF0YXBjaTE6IFJlc2VydmVkIDB4NCBi eXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4YzQ4MAphdGEzOiBTQVRBIGNvbm5lY3QgdGlt ZW91dCBzdGF0dXM9MDAwMDAwMDAKYXRhMzogW01QU0FGRV0KYXRhMzogW0lUSFJFQURdCnBjaWIx OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDkuMCBvbiBwY2kwCnBjaWIxOiAgIGRv bWFpbiAgICAgICAgICAgIDAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBz dWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MC0weDAKcGNp YjE6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpYjE6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVk IGJyaWRnZS4KcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpMTogZG9tYWluPTAsIHBo eXNpY2FsIGJ1cz0xCm5mZTA6IDxOVklESUEgbkZvcmNlNCBDSzgwNCBNQ1A5IE5ldHdvcmtpbmcg QWRhcHRlcj4gcG9ydCAweGMwODAtMHhjMDg3IG1lbSAweGY5ZmZiMDAwLTB4ZjlmZmJmZmYgaXJx IDIxIGF0IGRldmljZSAxMC4wIG9uIHBjaTAKbmZlMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZv ciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmOWZmYjAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gbmZl MApjaXBoeTA6IDxWaXRlc3NlIFZTQzg2MDEgMTAvMTAwLzEwMDBUWCBQSFk+IFBIWSAxIG9uIG1p aWJ1czAKY2lwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvCm5mZTA6IGJwZiBhdHRhY2hlZApu ZmUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxOTpkYjoyMjo3NDo4NwpuZmUwOiBbTVBTQUZFXQpu ZmUwOiBbRklMVEVSXQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxMS4w IG9uIHBjaTAKcGNpYjI6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMjogICBzZWNvbmRhcnkg YnVzICAgICAyCnBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDIKcGNpYjI6ICAgSS9PIGRlY29k ZSAgICAgICAgMHgwLTB4MApwY2liMjogICBubyBwcmVmZXRjaGVkIGRlY29kZQpwY2kyOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTIKcGNpYjM6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTIuMCBvbiBwY2kwCnBjaWIzOiAgIGRv bWFpbiAgICAgICAgICAgIDAKcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMwpwY2liMzogICBz dWJvcmRpbmF0ZSBidXMgICAzCnBjaWIzOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MC0weDAKcGNp YjM6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMK cGNpMzogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0zCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDEzLjAgb24gcGNpMApwY2liNDogICBkb21haW4gICAgICAgICAgICAwCnBj aWI0OiAgIHNlY29uZGFyeSBidXMgICAgIDQKcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAgNApw Y2liNDogICBJL08gZGVjb2RlICAgICAgICAweDAtMHgwCnBjaWI0OiAgIG5vIHByZWZldGNoZWQg ZGVjb2RlCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaTQ6IGRvbWFpbj0wLCBwaHlz aWNhbCBidXM9NApwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxNC4wIG9u IHBjaTAKcGNpYjU6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNTogICBzZWNvbmRhcnkgYnVz ICAgICA1CnBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDUKcGNpYjU6ICAgSS9PIGRlY29kZSAg ICAgICAgMHhlMDAwLTB4ZWZmZgpwY2liNTogICBtZW1vcnkgZGVjb2RlICAgICAweGZhMDAwMDAw LTB4ZmViZmZmZmYKcGNpYjU6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhkMDAwMDAwMC0weGRmZmZm ZmZmCnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1CnBjaTU6IGRvbWFpbj0wLCBwaHlzaWNh bCBidXM9NQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDA2ZTQsIHJldmlkPTB4YTEKCWRv bWFpbj0wLCBidXM9NSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06 IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZkMDAwMDAwLCBzaXplIDI0LCBlbmFibGVk CnBjaWI1OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmQwMDAwMDAtMHhmZGZmZmZmZjogZ29v ZAoJbWFwWzE0XTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGQw MDAwMDAwLCBzaXplIDI4LCBlbmFibGVkCnBjaWI1OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4 ZDAwMDAwMDAtMHhkZmZmZmZmZjogZ29vZAoJbWFwWzFjXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0 LCBiYXNlIDB4ZmEwMDAwMDAsIHNpemUgMjUsIGVuYWJsZWQKcGNpYjU6IHJlcXVlc3RlZCBtZW1v cnkgcmFuZ2UgMHhmYTAwMDAwMC0weGZiZmZmZmZmOiBnb29kCgltYXBbMjRdOiB0eXBlIEkvTyBQ b3J0LCByYW5nZSAzMiwgYmFzZSAweGVjMDAsIHNpemUgIDcsIGVuYWJsZWQKcGNpYjU6IHJlcXVl c3RlZCBJL08gcmFuZ2UgMHhlYzAwLTB4ZWM3ZjogaW4gcmFuZ2UKcGNpYjU6IG1hdGNoZWQgZW50 cnkgZm9yIDUuMC5JTlRBIChzcmMgXFxfU0JfLkxOS0M6MCkKcGNpX2xpbmsyOiBQaWNrZWQgSVJR IDE2IHdpdGggd2VpZ2h0IDAKcGNpYjU6IHNsb3QgMCBJTlRBIHJvdXRlZCB0byBpcnEgMTYgdmlh IFxcX1NCXy5MTktDCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4ZWMw MC0weGVjN2YgbWVtIDB4ZmQwMDAwMDAtMHhmZGZmZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZmZmYs MHhmYTAwMDAwMC0weGZiZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTUKYW1kdGVt cDA6IDxBTUQgSzggVGhlcm1hbCBTZW5zb3JzPiBvbiBob3N0YjMKYWNwaV9idXR0b24wOiA8UG93 ZXIgQnV0dG9uPiBvbiBhY3BpMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcw LTB4NzEgaXJxIDggb24gYWNwaTAKYXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkg Y2xvY2sgKHJlc29sdXRpb24gMTAwMDAwMHVzKQp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+ IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiA0IChJU0EgSVJRIDQpIHRvIGxhcGljIDAgdmVjdG9yIDU0CnVhcnQwOiBbRklM VEVSXQp1YXJ0MDogZmFzdCBpbnRlcnJ1cHQKcHBjMDogdXNpbmcgZXh0ZW5kZWQgSS9PIHBvcnQg cmFuZ2UKcHBjMDogU1BQCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmIGly cSA3IG9uIGFjcGkwCnBwYzA6IEdlbmVyaWMgY2hpcHNldCAoTklCQkxFLW9ubHkpIGluIENPTVBB VElCTEUgbW9kZQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA3IChJU0EgSVJRIDcpIHRvIGxhcGlj IDAgdmVjdG9yIDU1CnBwYzA6IFtNUFNBRkVdCnBwYzA6IFtJVEhSRUFEXQpwcGJ1czA6IDxQYXJh bGxlbCBwb3J0IGJ1cz4gb24gcHBjMApwbGlwMDogPFBMSVAgbmV0d29yayBpbnRlcmZhY2U+IG9u IHBwYnVzMApwbGlwMDogYnBmIGF0dGFjaGVkCnBsaXAwOiBbTVBTQUZFXQpwbGlwMDogW0lUSFJF QURdCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogW01QU0FGRV0KbHB0MDogW0lUSFJF QURdCmxwdDA6IEludGVycnVwdC1kcml2ZW4gcG9ydApwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBw cGJ1czAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4 NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAK YXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDY1CmF0a2Jk OiBrZXlib2FyZCBJRCAweDQxYWIgKDIpCmtiZDAgYXQgYXRrYmQwCmtiZDA6IGF0a2JkMCwgQVQg MTAxLzEwMiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCmlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDEgKElTQSBJUlEgMSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTYKYXRrYmQwOiBbR0lBTlQt TE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCnBz bWNwbnAwOiA8UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKcHNtMDogY3VycmVudCBj b21tYW5kIGJ5dGU6MDA2NQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKaW9h cGljMDogcm91dGluZyBpbnRwaW4gMTIgKElTQSBJUlEgMTIpIHRvIGxhcGljIDAgdmVjdG9yIDU3 CnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IFtJVEhSRUFEXQpwc20wOiBtb2RlbCBJbnRlbGxp TW91c2UgRXhwbG9yZXIsIGRldmljZSBJRCA0LTAwLCA1IGJ1dHRvbnMKcHNtMDogY29uZmlnOjAw MDAwMDAwLCBmbGFnczowMDAwMDAwOCwgcGFja2V0IHNpemU6NApwc20wOiBzeW5jbWFzazowOCwg c3luY2JpdHM6MDAKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKYXRr YmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdHJ0YzogYXRydGMwIGFs cmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApwcGM6IHBwYzAgYWxyZWFkeSBleGlzdHM7IHNraXBw aW5nIGl0CnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnVhcnQ6IHVhcnQwIGFs cmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9u LVBuUCBkZXZpY2VzCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2Ew CnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGti ZDEsIHRlcm1pbmFsIGVtdWxhdG9yOiBzY3Rla2VuICh0ZWtlbiB0ZXJtaW5hbCkKdmdhMDogPEdl bmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYg b24gaXNhMApmZGMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2YwIGlycSA2IGRycSAyIG9u IGlzYTAKdWFydDE6IDxuczgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZm IGlycSAzIG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCnBv d2Vybm93MDogPFBvd2VyTm93ISBLOD4gb24gY3B1MApwb3dlcm5vdzE6IDxQb3dlck5vdyEgSzg+ IG9uIGNwdTEKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVk CmxpbnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAxMDA1MTU0 MzIgSHoKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDM1MTEzMzkzMDcgSHogcXVhbGl0eSAt MTAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdmxhbjogaW5pdGlhbGl6ZWQs IHVzaW5nIGhhc2ggdGFibGVzIHdpdGggY2hhaW5pbmcKTGludXggRUxGIGV4ZWMgaGFuZGxlciBp bnN0YWxsZWQKbG8wOiBicGYgYXR0YWNoZWQKaHB0cnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQu CmF0YTA6IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDAwMDAxCmF0YTA6IE5ldyBkZXZpY2VzOiAw MDAwMDAwMQp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogNDgwTWJw cyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDxuVmlkaWE+IGF0IHVzYnVzMAp1aHViMDog PG5WaWRpYSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXMwCnVnZW4xLjE6IDxuVmlkaWE+IGF0IHVzYnVzMQp1aHViMTogPG5WaWRpYSBFSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCmF0 YTAtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEwMCBjYWJsZT04MCB3aXJl CmF0YXBpY2FtOiBhdGFwaWNhbTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmRyaXZlciBi dWc6IFVuYWJsZSB0byBzZXQgZGV2Y2xhc3MgKGRldm5hbWU6IChudWxsKSkKYWQwOiBzZXR0aW5n IFVETUExMDAKYWQwOiAzOTI2Nk1CIDxJQzM1TDA0MEFWVk4wNyAwIFZBMk9BRzBBPiBhdCBhdGEw LW1hc3RlciBVRE1BMTAwIAphZDA6IDgwNDE4MjQwIHNlY3RvcnMgWzc5NzgwQy8xNkgvNjNTXSAx NiBzZWN0b3JzL2ludGVycnVwdCAxIGRlcHRoIHF1ZXVlCkdFT006IG5ldyBkaXNrIGFkMAphZDA6 IG5WaWRpYSBjaGVjazEgZmFpbGVkCmFkMDogQWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkMDogTFNJ ICh2MykgY2hlY2sxIGZhaWxlZAphZDA6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQKYWQwOiBGcmVl QlNEIGNoZWNrMSBmYWlsZWQKYXRhMTogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMDAwMDAKYXRh MTogTmV3IGRldmljZXM6IDAwMDAwMDAwCmF0YTI6IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDAw MDAxCmF0YTI6IE5ldyBkZXZpY2VzOiAwMDAwMDAwMQphdGEyLW1hc3RlcjogcGlvPVBJTzQgd2Rt YT1XRE1BMiB1ZG1hPVVETUExMzMgY2FibGU9NDAgd2lyZQphZDQ6IHNldHRpbmcgVURNQTEwMAph ZDQ6IDc2MjkzTUIgPFNBTVNVTkcgSEQwODBISi9QIFpIMTAwLTM0PiBhdCBhdGEyLW1hc3RlciBV RE1BMTAwIFNBVEEgM0diL3MKYWQ0OiAxNTYyNTAwMDAgc2VjdG9ycyBbMTU1MDA5Qy8xNkgvNjNT XSAxNiBzZWN0b3JzL2ludGVycnVwdCAxIGRlcHRoIHF1ZXVlCkdFT006IG5ldyBkaXNrIGFkNAph ZDQ6IG5WaWRpYSBjaGVjazEgZmFpbGVkCmFkNDogQWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkNDog TFNJICh2MykgY2hlY2sxIGZhaWxlZAphZDQ6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQKYWQ0OiBG cmVlQlNEIGNoZWNrMSBmYWlsZWQKYXRhMzogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMDAwMDAK YXRhMzogTmV3IGRldmljZXM6IDAwMDAwMDAwCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApTTVA6IEFQ IENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAwMCAgIFZFUjogMHg4 MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3 MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRp bWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAwMDBmMCBwbWM6IDB4 MDAwMTA0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNCAoSVNBIElSUSA0KSB0byBsYXBpYyAx IHZlY3RvciA0OAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIGxhcGlj IDEgdmVjdG9yIDQ5CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE0IChJU0EgSVJRIDE0KSB0byBs YXBpYyAxIHZlY3RvciA1MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMCAoUENJIElSUSAyMCkg dG8gbGFwaWMgMSB2ZWN0b3IgNTEKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjIgKFBDSSBJUlEg MjIpIHRvIGxhcGljIDEgdmVjdG9yIDUyClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMSB1 c2J1czAKdWh1YjA6IDggcG9ydHMgd2l0aCA4IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3Qg bW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEK Um9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMxCnVodWIxOiA4IHBvcnRzIHdpdGggOCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czEKdWdlbjEu MjogPHZlbmRvciAweDA0MDI+IGF0IHVzYnVzMQp1bWFzczA6IDx2ZW5kb3IgMHgwNDAyIFVTQiAy LjAgU3RvcmFnZSBEZXZpY2UsIGNsYXNzIDAvMCwgcmV2IDIuMDAvMS4wMywgYWRkciAyPiBvbiB1 c2J1czEKdW1hc3MwOiAgU0NTSSBvdmVyIEJ1bGstT25seTsgcXVpcmtzID0gMHgwMDAwCnVtYXNz MDoyOjA6LTE6IEF0dGFjaGVkIHRvIHNjYnVzMgpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVm czovZGV2L2FkNHMxYQoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBEb3duIHJldmluZyBQcm90 b2NvbCBWZXJzaW9uIGZyb20gMiB0byAwPwpjdF90b190cyhbMjAxMS0wMS0wNSAxOTo1MTowNF0p ID0gMTI5NDI1NzA2NC4wMDAwMDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKKHBy b2JlMDp1bWFzcy1zaW0wOjA6MDowKTogU0NTSSBzdGF0dXMgZXJyb3IKKHByb2JlMDp1bWFzcy1z aW0wOjA6MDowKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAgMCAwIDAgMCAwIAoocHJvYmUwOnVt YXNzLXNpbTA6MDowOjApOiBDQU0gc3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcgoocHJvYmUwOnVt YXNzLXNpbTA6MDowOjApOiBTQ1NJIHN0YXR1czogQ2hlY2sgQ29uZGl0aW9uCihwcm9iZTA6dW1h c3Mtc2ltMDowOjA6MCk6IFNDU0kgc2Vuc2U6IE5PVCBSRUFEWSBhc2M6M2EsMCAoTWVkaXVtIG5v dCBwcmVzZW50KQoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBFcnJvciA2LCBVbnJldHJ5YWJs ZSBlcnJvcgpzZzAgYXQgdW1hc3Mtc2ltMCBidXMgMCBzY2J1czIgdGFyZ2V0IDAgbHVuIDAKc2cw OiA8X05FQyBEVkRfUlcgTkQtMjUxMEEgMi4wND4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2 aWNlIApzZzA6IFNlcmlhbCBOdW1iZXIgMDAwNDIyMjIyMDAwMDAxMjAyNTEKc2cwOiA0MC4wMDBN Qi9zIHRyYW5zZmVycwpwYXNzMCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBs dW4gMApwYXNzMDogPF9ORUMgRFZEX1JXIE5ELTI1MTBBIDIuMDQ+IFJlbW92YWJsZSBDRC1ST00g U0NTSS0wIGRldmljZSAKcGFzczA6IFNlcmlhbCBOdW1iZXIgMDAwNDIyMjIyMDAwMDAxMjAyNTEK cGFzczA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCkdFT006IG5ldyBkaXNrIGNkMAooY2QwOnVtYXNz LXNpbTA6MDowOjApOiBTQ1NJIHN0YXR1cyBlcnJvcgooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBS RUFEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAgMCAwIDAgMCAwIAooY2QwOnVtYXNzLXNpbTA6 MDowOjApOiBDQU0gc3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcgooY2QwOnVtYXNzLXNpbTA6MDow OjApOiBTQ1NJIHN0YXR1czogQ2hlY2sgQ29uZGl0aW9uCihjZDA6dW1hc3Mtc2ltMDowOjA6MCk6 IFNDU0kgc2Vuc2U6IE5PVCBSRUFEWSBhc2M6M2EsMCAoTWVkaXVtIG5vdCBwcmVzZW50KQooY2Qw OnVtYXNzLXNpbTA6MDowOjApOiBFcnJvciA2LCBVbnJldHJ5YWJsZSBlcnJvcgpjZDAgYXQgdW1h c3Mtc2ltMCBidXMgMCBzY2J1czIgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8X05FQyBEVkRfUlcgTkQt MjUxMEEgMi4wND4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNlIApjZDA6IFNlcmlhbCBO dW1iZXIgMDAwNDIyMjIyMDAwMDAxMjAyNTEKY2QwOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpjZDA6 IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBu b3QgcHJlc2VudAooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBTQ1NJIHN0YXR1cyBlcnJvcgooY2Qw OnVtYXNzLXNpbTA6MDowOjApOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAgMCAwIDAg MCAwIAooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBDQU0gc3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJv cgooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBTQ1NJIHN0YXR1czogQ2hlY2sgQ29uZGl0aW9uCihj ZDA6dW1hc3Mtc2ltMDowOjA6MCk6IFNDU0kgc2Vuc2U6IE5PVCBSRUFEWSBhc2M6M2EsMCAoTWVk aXVtIG5vdCBwcmVzZW50KQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBFcnJvciA2LCBVbnJldHJ5 YWJsZSBlcnJvcgooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBTQ1NJIHN0YXR1cyBlcnJvcgooY2Qw OnVtYXNzLXNpbTA6MDowOjApOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAgMCAwIDAg MCAwIAooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBDQU0gc3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJv cgooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBTQ1NJIHN0YXR1czogQ2hlY2sgQ29uZGl0aW9uCihj ZDA6dW1hc3Mtc2ltMDowOjA6MCk6IFNDU0kgc2Vuc2U6IE5PVCBSRUFEWSBhc2M6M2EsMCAoTWVk aXVtIG5vdCBwcmVzZW50KQooY2QwOnVtYXNzLXNpbTA6MDowOjApOiBFcnJvciA2LCBVbnJldHJ5 YWJsZSBlcnJvcgp0c190b19jdCgxMjk0MjU3MDg3LjU5MzcyODY3NSkgPSBbMjAxMS0wMS0wNSAx OTo1MToyN10K ------=_20110111042005_78835-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 13:24:04 2011 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 B37DF106566C for ; Tue, 11 Jan 2011 13:24:04 +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 713098FC0C for ; Tue, 11 Jan 2011 13:24:03 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B407619E038; Tue, 11 Jan 2011 14:24:02 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id DEFBF19E036; Tue, 11 Jan 2011 14:23:59 +0100 (CET) Message-ID: <4D2C59EF.7050107@quip.cz> Date: Tue, 11 Jan 2011 14:23:59 +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.16) Gecko/20101123 SeaMonkey/2.0.11 MIME-Version: 1.0 To: Dan Langille References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> <4D2BD0A7.9060003@langille.org> In-Reply-To: <4D2BD0A7.9060003@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , John Hawkes-Reed Subject: Re: ZFS - hot spares : automatic or 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: Tue, 11 Jan 2011 13:24:04 -0000 Dan Langille wrote: > On 1/4/2011 11:52 AM, John Hawkes-Reed wrote: [...] >> As far as our testing could discover, it's not automatic. >> >> I wrote some Ugly Perl that's called by devd when it spots a drive-fail >> event, which seemed to DTRT when simulating a failure by pulling a drive. > > Without such a script, what is the value in creating hot spares? IMHO hot spares are totally useless in the current state (in FreeBSD). I think there should be some strong warning somewhere (in man zpool?). Some users can be misleaded otherwise. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 16:12:37 2011 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 BF1EF1065673 for ; Tue, 11 Jan 2011 16:12:37 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id 782DB8FC14 for ; Tue, 11 Jan 2011 16:12:37 +0000 (UTC) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id E830E21F24; Tue, 11 Jan 2011 16:12:35 +0000 (GMT) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com (HELO propellor.libeljournal.com) (77.103.165.1) (smtp-auth username hirez, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (AES256-SHA encrypted) ESMTPSA; Tue, 11 Jan 2011 16:12:35 +0000 Received: from propellor.libeljournal.com (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id E7FF2170BB; Tue, 11 Jan 2011 16:10:47 +0000 (GMT) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by propellor.libeljournal.com (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpZMBaVt44j4; Tue, 11 Jan 2011 16:10:43 +0000 (GMT) Received: from [172.16.0.10] (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTPA id BE92517076; Tue, 11 Jan 2011 16:10:43 +0000 (GMT) Message-ID: <4D2C810E.2070007@libeljournal.com> Date: Tue, 11 Jan 2011 16:10:54 +0000 From: John Hawkes-Reed User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Langille References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> <4D2BD0A7.9060003@langille.org> In-Reply-To: <4D2BD0A7.9060003@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gradwell-MongoId: 4d2c8173.11ef5-532c-2 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: hirez Cc: freebsd-stable Subject: Re: ZFS - hot spares : automatic or 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: Tue, 11 Jan 2011 16:12:37 -0000 On 11/01/2011 03:38, Dan Langille wrote: > On 1/4/2011 11:52 AM, John Hawkes-Reed wrote: >> On 04/01/2011 03:08, Dan Langille wrote: >>> Hello folks, >>> >>> I'm trying to discover if ZFS under FreeBSD will automatically pull in a >>> hot spare if one is required. >>> >>> This raised the issue back in March 2010, and refers to a PR opened in >>> May 2009 >>> >>> * http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007943.html >>> * http://www.freebsd.org/cgi/query-pr.cgi?pr=134491 >>> >>> In turn, the PR refers to this March 2010 post referring to using devd >>> to accomplish this task. >>> >>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055686.html >>> >>> Does the above represent the the current state? >>> >>> I ask because I just ordered two more HDD to use as spares. Whether they >>> sit on the shelf or in the box is open to discussion. >> >> As far as our testing could discover, it's not automatic. >> >> I wrote some Ugly Perl that's called by devd when it spots a drive-fail >> event, which seemed to DTRT when simulating a failure by pulling a drive. > > Without such a script, what is the value in creating hot spares? We went through that loop in the office. We're used to the way the Netapps work here, where often one's first notice of a failed disk is a visit from the courier with a replacement. (I'm only half joking) In the end, writing enough perl to swap in the spare disk made much more sense than paging the relevant admin on disk-fail and expecting them to be able to type straight at 4AM. Our thinking is that having a hot spare allows us to do the physical disk-swap in office hours, rather than (for instance) running in a degraded state over a long weekend. If it's of interest, I'll see if I can share the code. -- JH-R From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 16:21:14 2011 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 87910106566B for ; Tue, 11 Jan 2011 16:21:14 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1062C8FC13 for ; Tue, 11 Jan 2011 16:21:13 +0000 (UTC) Received: by ewy24 with SMTP id 24so9735944ewy.13 for ; Tue, 11 Jan 2011 08:21:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.156.84 with SMTP id l62mr7788578wek.58.1294762872712; Tue, 11 Jan 2011 08:21:12 -0800 (PST) Received: by 10.216.72.69 with HTTP; Tue, 11 Jan 2011 08:21:12 -0800 (PST) X-Originating-IP: [209.66.78.50] In-Reply-To: References: <20110111021316.GA84376@icarus.home.lan> Date: Tue, 11 Jan 2011 11:21:12 -0500 Message-ID: From: Mark Saad To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: Enabling DDB prevent kernel from panicing 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, 11 Jan 2011 16:21:14 -0000 On Mon, Jan 10, 2011 at 10:29 PM, Mark Saad wrote: > On Mon, Jan 10, 2011 at 9:13 PM, Jeremy Chadwick > wrote: >> On Mon, Jan 10, 2011 at 07:42:21PM -0500, Mark Saad wrote: >>> On Mon, Jan 10, 2011 at 6:59 PM, =C2=A0 wrote: >>> > Hello, Mark >>> > >>> > 2011/1/11 Mark Saad : >>> >> All >>> >> This was originally posted to hackers@ >>> >> >>> >> I have a good question that I cant find an answer for. I believe >>> >> found a kernel bug in 7.3-RELEASE that prevents me from booting 64-b= it >>> >> kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: pag= e >>> >> fault while in kernel mode " . The hardware works fine in 7.2-RELEAS= E >>> >> amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . >>> >> >>> >> In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using t= he >>> >> stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if th= is >>> >> issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC >>> >> kernel using patches sources and tried to boot and I got the same >>> >> crash. >>> >> >>> >> =C2=A0Next I rebuilt the kernel with KDB and DDB to see if I could g= et a >>> >> core-dump of the system. I also set loader.conf to >>> >> >>> >> kernel=3D"kernel.DEBUG" >>> >> kern.dumpdev=3D"/dev/da0s1b" >>> >> >>> >> Next I pxebooted =C2=A0the box and the system does not crash on boot= up, it >>> >> will easily load a nfs root and work fine. So I copied my debug >>> >> kernel, and loader.conf to the local disk and rebooted and it boots >>> >> fine from the local disk . >>> > >>> > Looks like a race condition. >>> > Well, you don't need to compile KDB and DDB, just add >>> > >>> > makeoptions DEBUG=3D-g >>> > >>> > into your kernel config file and rebuild kernel. >>> > >>> > Then after you got a crash dump you can easy debug it (see FreeBSD >>> > Developers Handbok): >>> > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-g= db.html >>> > >>> > >>> > wbr, >>> > Nickolas >>> > >>> >>> =C2=A0 Sorry let me clarify the issue, When you install a generic >>> 7.3-RELEASE amd64 on some of the HP servers I use, the kernel panics >>> in boot up >>> when it probes the sio driver . Here is a part of my dmesg.boot file >>> >>> atkbd0: [ITHREAD] >>> psm0: irq 12 on atkbdc0 >>> psm0: [GIANT-LOCKED] >>> psm0: [ITHREAD] >>> psm0: model Generic PS/2 mouse, device ID 0 >>> sio0: configured irq 4 not in bitmap of probed irqs 0 >>> sio0: port may not be enabled >>> sio0: configured irq 4 not in bitmap of probed irqs 0 >>> sio0: port may not be enabled >>> sio0: port 0x3f8-0x3ff irq 4 on acpi0 >>> sio0: type 16550A >>> sio0: [FILTER] >>> Say about here in the boot up , is where the box crashes with the >>> above noted error. >>> >>> If I then boot the same box off a 7.1-RELEASE amd64 netboot server , >>> mount the local disks of the 7.3-RELEASE install and edit the >>> /boot/device.hints and comment out the sio hints like this >>> >>> hint.vga.0.at=3D"isa" >>> hint.sc.0.at=3D"isa" >>> hint.sc.0.flags=3D"0x100" >>> #hint.sio.0.at=3D"isa" >>> #hint.sio.0.port=3D"0x3F8" >>> #hint.sio.0.flags=3D"0x10" >>> #hint.sio.0.irq=3D"4" >>> #hint.sio.1.at=3D"isa" >>> #hint.sio.1.port=3D"0x2F8" >>> #hint.sio.1.irq=3D"3" >>> #hint.sio.2.at=3D"isa" >>> #hint.sio.2.disabled=3D"1" >>> #hint.sio.2.port=3D"0x3E8" >>> #hint.sio.2.irq=3D"5" >>> #hint.sio.3.at=3D"isa" >>> #hint.sio.3.disabled=3D"1" >>> #hint.sio.3.port=3D"0x2E8" >>> #hint.sio.3.irq=3D"9" >>> hint.ppc.0.at=3D"isa" >>> hint.ppc.0.irq=3D"7" >>> >>> then boot the server off the local disks , the server boots correctly. >>> >>> The odd thing was, I rebuilt a debug 7.3-RELEASE amd64 kernel on >>> another working server, and installed it on the broken server and >>> booted it off the local disks, with out any changes to the hints file >>> and the server booted correctly and I was able to manually break out >>> into the debugger , but nothing looked wrong . >> >> The sio(4) driver has been deprecated in RELENG_8, which uses uart(4). >> uart(4) is better in a lot of regards, and should also be available for >> use on RELENG_7 but you'll need to adjust /etc/ttys to refer to the new >> device names (ttyuX vs. ttydX), plus add the uart entries to >> /boot/device.hints. >> > I found that too, and I was thinking about the change but its going to > require a source build of the kernel to fix that along with a bunch of > manual work > on my side that =C2=A0I would rather not do . > >> I'm mentioning this as a workaround. >> >> Also worth considering is that the sio(4) ISA probe may be touching >> something Bad(tm) as a result, so you might try adding the following >> lines to your loader.conf (not a typo) to disable sio(4) entries >> entirely: >> >> hint.sio.0.disabled=3D"1" >> hint.sio.1.disabled=3D"1" >> >> And see if that improves things. =C2=A0If it does, remove the sio.1.disa= bled >> entry and see if that suffices. > > I'll try the hint disabling but how is that different from removing > the hint outright ? > so adding the hint to the loader.conf worked . my understanding of how the loader's 4th bits work make me believe we can use either file for this hint . but I am still unsure of why the stock hint breaks the box, where as no hint works and disabling port via hint works. the other thing is the port works in its intended way with no hint or disabled hint. >> >>> So to sum this up there is something broken in 7.3-RELEASE but I cant >>> figure out what. This server works with a generic install of >>> 7.1-RELEASE 7.2-RELEASE , 6.1-RELEASE, 6.2-RELEASE and 6.4-RELEASE in >>> both amd64 and i386 , but not 7.3-RELEASE in amd64 . It also worked in >>> 7.4-RC1 . >>> >>> avg recommended I see what changed from r212964 =C2=A0to r212994 I am >>> currently looking into this . Has anyone seen this before ? >> >> If the server works fine with 7.4-PRERELEASE/RC1, why are you caring >> about 7.3? =C2=A0Upgrade. =C2=A0:-) >> > > Can't just upgrade we did a bunch of work on 7.3-RELEASE and we are > going to stay on 7.3-RELEASE until 2012 for various reasons. > >> -- >> | Jeremy Chadwick =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 jdc@paro= dius.com | >> | Parodius Networking =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.parodius.com/ | >> | UNIX Systems Administrator =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Mountain View, CA, USA | >> | Making life hard for others since 1977. =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 PGP 4BD6C0CB | >> >> > > So anyone what to take a stab on flying with out a device.hints ? > > > -- > > mark saad | nonesuch@longcount.org > I am still looking at what changed in 7.4 that could fix this. --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 02:04:09 2011 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 C4872106564A for ; Wed, 12 Jan 2011 02:04:09 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5E81E8FC16 for ; Wed, 12 Jan 2011 02:04:08 +0000 (UTC) Received: by wwf26 with SMTP id 26so91597wwf.31 for ; Tue, 11 Jan 2011 18:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=aIEpd5K6jXe/09mJ1DLPFns6Yp3t9VNUPdLLEJUmxEw=; b=S52fPnY78ce6F67v9dGC0futlOxXKXPes0oRUOerWtAKwzeoj6G+bI32lNz3/flG9Y JW9nd/CVXiTCjwEzKbrhbc4pCZ+h/1dwE2u/DFNepMEhM8OHU/6/x/1yvojWVMxaWR0b odcmaoHBoDimC0FdkIq8CwItZ6mBdCxZZEzJI= 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=sfa7UoNYHpZkvLSDnS2j8pAj1TCFIq9CFpSAtkrvc3znXoYJNwHyVPLetlsp0fp3dF ei46ZcuDzo2fYOnnl6eXtU/tLG+XC8Mljx101qoF6PHwxGVDVXzo7uqulrFU2Z1PxNmc ytVeuFvOKo0ZUjOOIVayEv0BxJGcPiZWOFWxo= MIME-Version: 1.0 Received: by 10.227.57.131 with SMTP id c3mr293734wbh.188.1294795972586; Tue, 11 Jan 2011 17:32:52 -0800 (PST) Received: by 10.227.59.3 with HTTP; Tue, 11 Jan 2011 17:32:52 -0800 (PST) Date: Wed, 12 Jan 2011 02:32:52 +0100 Message-ID: From: Oliver Pinter To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: sed is broken under freebsd? 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, 12 Jan 2011 02:04:09 -0000 hi all! The freebsd versions of sed contained a bug/regression, when \n char can i subsitue, gsed not affected with this bug: FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 aa@xxx ~> echo axa | sed s/x/\n/g ana aa@xxx ~> echo axa | sed s/x/'\n'/g ana it is FreeBSD 8.1 base systems sed aa@centaur:~$ uname -a Linux centaur 2.6.18-6-686 #1 SMP Thu Aug 20 21:56:59 UTC 2009 i686 GNU/Lin= ux aa@centaur:~$ echo axa | sed s/x/\n/g ana aa@centaur:~$ echo axa | sed s/x/'\n'/g a a aa@centaur:~$ sed --version GNU sed verzi=C3=B3 4.1.5 ural2:~$ uname -a SunOS ural2 5.8 Generic_117350-62 sun4u sparc ural2:~$ echo axa | sed s/x/\n/g ana ural2:~$ echo axa | sed s/x/'\n'/g a a ural2:~$ sed --version GNU sed version 4.2.1 From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 03:24:48 2011 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 AEF60106566B; Wed, 12 Jan 2011 03:24:47 +0000 (UTC) (envelope-from prvs=19938927b1=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id EC14E8FC13; Wed, 12 Jan 2011 03:24:46 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 12 Jan 2011 03:13:40 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 12 Jan 2011 03:13:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50011959913.msg; Wed, 12 Jan 2011 03:13:40 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=19938927b1=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <97E367EFBB774F9BA06B0D6DFF14039D@multiplay.co.uk> From: "Steven Hartland" To: "Vogel, Jack" , "TAKAHASHI Yoshihiro" , References: <20110108.124018.59640143160055980.nyan@FreeBSD.org> <1DB50624F8348F48840F2E2CF6040A9D014BC5519A@orsmsx508.amr.corp.intel.com> Date: Wed, 12 Jan 2011 03:13:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Supermicro Bladeserver 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, 12 Jan 2011 03:24:48 -0000 Out of interest what change was that? ----- Original Message ----- From: "Vogel, Jack" To: "TAKAHASHI Yoshihiro" ; Cc: ; Sent: Monday, January 10, 2011 9:17 PM Subject: RE: Supermicro Bladeserver We attempted to repro this problem with the 82566DM (ich8 btw) in house and failed, it worked correctly for my testers. Oh, and just so the mailing lists have an update, the SM Blade problem was not an issue in the driver, it was a local change in the loader.conf that caused the problem. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 06:13:11 2011 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 ABE2C106564A; Wed, 12 Jan 2011 06:13:11 +0000 (UTC) (envelope-from robin@icir.org) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by mx1.freebsd.org (Postfix) with ESMTP id 8BD388FC0C; Wed, 12 Jan 2011 06:13:11 +0000 (UTC) Received: from empire.icsi.berkeley.edu (empire.ICSI.Berkeley.EDU [192.150.186.169]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p0C5bCvc020421; Tue, 11 Jan 2011 21:37:12 -0800 (PST) Received: by empire.icsi.berkeley.edu (Postfix, from userid 502) id B0DDF4193862; Tue, 11 Jan 2011 21:37:11 -0800 (PST) Date: Tue, 11 Jan 2011 21:37:11 -0800 From: Robin Sommer To: Steven Hartland Message-ID: <20110112053711.GC34444@icir.org> References: <20110108.124018.59640143160055980.nyan@FreeBSD.org> <1DB50624F8348F48840F2E2CF6040A9D014BC5519A@orsmsx508.amr.corp.intel.com> <97E367EFBB774F9BA06B0D6DFF14039D@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97E367EFBB774F9BA06B0D6DFF14039D@multiplay.co.uk> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-net@freebsd.org, jfvogel@gmail.com, freebsd-stable@freebsd.org, "Vogel, Jack" Subject: Re: Supermicro Bladeserver 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, 12 Jan 2011 06:13:11 -0000 On Wed, Jan 12, 2011 at 03:13 -0000, you wrote: > Out of interest what change was that? As what seems to have been a left-over from a debugging session a long time ago, I had MSI disabled in loader.conf. That's not supported by the driver. So simply reenabling that solved my problem. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin@icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 07:18:32 2011 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 6B885106566C for ; Wed, 12 Jan 2011 07:18:32 +0000 (UTC) (envelope-from cliftonr@oz.volcano.org) Received: from oz.volcano.org (oz.volcano.org [64.65.105.124]) by mx1.freebsd.org (Postfix) with ESMTP id 3B20C8FC0C for ; Wed, 12 Jan 2011 07:18:31 +0000 (UTC) Received: by oz.volcano.org (Postfix, from userid 1001) id 6686C50824; Tue, 11 Jan 2011 21:00:09 -1000 (HST) Date: Tue, 11 Jan 2011 21:00:09 -1000 From: Clifton Royston To: Oliver Pinter Message-ID: <20110112070009.GB20924@lava.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: sed is broken under freebsd? 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, 12 Jan 2011 07:18:32 -0000 On Wed, Jan 12, 2011 at 02:32:52AM +0100, Oliver Pinter wrote: > hi all! > > The freebsd versions of sed contained a bug/regression, when \n char > can i subsitue, gsed not affected with this bug: > FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 > UTC 2010 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > i386 > aa@xxx ~> echo axa | sed s/x/\n/g > ana > aa@xxx ~> echo axa | sed s/x/'\n'/g > ana Different than GNU is not a bug. I have 7.3 here. It behaves as the above, which is how the man page says it should work. The following is how the man page specifies you can substitute a newline, by prefacing a quoted actual newline with a backslash: $ echo axa | sed 's/x/\ > /g' a a That's how I remember classic sed behaving (Unix v7 or thereabouts.) -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 08:13:55 2011 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 0DF1C106566C for ; Wed, 12 Jan 2011 08:13:55 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id CC5318FC18 for ; Wed, 12 Jan 2011 08:13:54 +0000 (UTC) Received: (qmail 55010 invoked by uid 503); 12 Jan 2011 07:47:13 -0000 Date: Tue, 11 Jan 2011 23:47:13 -0800 From: Marcus Reid To: Attila Nagy Message-ID: <20110112074713.GB52770@blazingdot.com> References: <4D0A09AF.3040005@FreeBSD.org> <4D1F7008.3050506@fsn.hu> <4D29A198.4070107@fsn.hu> <20110110085756.GA1744@garage.freebsd.pl> <4D2B423F.2000403@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2B423F.2000403@fsn.hu> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Pawel Jakub Dawidek , Artem Belevich Subject: Re: New ZFSv28 patchset for 8-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, 12 Jan 2011 08:13:55 -0000 On Mon, Jan 10, 2011 at 06:30:39PM +0100, Attila Nagy wrote: > >why and we can't ask him now, I'm afraid. I just sent an e-mail to > > What happened to him? Oops, I was thinking of something else. http://valleywag.gawker.com/383763/freebsd-developer-kip-macy-arrested-for-tormenting-tenants Marcus From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 10:21:03 2011 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 AD200106564A for ; Wed, 12 Jan 2011 10:21:03 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD148FC13 for ; Wed, 12 Jan 2011 10:21:02 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0CAKxRO019037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Jan 2011 21:21: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.4/8.14.4) with ESMTP id p0CAKwxS046440 for ; Wed, 12 Jan 2011 21:20:58 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p0CAKw5F046439 for freebsd-stable@freebsd.org; Wed, 12 Jan 2011 21:20:58 +1100 (EST) (envelope-from peter) Date: Wed, 12 Jan 2011 21:20:58 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org Message-ID: <20110112102058.GA46319@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: classes and kernel_cookie was Re: Specifying root mount options on diskless boot. 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, 12 Jan 2011 10:21:03 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jan-09 10:32:48 -0500, Daniel Feenberg wrote: >Daniel Braniss writes... >> I have it pxebooting nicely and running with an NFS root >> but it then reports locking problems: devd, syslogd, moused (and maybe Actually, that was me, not Daniel. >Are you mounting /var via nfs? Yes. I'm using "diskless" in the traditional Sun workstation style - the system itself is running with a normal filesystem which is all NFS mounted from another (FreeBSD) server. I'm aware of the MFS-based read-only approach but didn't want to use that approach. >I note that the response to your message from "danny" offers the ability= =20 >to pass arguments to the nfs mount command, Actually, my original mail indicates that that I'm aware you can pass options to the NFS mount command (passing nolockd will solve my problem). My issue is that there are several incompatible approaches and none of them work by default. > but also seems to offer a fix=20 >for the fact that "classes" are not supported under PXE: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/90368 I wasn't previously aware of that PR but it is consistent with my findings. On 2011-Jan-10 10:52:34 +0200, Daniel Braniss wrote: >I'm willing to try and add the missing pieces, but I need some better expl= anantion as to what they are, for example, I have no clue what the >kernel_cookie is used for, nor what the ${class} is all about. I'm also happy to patch the code but feel that both PXE and BOOTP should be consistent and I'm not sure which is the correct approach. >BTW, it would be kind if the line in the pxeboot(8): > As PXE is still in its infancy ... >can be changed :-) Well, there are still some issues with PXE booting FreeBSD - eg as discussed here. But, I agree, that comment can probably go. --=20 Peter Jeremy --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk0tgIoACgkQ/opHv/APuIfiMwCfag5EU5tt7CcOoBGOF24bzJ0b 2wQAn2EZUYNdi+vn72+YugTaZTu1hlli =bHLv -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 18:21:43 2011 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 82A23106564A for ; Wed, 12 Jan 2011 18:21:43 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 43C578FC15 for ; Wed, 12 Jan 2011 18:21:43 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 9605B13DF5F for ; Wed, 12 Jan 2011 21:02:04 +0300 (MSK) Date: Wed, 12 Jan 2011 21:02:01 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <628423291.20110112210201@serebryakov.spb.ru> To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: geom_label, fstab without device names & swap partition? 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, 12 Jan 2011 18:21:43 -0000 Hello, Stable. Now, with "newfs -L name", geom_label and /dev/ufs/* it is possible to not use device names for FSes in "/etc/fstab" at all. But what to do with swap partitions? How to say, that I want swap on "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 19:03:05 2011 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 50980106564A for ; Wed, 12 Jan 2011 19:03:05 +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 20EF28FC19 for ; Wed, 12 Jan 2011 19:03:05 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pd5yG-0008Eb-Pi; Wed, 12 Jan 2011 14:03:00 -0500 Date: Wed, 12 Jan 2011 14:03:00 -0500 From: Gary Palmer To: Lev Serebryakov Message-ID: <20110112190300.GC61893@in-addr.com> References: <628423291.20110112210201@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <628423291.20110112210201@serebryakov.spb.ru> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: stable@freebsd.org Subject: Re: geom_label, fstab without device names & swap partition? 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, 12 Jan 2011 19:03:05 -0000 On Wed, Jan 12, 2011 at 09:02:01PM +0300, Lev Serebryakov wrote: > Hello, Stable. > > Now, with "newfs -L name", geom_label and /dev/ufs/* it is possible > to not use device names for FSes in "/etc/fstab" at all. But what to > do with swap partitions? How to say, that I want swap on > "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? Have you tried using glabel(8)? It allows you to assign a name to a slice. The slice should not be in use at the time, and if it has a filesystem on it you may have problems as glabel(8) uses the last block for a data store. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 19:08:15 2011 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 F18CA106566C for ; Wed, 12 Jan 2011 19:08:15 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id 009DC8FC1C for ; Wed, 12 Jan 2011 19:08:13 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward15.mail.yandex.net (Yandex) with ESMTP id 2594E445A55B; Wed, 12 Jan 2011 21:57:08 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1294858628; bh=oQ2AItNer0ZDU/S+PP97cmiUv7bR43rNDpbfVGXlmX8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=Z3389fkbgDn87Ku0iI4E8j6HykHDioHwZFjwJ9nhIC7DecgFKvtG1PMYYsd7onDN/ IaF1yVVkSCYBz8F2vHIpPUGA791QNOKwyZH/M5j7t2x22CInT4GEXb/JSsWUU8zEs4 pEIylnlRrng0X7Ypw7OtqIGRinK6VwuB76V948bc= Received: from [178.141.6.249] (dynamic-178-141-6-249.kirov.comstar-r.ru [178.141.6.249]) by smtp12.mail.yandex.net (Yandex) with ESMTPSA id E2E6913E8097; Wed, 12 Jan 2011 21:57:07 +0300 (MSK) Message-ID: <4D2DF979.4000801@yandex.ru> Date: Wed, 12 Jan 2011 21:56:57 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101030 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lev Serebryakov References: <628423291.20110112210201@serebryakov.spb.ru> In-Reply-To: <628423291.20110112210201@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD7C8C9D81A3ED5480755A1FD" Cc: stable@freebsd.org Subject: Re: geom_label, fstab without device names & swap partition? 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, 12 Jan 2011 19:08:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD7C8C9D81A3ED5480755A1FD Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 12.01.2011 21:02, Lev Serebryakov wrote: > Hello, Stable. >=20 > Now, with "newfs -L name", geom_label and /dev/ufs/* it is possible > to not use device names for FSes in "/etc/fstab" at all. But what to > do with swap partitions? How to say, that I want swap on > "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? You can label swap partitions with glabel(8) and use this label in fstab. --=20 WBR, Andrey V. Elsukov --------------enigD7C8C9D81A3ED5480755A1FD 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.16 (FreeBSD) iQEcBAEBAgAGBQJNLfl/AAoJEAHF6gQQyKF6PS0IAJym5rULoDO1BBgfkDGbS9sC hYah+U7FqCJISzbrO7QGlYeGXLqOsKQXwR/x2I49W3pj3xDM9kRnWUvz7TicCTLL kROfoqxcVmjioBhUt91c6FTzaHaEaii0+bNwISYHyspf7PyTGaTxpxcM9Ly9Jc8M wlCcbBg5zBRUzgp0NeJAotiWW67J+5FMCTAlF7vAPHXSntFE4hlHwCq5uT/9kwOm Yt+VWPnUcmkoaFe9OE94i02DUt98P4FvOLmfdpxPmnQ3WA+u7eWIk0H20d7h670R fF2gOca01pX2L59gQlxUFi5fcIZqOl/7lYh6f2V4dBoa8ObSPdhwViWxmrT2mCE= =9EMz -----END PGP SIGNATURE----- --------------enigD7C8C9D81A3ED5480755A1FD-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 19:19:12 2011 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 BFC371065675 for ; Wed, 12 Jan 2011 19:19:12 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 781AC8FC14 for ; Wed, 12 Jan 2011 19:19:12 +0000 (UTC) Received: by qyk8 with SMTP id 8so3883600qyk.13 for ; Wed, 12 Jan 2011 11:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xT5SWpVmqZpeBaFMWYNIeiFOX3sIRlATxHMYPxlJjjA=; b=dcrVdNyFZcBKMbPOv0FE8qCQwq3DTSjXR9YG/IAReUTypgN3bxTVub7l5km5ixMKSa oAgZEzn4g93ItkGDOEKDEx7SDQlrcr7UFYvq0JU1mJB0wmvkuk8UJTdup4TbtEYu2rQi rGFg54H9LYpohedQadHpX9wGCN73U7rRiGSyE= 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=Q9bYKaGv9hNJoqroqGHZK1MuXSimN5RSmRmGkRglZUZLztPO1tQjP05Nb5PkQFu6o4 DhsyT+aqj1dGM1Q0sBHuQzxYjiEg0zgp+8TiSVPDYOpaBrcb9sZ10vVI3882QfnPzblC 82tgKcTnEqkOhf9926l7FjNJ0rl0Pgi9Vwzm0= MIME-Version: 1.0 Received: by 10.229.87.75 with SMTP id v11mr1117874qcl.183.1294858451833; Wed, 12 Jan 2011 10:54:11 -0800 (PST) Received: by 10.229.97.145 with HTTP; Wed, 12 Jan 2011 10:54:11 -0800 (PST) In-Reply-To: <628423291.20110112210201@serebryakov.spb.ru> References: <628423291.20110112210201@serebryakov.spb.ru> Date: Wed, 12 Jan 2011 10:54:11 -0800 Message-ID: From: Freddie Cash To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: geom_label, fstab without device names & swap partition? 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, 12 Jan 2011 19:19:12 -0000 2011/1/12 Lev Serebryakov : > =C2=A0Now, with "newfs -L name", geom_label and /dev/ufs/* it is possible > to not use device names for FSes in "/etc/fstab" at all. But what to > do with swap partitions? How to say, that I want swap on > "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? Use glabel(8) to label the device: # glabel label swap ada0s1b Then point to the label in /etc/fstab: /dev/label/swap swap sw ... --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 20:00:14 2011 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 53DD91065698 for ; Wed, 12 Jan 2011 20:00:14 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BD66B8FC1C for ; Wed, 12 Jan 2011 20:00:12 +0000 (UTC) Received: by bwz12 with SMTP id 12so815292bwz.13 for ; Wed, 12 Jan 2011 12:00:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.64.139 with SMTP id e11mr1095339bki.97.1294862411432; Wed, 12 Jan 2011 12:00:11 -0800 (PST) Received: by 10.204.151.212 with HTTP; Wed, 12 Jan 2011 12:00:10 -0800 (PST) X-Originating-IP: [209.66.78.50] In-Reply-To: References: <628423291.20110112210201@serebryakov.spb.ru> Date: Wed, 12 Jan 2011 15:00:10 -0500 Message-ID: From: Mark Saad To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: geom_label, fstab without device names & swap partition? 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, 12 Jan 2011 20:00:14 -0000 On Wed, Jan 12, 2011 at 1:54 PM, Freddie Cash wrote: > 2011/1/12 Lev Serebryakov : >> =C2=A0Now, with "newfs -L name", geom_label and /dev/ufs/* it is possibl= e >> to not use device names for FSes in "/etc/fstab" at all. But what to >> do with swap partitions? How to say, that I want swap on >> "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? > > Use glabel(8) to label the device: > > # glabel label swap ada0s1b On a side note there is not a simple way to glabel mounted filesystem > > Then point to the label in /etc/fstab: > > /dev/label/swap =C2=A0 =C2=A0swap =C2=A0 sw ... > > > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > 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" > glabel is also great for doing silly things like things like this glabel label leftdrive0 /dev/ad4 glabel label rightdrive0 /dev/ad5 gmirror label -v -b load raid1 leftdrive0 rightdrive0 this way when you get a gmirror status you can easily tell which drive is doing what, red rebuilding etc . --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 20:01:49 2011 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 DB118106564A for ; Wed, 12 Jan 2011 20:01:49 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3198FC1E for ; Wed, 12 Jan 2011 20:01:49 +0000 (UTC) Received: by qwj9 with SMTP id 9so973385qwj.13 for ; Wed, 12 Jan 2011 12:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zgRxY2m1eJFaaIfVT9fco1l5ZzmhQgEGTxKkDTpTG5I=; b=En8JWFD7MvwEwDNOF09bmhHVxyeY6ACr7Qeb7Px9NomK+EFibJXaQw8Hd+DGHlRm7N LinYWC1y42Wc3JWCf5oUl25Ni9AmkZzWPK9W3SVDDEvx5yirWeSRiH4tNMNK8auue5mC itplFJ3PVZqaE6a9X17Yj6CHgJWWNTn5y3afc= 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=aCwdONBQPL7pTazzfmGyySS37SUviEhhCM8UG4SA146Vq4Tu/z0oKZ4P0+tqSJg/na gs/7zr31cEPwM/jST+pzlLlnIZE7nTyYl9pQqp2Ui+gjOe/OPtUhWdOKM0vuCaiQZO39 gWrMhK3ht0/sFm0GGN5jkpv42quGV2SwUtbfQ= MIME-Version: 1.0 Received: by 10.229.88.82 with SMTP id z18mr558651qcl.221.1294862508683; Wed, 12 Jan 2011 12:01:48 -0800 (PST) Received: by 10.229.97.145 with HTTP; Wed, 12 Jan 2011 12:01:48 -0800 (PST) In-Reply-To: References: <628423291.20110112210201@serebryakov.spb.ru> Date: Wed, 12 Jan 2011 12:01:48 -0800 Message-ID: From: Freddie Cash To: Mark Saad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: geom_label, fstab without device names & swap partition? 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, 12 Jan 2011 20:01:49 -0000 On Wed, Jan 12, 2011 at 12:00 PM, Mark Saad wrote: > On Wed, Jan 12, 2011 at 1:54 PM, Freddie Cash wrote: >> 2011/1/12 Lev Serebryakov : >>> =C2=A0Now, with "newfs -L name", geom_label and /dev/ufs/* it is possib= le >>> to not use device names for FSes in "/etc/fstab" at all. But what to >>> do with swap partitions? How to say, that I want swap on >>> "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? >> >> Use glabel(8) to label the device: >> >> # glabel label swap ada0s1b > > On a side note there is not a simple way to glabel mounted filesystem True, but for a swap partition, it's easy to disable swap, label the partition, and re-enable swap. :) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 20:11:15 2011 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 063F5106567A for ; Wed, 12 Jan 2011 20:11:15 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 967E78FC1F for ; Wed, 12 Jan 2011 20:11:14 +0000 (UTC) Received: by eyf6 with SMTP id 6so509155eyf.13 for ; Wed, 12 Jan 2011 12:11:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.71.65 with SMTP id g1mr1088590bkj.178.1294863073275; Wed, 12 Jan 2011 12:11:13 -0800 (PST) Received: by 10.204.151.212 with HTTP; Wed, 12 Jan 2011 12:11:13 -0800 (PST) X-Originating-IP: [209.66.78.50] In-Reply-To: References: <628423291.20110112210201@serebryakov.spb.ru> Date: Wed, 12 Jan 2011 15:11:13 -0500 Message-ID: From: Mark Saad To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: geom_label, fstab without device names & swap partition? 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, 12 Jan 2011 20:11:15 -0000 On Wed, Jan 12, 2011 at 3:01 PM, Freddie Cash wrote: > On Wed, Jan 12, 2011 at 12:00 PM, Mark Saad wrot= e: >> On Wed, Jan 12, 2011 at 1:54 PM, Freddie Cash wrote: >>> 2011/1/12 Lev Serebryakov : >>>> =C2=A0Now, with "newfs -L name", geom_label and /dev/ufs/* it is possi= ble >>>> to not use device names for FSes in "/etc/fstab" at all. But what to >>>> do with swap partitions? How to say, that I want swap on >>>> "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? >>> >>> Use glabel(8) to label the device: >>> >>> # glabel label swap ada0s1b >> >> On a side note there is not a simple way to glabel mounted filesystem > > True, but for a swap partition, it's easy to disable swap, label the > partition, and re-enable swap. =C2=A0:) > > -- > Freddie Cash > fjwcash@gmail.com > Well the thing is I like use glabel in place of a fs label as it makes my devices all names something similar /dev/label/thingie rather then have /dev/ufs/rootfs and /dev/label/swap , I'll have /dev/label/rootfs /dev/label/swap. Also I dont think you can easily change a live label either . --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 22:01:34 2011 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 2DD9D1065672 for ; Wed, 12 Jan 2011 22:01:34 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id B2B2F8FC0C for ; Wed, 12 Jan 2011 22:01:33 +0000 (UTC) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0CJvo4t012185 for ; Thu, 13 Jan 2011 06:57:50 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0CJvkeD007747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jan 2011 06:57:47 +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.4/8.14.4) with ESMTP id p0CJvk0T016770; Thu, 13 Jan 2011 06:57:46 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p0CJvkCf016769; Thu, 13 Jan 2011 06:57:46 +1100 (EST) (envelope-from peter) Date: Thu, 13 Jan 2011 06:57:46 +1100 From: Peter Jeremy To: Oliver Pinter Message-ID: <20110112195746.GA16732@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org Subject: Re: sed is broken under freebsd? 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, 12 Jan 2011 22:01:34 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jan-12 02:32:52 +0100, Oliver Pinter wrote: >The freebsd versions of sed contained a bug/regression, when \n char >can i subsitue, gsed not affected with this bug: gsed contains non-standard extensions and you have been suckered into using them. Try using 'gsed --posix' and/or setting POSIXLY_CORRECT. This is part of the GNU/FSF "lockin" policy that encourages people to use their non-standard extensions to ensure that you don't have any choice other than to use their software. --=20 Peter Jeremy --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk0uB7oACgkQ/opHv/APuIeeogCgi6x/JlUXXRObGwEkZNBIPim5 CJcAnjidhge2xSdA4yLiV8kyX7JMtY66 =JHLf -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 12 22:51:23 2011 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 DB2BE1065694 for ; Wed, 12 Jan 2011 22:51:23 +0000 (UTC) (envelope-from bob@immure.com) Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9C41F8FC0A for ; Wed, 12 Jan 2011 22:51:23 +0000 (UTC) Received: from rancor.immure.com (rancor.immure.com [10.1.132.9]) by maul.immure.com (8.14.4/8.14.4) with ESMTP id p0CMWTP7004693; Wed, 12 Jan 2011 16:32:29 -0600 (CST) (envelope-from bob@immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.4/8.14.4/Submit) id p0CMWTR1067698; Wed, 12 Jan 2011 16:32:29 -0600 (CST) (envelope-from bob) Date: Wed, 12 Jan 2011 16:32:29 -0600 From: Bob Willcox To: Clifton Royston Message-ID: <20110112223229.GB65854@rancor.immure.com> References: <20110112070009.GB20924@lava.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110112070009.GB20924@lava.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-immure-MailScanner-Information: Please contact the ISP for more information X-immure-MailScanner-ID: p0CMWTP7004693 X-immure-MailScanner: Found to be clean X-immure-MailScanner-From: bob@immure.com X-Spam-Status: No Cc: stable@freebsd.org, Oliver Pinter Subject: Re: sed is broken under freebsd? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Willcox List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 22:51:23 -0000 On Tue, Jan 11, 2011 at 09:00:09PM -1000, Clifton Royston wrote: > On Wed, Jan 12, 2011 at 02:32:52AM +0100, Oliver Pinter wrote: > > hi all! > > > > The freebsd versions of sed contained a bug/regression, when \n char > > can i subsitue, gsed not affected with this bug: > > > FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 > > UTC 2010 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > > i386 > > aa@xxx ~> echo axa | sed s/x/\n/g > > ana > > aa@xxx ~> echo axa | sed s/x/'\n'/g > > ana > > Different than GNU is not a bug. > > I have 7.3 here. It behaves as the above, which is how the man page says it > should work. The following is how the man page specifies you can substitute > a newline, by prefacing a quoted actual newline with a backslash: > > $ echo axa | sed 's/x/\ > > /g' > a > a > > That's how I remember classic sed behaving (Unix v7 or thereabouts.) > -- Clifton FWI, AIX 6.1 sed works as the FreeBSD sed does. -- Bob Willcox When the ax entered the forest, the trees said, bob@immure.com "The handle is one of us!" Austin, TX -- Turkish proverb From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 00:32:45 2011 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 49DC21065675 for ; Thu, 13 Jan 2011 00:32:45 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta01.eastlink.ca (mta01.eastlink.ca [24.224.136.30]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2AC8FC0A for ; Thu, 13 Jan 2011 00:32:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ip02.eastlink.ca ([unknown] [24.222.39.20]) by mta01.eastlink.ca (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0LEX00BSDQUKJG23@mta01.eastlink.ca> for freebsd-stable@freebsd.org; Wed, 12 Jan 2011 20:32:44 -0400 (AST) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=b0sI0M7bjhCmEOs51LbeKzGQ5ECIs9m+H5QCeOcUmtc= c=1 sm=1 a=T6VSQHqbTHoA:10 a=kj9zAlcOel0A:10 a=uVkr0bZLAAAA:8 a=ep_KMAzDAAAA:8 a=cexIBkohAAAA:8 a=6I5d2MoRAAAA:8 a=6r1kPjOZHrZPmrUSHPkA:9 a=2Vts0pPOK_bug2Pw0R8A:7 a=szAKYIf62M0mh85MRm7qFw0WMzkA:4 a=CjuIK1q_8ugA:10 a=-y2NtEVjt-8A:10 a=wbyU6Wivc7IA:10 a=RjEokbflrYAA:10 a=SV7veod9ZcQA:10 a=NnPfv43VsoWtsnbu:21 a=vUjyhbbWYmqtMJCT:21 a=Y4g+zi6NJtbRuBVJrbSZ6Q==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip02.eastlink.ca with ESMTP; Wed, 12 Jan 2011 20:32:43 -0400 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Wed, 12 Jan 2011 20:32:43 -0400 From: Chris Forgeron To: freebsd-stable Date: Wed, 12 Jan 2011 20:32:42 -0400 Thread-topic: ZFS - hot spares : automatic or not? Thread-index: AcuxqmZWxHSqk1RpTla28yMUxgTo2QBDdL5Q Message-id: References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> <4D2BD0A7.9060003@langille.org> <4D2C810E.2070007@libeljournal.com> In-reply-to: <4D2C810E.2070007@libeljournal.com> Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Subject: RE: ZFS - hot spares : automatic or 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, 13 Jan 2011 00:32:45 -0000 Interesting, I was just testing Solaris 11 Express's ability to handle a pulled drive today. It handles it quite well. However, my Areca 1880 drive (arcmsr0) crashes when you reinsert the drive.. but that's another topic, and an issue for Areca tech support.. ..back to the point: Solaris runs a separate process called Fault Management Daemon (fmd) that looks to handle this logic - This means that it's really not inside the ZFS code to handle this, and FreeBSD would need something similar, hopefully less kludgy than a user script. I wonder if anyone has been eyeing the fma code in the cddl with a thought for porting it - It looks to be a really neat bit of code - I'm still quite new with it, having only been working with Solaris the last few months. Here's two links to a bit of info on the Solaris daemon: http://www.princeton.edu/~unix/Solaris/troubleshoot/fm.html http://hub.opensolaris.org/bin/view/Community+Group+fm/ Here's my log of the event in Solaris 11 Express: Jan 12 21:28:47 solaris fmd: [ID 377184 daemon.error] SUNW-MSG-ID: ZFS-8000-FD, TYPE: Fault, VER: 1, SEVERITY: Major Jan 12 21:28:47 solaris EVENT-TIME: Wed Jan 12 21:28:47 UTC 2011 Jan 12 21:28:47 solaris PLATFORM: PowerEdge-T710, CSN: 39SLQN1, HOSTNAME: solaris Jan 12 21:28:47 solaris SOURCE: zfs-diagnosis, REV: 1.0 Jan 12 21:28:47 solaris EVENT-ID: ccfa7a23-838b-ebc8-decf-c2607afb390d Jan 12 21:28:47 solaris DESC: The number of I/O errors associated with a ZFS device exceeded Jan 12 21:28:47 solaris acceptable levels. Refer to http://sun.com/msg/ZFS-8000-FD for more information. Jan 12 21:28:47 solaris AUTO-RESPONSE: The device has been offlined and marked as faulted. An attempt Jan 12 21:28:47 solaris will be made to activate a hot spare if available. Jan 12 21:28:47 solaris IMPACT: Fault tolerance of the pool may be compromised. Jan 12 21:28:47 solaris REC-ACTION: Run 'zpool status -x' and replace the bad device. -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of John Hawkes-Reed Sent: Tuesday, January 11, 2011 12:11 PM To: Dan Langille Cc: freebsd-stable Subject: Re: ZFS - hot spares : automatic or not? On 11/01/2011 03:38, Dan Langille wrote: > On 1/4/2011 11:52 AM, John Hawkes-Reed wrote: >> On 04/01/2011 03:08, Dan Langille wrote: >>> Hello folks, >>> >>> I'm trying to discover if ZFS under FreeBSD will automatically pull in a >>> hot spare if one is required. >>> >>> This raised the issue back in March 2010, and refers to a PR opened in >>> May 2009 >>> >>> * http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007943.html >>> * http://www.freebsd.org/cgi/query-pr.cgi?pr=134491 >>> >>> In turn, the PR refers to this March 2010 post referring to using devd >>> to accomplish this task. >>> >>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055686.html >>> >>> Does the above represent the the current state? >>> >>> I ask because I just ordered two more HDD to use as spares. Whether they >>> sit on the shelf or in the box is open to discussion. >> >> As far as our testing could discover, it's not automatic. >> >> I wrote some Ugly Perl that's called by devd when it spots a drive-fail >> event, which seemed to DTRT when simulating a failure by pulling a drive. > > Without such a script, what is the value in creating hot spares? We went through that loop in the office. We're used to the way the Netapps work here, where often one's first notice of a failed disk is a visit from the courier with a replacement. (I'm only half joking) In the end, writing enough perl to swap in the spare disk made much more sense than paging the relevant admin on disk-fail and expecting them to be able to type straight at 4AM. Our thinking is that having a hot spare allows us to do the physical disk-swap in office hours, rather than (for instance) running in a degraded state over a long weekend. If it's of interest, I'll see if I can share the code. -- JH-R _______________________________________________ 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 Thu Jan 13 00:36:00 2011 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 2AAEA1065673 for ; Thu, 13 Jan 2011 00:36:00 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B94D08FC1D for ; Thu, 13 Jan 2011 00:35:59 +0000 (UTC) Received: by bwz12 with SMTP id 12so1013102bwz.13 for ; Wed, 12 Jan 2011 16:35:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.81.72 with SMTP id w8mr1275959bkk.205.1294878958392; Wed, 12 Jan 2011 16:35:58 -0800 (PST) Received: by 10.204.151.212 with HTTP; Wed, 12 Jan 2011 16:35:58 -0800 (PST) X-Originating-IP: [68.239.208.169] In-Reply-To: <20110112223229.GB65854@rancor.immure.com> References: <20110112070009.GB20924@lava.net> <20110112223229.GB65854@rancor.immure.com> Date: Wed, 12 Jan 2011 19:35:58 -0500 Message-ID: From: Mark Saad To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: sed is broken under freebsd? 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, 13 Jan 2011 00:36:00 -0000 On Wed, Jan 12, 2011 at 5:32 PM, Bob Willcox wrote: > On Tue, Jan 11, 2011 at 09:00:09PM -1000, Clifton Royston wrote: >> On Wed, Jan 12, 2011 at 02:32:52AM +0100, Oliver Pinter wrote: >> > hi all! >> > >> > The freebsd versions of sed contained a bug/regression, when \n char >> > can i subsitue, gsed not affected with this bug: >> >> > FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 >> > UTC 2010 =C2=A0 =C2=A0 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/s= ys/GENERIC >> > =C2=A0i386 >> > aa@xxx ~> echo axa | sed s/x/\n/g >> > ana >> > aa@xxx ~> echo axa | sed s/x/'\n'/g >> > ana >> >> Different than GNU is not a bug. >> >> I have 7.3 here. =C2=A0It behaves as the above, which is how the man pag= e says it >> should work. =C2=A0The following is how the man page specifies you can s= ubstitute >> a newline, by prefacing a quoted actual newline with a backslash: >> >> $ echo axa | sed 's/x/\ >> > /g' >> a >> a >> >> =C2=A0 That's how I remember classic sed behaving (Unix v7 or thereabout= s.) >> =C2=A0 -- Clifton > > FWI, AIX 6.1 sed works as the FreeBSD sed does. Solaris 2.6 and OSX 10.6 , do the same thing as FreeBSD as well. --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 01:17:39 2011 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 E91DA1065693 for ; Thu, 13 Jan 2011 01:17:39 +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 85BE88FC14 for ; Thu, 13 Jan 2011 01:17:38 +0000 (UTC) Received: (qmail 86799 invoked from network); 13 Jan 2011 00:50:57 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@96.224.221.101) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 13 Jan 2011 00:50:57 -0000 Message-ID: <4D2E4C61.80407@acm.poly.edu> Date: Wed, 12 Jan 2011 19:50:41 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101031 Thunderbird/3.1.6 MIME-Version: 1.0 To: Chris Forgeron References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> <4D2BD0A7.9060003@langille.org> <4D2C810E.2070007@libeljournal.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: ZFS - hot spares : automatic or 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, 13 Jan 2011 01:17:40 -0000 On 01/12/11 19:32, Chris Forgeron wrote: > Interesting, I was just testing Solaris 11 Express's ability to handle a pulled drive today. It handles it quite well. However, my Areca 1880 drive (arcmsr0) crashes when you reinsert the drive.. but that's another topic, and an issue for Areca tech support.. > > ..back to the point: > > Solaris runs a separate process called Fault Management Daemon (fmd) that looks to handle this logic - This means that it's really not inside the ZFS code to handle this, and FreeBSD would need something similar, hopefully less kludgy than a user script. > > I wonder if anyone has been eyeing the fma code in the cddl with a thought for porting it - It looks to be a really neat bit of code - I'm still quite new with it, having only been working with Solaris the last few months. > > Here's two links to a bit of info on the Solaris daemon: > > http://www.princeton.edu/~unix/Solaris/troubleshoot/fm.html > http://hub.opensolaris.org/bin/view/Community+Group+fm/ > > > Here's my log of the event in Solaris 11 Express: > > Jan 12 21:28:47 solaris fmd: [ID 377184 daemon.error] SUNW-MSG-ID: ZFS-8000-FD, TYPE: Fault, VER: 1, SEVERITY: Major > Jan 12 21:28:47 solaris EVENT-TIME: Wed Jan 12 21:28:47 UTC 2011 > Jan 12 21:28:47 solaris PLATFORM: PowerEdge-T710, CSN: 39SLQN1, HOSTNAME: solaris > Jan 12 21:28:47 solaris SOURCE: zfs-diagnosis, REV: 1.0 > Jan 12 21:28:47 solaris EVENT-ID: ccfa7a23-838b-ebc8-decf-c2607afb390d > Jan 12 21:28:47 solaris DESC: The number of I/O errors associated with a ZFS device exceeded > Jan 12 21:28:47 solaris acceptable levels. Refer to http://sun.com/msg/ZFS-8000-FD for more information. > Jan 12 21:28:47 solaris AUTO-RESPONSE: The device has been offlined and marked as faulted. An attempt > Jan 12 21:28:47 solaris will be made to activate a hot spare if available. > Jan 12 21:28:47 solaris IMPACT: Fault tolerance of the pool may be compromised. > Jan 12 21:28:47 solaris REC-ACTION: Run 'zpool status -x' and replace the bad device. After a cursory glance at their fault-management infrastructure, I noticed that it also deals with other kinds of stuff like CPU and memory problems, which might make a port painful or impractical. Would the people with custom hot-spare scripts, or nothing automated at all, be content if the sysutils/geomWatch program grew support for hot spares in a future version? I already became somewhat familiar with the userland ZFS API when I added ZFS support to it. -Boris From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 03:03:26 2011 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 92BD21065673 for ; Thu, 13 Jan 2011 03:03:26 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta03.eastlink.ca (mta03.eastlink.ca [24.224.136.9]) by mx1.freebsd.org (Postfix) with ESMTP id 587138FC0C for ; Thu, 13 Jan 2011 03:03:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ip02.eastlink.ca ([unknown] [24.222.39.20]) by mta03.eastlink.ca (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)) with ESMTP id <0LEX00D1IXTNX4H0@mta03.eastlink.ca> for freebsd-stable@freebsd.org; Wed, 12 Jan 2011 23:03:23 -0400 (AST) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=8reSTVRqS4Rq5Xx4Jai9N41eZpHz3D5gSX5rA0od4mg= c=1 sm=1 a=T6VSQHqbTHoA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=1_v7PSh7Bdlkhcp0d0IA:9 a=5vBL7Iqk-1RW14fIEpoA:7 a=-9QeMS4CoSEATtAOGmwYnNQIQKQA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=wr7kPckUEblMA6dw:21 a=L4s1RISHTLBBIm0i:21 a=Y4g+zi6NJtbRuBVJrbSZ6Q==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip02.eastlink.ca with ESMTP; Wed, 12 Jan 2011 23:03:23 -0400 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Wed, 12 Jan 2011 23:03:20 -0400 From: Chris Forgeron To: freebsd-stable Date: Wed, 12 Jan 2011 23:03:19 -0400 Thread-topic: ZFS - hot spares : automatic or not? Thread-index: Acuyv7Wk8nd2VFhaRRqUNZGv5bNKPAABXM0Q Message-id: References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> <4D2BD0A7.9060003@langille.org> <4D2C810E.2070007@libeljournal.com> <4D2E4C61.80407@acm.poly.edu> In-reply-to: <4D2E4C61.80407@acm.poly.edu> Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Subject: RE: ZFS - hot spares : automatic or 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, 13 Jan 2011 03:03:26 -0000 I think we'd be happy with whatever solution someone was kind enough to donate the time towards. Although, stripping the Solaris FMD stuff down to just the ZFS parts would help keep Solaris/FreeBSD a bit closer in their ZFS implementations, which is of arguable importance, but I do like standardization. Eventually porting more of the FMD may be really useful, Solaris has a lot of very handy things in it that impress me. ..then again I'm not volunteering the time to do it, so I don't have much say. :-) -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Boris Kochergin Sent: Wednesday, January 12, 2011 8:51 PM To: Chris Forgeron Cc: freebsd-stable Subject: Re: ZFS - hot spares : automatic or not? >After a cursory glance at their fault-management infrastructure, I >noticed that it also deals with other kinds of stuff like CPU and memory >problems, which might make a port painful or impractical. Would the >people with custom hot-spare scripts, or nothing automated at all, be >content if the sysutils/geomWatch program grew support for hot spares in >a future version? I already became somewhat familiar with the userland >ZFS API when I added ZFS support to it. > >-Boris From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 05:10:23 2011 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 B536E106566C for ; Thu, 13 Jan 2011 05:10:23 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [168.103.150.6]) by mx1.freebsd.org (Postfix) with ESMTP id 25FCB8FC15 for ; Thu, 13 Jan 2011 05:10:22 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id p0D5AEvR082201; Wed, 12 Jan 2011 21:10:20 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Wed, 12 Jan 2011 21:10:21 -0800 (PST) Message-ID: In-Reply-To: <20110112223229.GB65854@rancor.immure.com> References: <20110112070009.GB20924@lava.net> <20110112223229.GB65854@rancor.immure.com> Date: Wed, 12 Jan 2011 21:10:21 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: cliftonr@lava.net Subject: Re: sed is broken under freebsd? 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, 13 Jan 2011 05:10:23 -0000 On Wed, January 12, 2011 2:32 pm, Bob Willcox wrote: > On Tue, Jan 11, 2011 at 09:00:09PM -1000, Clifton Royston wrote: > >> On Wed, Jan 12, 2011 at 02:32:52AM +0100, Oliver Pinter wrote: >> >>> hi all! >>> >>> The freebsd versions of sed contained a bug/regression, when \n char >>> can i subsitue, gsed not affected with this bug: >> >>> FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 >>> UTC 2010 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >>> i386 aa@xxx ~> echo axa | sed s/x/\n/g ana aa@xxx ~> echo axa | sed s/x/'\n'/g >>> ana >> >> Different than GNU is not a bug. >> >> >> I have 7.3 here. It behaves as the above, which is how the man page says it >> should work. The following is how the man page specifies you can substitute a >> newline, by prefacing a quoted actual newline with a backslash: >> >> $ echo axa | sed 's/x/\ >> >>> /g' >>> >> a a >> >> That's how I remember classic sed behaving (Unix v7 or thereabouts.) >> -- Clifton >> > > FWI, AIX 6.1 sed works as the FreeBSD sed does. FWIW On a hunch, I just performed an experimentwith sed(1) against gsed on 50,000 html documents. My mission; to replace all instances of: with: in an effort to see how long it would take to perform the operation for each of the two versions. The results? sed(1) (as provided by the BSD family of operating systems): ~2 seconds gsed: ~4.5 seconds Apologies for the extra noise on the list, but I do a tremendous amount of editing with sed(1) on almost a daily basis. It's a _fantastic_ tool, that saves me _zillions_ of hours. So I'm afraid I become a bit defensive when hearing anyone defame it - it's been like a trusted friend to me. :) --Chris > > > -- > Bob Willcox When the ax entered the forest, the trees said, > bob@immure.com "The handle is one of us!" Austin, TX > -- Turkish proverb > _______________________________________________ > 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 Thu Jan 13 05:46:50 2011 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 3A6A9106566C; Thu, 13 Jan 2011 05:46:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id CD5838FC17; Thu, 13 Jan 2011 05:46:49 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p0D5kmc4098856; Thu, 13 Jan 2011 05:46:48 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p0D5kmCM098831; Thu, 13 Jan 2011 05:46:48 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 13 Jan 2011 05:46:48 GMT Message-Id: <201101130546.p0D5kmCM098831@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 05:46:50 -0000 TB --- 2011-01-13 04:30:13 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-01-13 04:30:13 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2011-01-13 04:30:13 - cleaning the object tree TB --- 2011-01-13 04:30:46 - cvsupping the source tree TB --- 2011-01-13 04:30:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2011-01-13 04:31:31 - building world TB --- 2011-01-13 04:31:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-13 04:31:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-13 04:31:31 - TARGET=i386 TB --- 2011-01-13 04:31:31 - TARGET_ARCH=i386 TB --- 2011-01-13 04:31:31 - TZ=UTC TB --- 2011-01-13 04:31:31 - __MAKE_CONF=/dev/null TB --- 2011-01-13 04:31:31 - cd /src TB --- 2011-01-13 04:31:31 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 13 04:31:33 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 13 05:35:20 UTC 2011 TB --- 2011-01-13 05:35:20 - generating LINT kernel config TB --- 2011-01-13 05:35:20 - cd /src/sys/i386/conf TB --- 2011-01-13 05:35:20 - /usr/bin/make -B LINT TB --- 2011-01-13 05:35:21 - building LINT kernel TB --- 2011-01-13 05:35:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-13 05:35:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-13 05:35:21 - TARGET=i386 TB --- 2011-01-13 05:35:21 - TARGET_ARCH=i386 TB --- 2011-01-13 05:35:21 - TZ=UTC TB --- 2011-01-13 05:35:21 - __MAKE_CONF=/dev/null TB --- 2011-01-13 05:35:21 - cd /src TB --- 2011-01-13 05:35:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 13 05:35:21 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_gre.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_iso88025subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_lagg.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_loop.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_llatbl.c cc1: warnings being treated as errors /src/sys/net/if_llatbl.c: In function 'llentry_free': /src/sys/net/if_llatbl.c:124: warning: format '%ld' expects type 'long int', but argument 4 has type 'size_t' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-13 05:46:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-13 05:46:48 - ERROR: failed to build lint kernel TB --- 2011-01-13 05:46:48 - 3332.97 user 461.16 system 4594.77 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 05:47:02 2011 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 3C51C10656C0; Thu, 13 Jan 2011 05:47:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id E64EB8FC14; Thu, 13 Jan 2011 05:47:01 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p0D5l1fS099784; Thu, 13 Jan 2011 05:47:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p0D5l1jv099777; Thu, 13 Jan 2011 05:47:01 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 13 Jan 2011 05:47:01 GMT Message-Id: <201101130547.p0D5l1jv099777@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 05:47:02 -0000 TB --- 2011-01-13 04:32:43 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-01-13 04:32:43 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2011-01-13 04:32:43 - cleaning the object tree TB --- 2011-01-13 04:33:05 - cvsupping the source tree TB --- 2011-01-13 04:33:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2011-01-13 04:33:48 - building world TB --- 2011-01-13 04:33:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-13 04:33:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-13 04:33:48 - TARGET=pc98 TB --- 2011-01-13 04:33:48 - TARGET_ARCH=i386 TB --- 2011-01-13 04:33:48 - TZ=UTC TB --- 2011-01-13 04:33:48 - __MAKE_CONF=/dev/null TB --- 2011-01-13 04:33:48 - cd /src TB --- 2011-01-13 04:33:48 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 13 04:33:50 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 13 05:36:55 UTC 2011 TB --- 2011-01-13 05:36:55 - generating LINT kernel config TB --- 2011-01-13 05:36:55 - cd /src/sys/pc98/conf TB --- 2011-01-13 05:36:55 - /usr/bin/make -B LINT TB --- 2011-01-13 05:36:55 - building LINT kernel TB --- 2011-01-13 05:36:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-13 05:36:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-13 05:36:55 - TARGET=pc98 TB --- 2011-01-13 05:36:55 - TARGET_ARCH=i386 TB --- 2011-01-13 05:36:55 - TZ=UTC TB --- 2011-01-13 05:36:55 - __MAKE_CONF=/dev/null TB --- 2011-01-13 05:36:55 - cd /src TB --- 2011-01-13 05:36:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 13 05:36:55 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_gre.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_iso88025subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_lagg.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_loop.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_llatbl.c cc1: warnings being treated as errors /src/sys/net/if_llatbl.c: In function 'llentry_free': /src/sys/net/if_llatbl.c:124: warning: format '%ld' expects type 'long int', but argument 4 has type 'size_t' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-13 05:46:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-13 05:46:59 - ERROR: failed to build lint kernel TB --- 2011-01-13 05:46:59 - 3222.41 user 464.84 system 4456.19 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 05:55:57 2011 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 C4D071065670 for ; Thu, 13 Jan 2011 05:55:57 +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 A871A8FC14 for ; Thu, 13 Jan 2011 05:55:57 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta01.emeryville.ca.mail.comcast.net with comcast id uttF1f0081GXsucA1tvxBJ; Thu, 13 Jan 2011 05:55:57 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta07.emeryville.ca.mail.comcast.net with comcast id utvw1f0032tehsa8UtvwPc; Thu, 13 Jan 2011 05:55:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BC3FB9B427; Wed, 12 Jan 2011 21:55:55 -0800 (PST) Date: Wed, 12 Jan 2011 21:55:55 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20110113055555.GA51212@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: gnn@freebsd.org, bz@freebsd.org, rpaulo@freebsd.org Subject: Fwd: [releng_8 tinderbox] failure on i386/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: Thu, 13 Jan 2011 05:55:57 -0000 CC'ing responsible committers... http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_llatbl.c ----- Forwarded message from FreeBSD Tinderbox ----- > From: FreeBSD Tinderbox > To: FreeBSD Tinderbox , stable@freebsd.org, i386@freebsd.org > Date: Thu, 13 Jan 2011 05:46:48 GMT > Cc: > Subject: [releng_8 tinderbox] failure on i386/i386 > > TB --- 2011-01-13 05:35:21 - TARGET=i386 > TB --- 2011-01-13 05:35:21 - TARGET_ARCH=i386 > [...] > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_llatbl.c > cc1: warnings being treated as errors > /src/sys/net/if_llatbl.c: In function 'llentry_free': > /src/sys/net/if_llatbl.c:124: warning: format '%ld' expects type 'long int', but argument 4 has type 'size_t' > *** Error code 1 > > Stop in /obj/i386/src/sys/LINT. > *** Error code 1 > > http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full ----- End forwarded message ----- -- | 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 Jan 13 06:53:39 2011 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 A8AF9106566B; Thu, 13 Jan 2011 06:53:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1918FC16; Thu, 13 Jan 2011 06:53:39 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.4/8.14.4) with ESMTP id p0D6rcwH015193; Thu, 13 Jan 2011 06:53:38 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.4/8.14.4/Submit) id p0D6rcFR015186; Thu, 13 Jan 2011 06:53:38 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 13 Jan 2011 06:53:38 GMT Message-Id: <201101130653.p0D6rcFR015186@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 06:53:39 -0000 TB --- 2011-01-13 05:46:48 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-01-13 05:46:48 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2011-01-13 05:46:48 - cleaning the object tree TB --- 2011-01-13 05:47:02 - cvsupping the source tree TB --- 2011-01-13 05:47:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2011-01-13 05:47:50 - building world TB --- 2011-01-13 05:47:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-13 05:47:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-13 05:47:50 - TARGET=powerpc TB --- 2011-01-13 05:47:50 - TARGET_ARCH=powerpc TB --- 2011-01-13 05:47:50 - TZ=UTC TB --- 2011-01-13 05:47:50 - __MAKE_CONF=/dev/null TB --- 2011-01-13 05:47:50 - cd /src TB --- 2011-01-13 05:47:50 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 13 05:47:51 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 13 06:46:02 UTC 2011 TB --- 2011-01-13 06:46:02 - generating LINT kernel config TB --- 2011-01-13 06:46:02 - cd /src/sys/powerpc/conf TB --- 2011-01-13 06:46:02 - /usr/bin/make -B LINT TB --- 2011-01-13 06:46:02 - building LINT kernel TB --- 2011-01-13 06:46:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-13 06:46:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-13 06:46:02 - TARGET=powerpc TB --- 2011-01-13 06:46:02 - TARGET_ARCH=powerpc TB --- 2011-01-13 06:46:02 - TZ=UTC TB --- 2011-01-13 06:46:02 - __MAKE_CONF=/dev/null TB --- 2011-01-13 06:46:02 - cd /src TB --- 2011-01-13 06:46:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 13 06:46:02 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_gre.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_iso88025subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_lagg.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_loop.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_llatbl.c cc1: warnings being treated as errors /src/sys/net/if_llatbl.c: In function 'llentry_free': /src/sys/net/if_llatbl.c:124: warning: format '%ld' expects type 'long int', but argument 4 has type 'size_t' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-13 06:53:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-13 06:53:38 - ERROR: failed to build lint kernel TB --- 2011-01-13 06:53:38 - 3043.95 user 417.30 system 4009.66 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 08:25:08 2011 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 E1706106564A; Thu, 13 Jan 2011 08:25:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 6F08B8FC16; Thu, 13 Jan 2011 08:25:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E901C41C7A3; Thu, 13 Jan 2011 09:25:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 8ac53rCGLx9f; Thu, 13 Jan 2011 09:25:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 549D941C7AE; Thu, 13 Jan 2011 09:25:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0F9754448F3; Thu, 13 Jan 2011 08:20:41 +0000 (UTC) Date: Thu, 13 Jan 2011 08:20:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jeremy Chadwick In-Reply-To: <20110113055555.GA51212@icarus.home.lan> Message-ID: <20110113081928.N14966@maildrop.int.zabbadoz.net> References: <20110113055555.GA51212@icarus.home.lan> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "George V. Neville-Neil" , freebsd-stable@freebsd.org, rpaulo@freebsd.org Subject: Re: Fwd: [releng_8 tinderbox] failure on i386/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: Thu, 13 Jan 2011 08:25:09 -0000 On Wed, 12 Jan 2011, Jeremy Chadwick wrote: Hi, > CC'ing responsible committers... > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_llatbl.c Yes, it had the same problem in HEAD back then. kib fixed it that time and I just merged his fix as well that would ideally have gone in with the MFC or r215207. -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 08:47:39 2011 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 DD6DF106564A for ; Thu, 13 Jan 2011 08:47:39 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 745378FC14 for ; Thu, 13 Jan 2011 08:47:39 +0000 (UTC) Received: by wyf19 with SMTP id 19so1476960wyf.13 for ; Thu, 13 Jan 2011 00:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZFCrHhFzsNWyi3fD+NdxjrNj5o95OthGsDV9ELKyDWw=; b=GyvPhKMKeKgdg5LtnpKlmoYX6/whWxGdBtZ2TMfBLGc2u/NIPyX2Mng/fuSuy/mRyj otoB1uAsO2IrwoBMfy0uGxDa8GVll4+sMASTCt9fabzfBGBwP4oVJ+0mNVjf6WpK8gxr b9mRhpq+38xdIVAAagN4L7i8Z4M9wFiYDLnrw= 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=PbFoeQH0+S5WoQYdKXvxW78Uv2Cryozaf1LcAYTPukRBhJe0tWHV3GzEz5q610xHti GPwcqDr2ZiUBwXLd5sTFTEM+m+SFKY2Ir0kaDTKQRRFydZRXJ6ahXAr5Y1Tz0MaELgx/ H5GXwPBfw7wDD/PBinB4dxXj2zzO8bahm5cL4= MIME-Version: 1.0 Received: by 10.227.132.208 with SMTP id c16mr2061229wbt.72.1294908458272; Thu, 13 Jan 2011 00:47:38 -0800 (PST) Received: by 10.227.59.3 with HTTP; Thu, 13 Jan 2011 00:47:38 -0800 (PST) In-Reply-To: <20110112195746.GA16732@server.vk2pj.dyndns.org> References: <20110112195746.GA16732@server.vk2pj.dyndns.org> Date: Thu, 13 Jan 2011 09:47:38 +0100 Message-ID: From: Oliver Pinter To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org Subject: Re: sed is broken under freebsd? 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, 13 Jan 2011 08:47:39 -0000 yeah, and the solution is was Clifton wrote, but double escaped new-line in tcsh On 1/12/11, Peter Jeremy wrote: > On 2011-Jan-12 02:32:52 +0100, Oliver Pinter wrote: >>The freebsd versions of sed contained a bug/regression, when \n char >>can i subsitue, gsed not affected with this bug: > > gsed contains non-standard extensions and you have been suckered into > using them. Try using 'gsed --posix' and/or setting POSIXLY_CORRECT. > This is part of the GNU/FSF "lockin" policy that encourages people > to use their non-standard extensions to ensure that you don't have > any choice other than to use their software. > > -- > Peter Jeremy > From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 10:15:51 2011 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 6D1BB106566C for ; Thu, 13 Jan 2011 10:15:51 +0000 (UTC) (envelope-from www-data@dric.rete.cz) Received: from rete.cz (mail.rete.cz [78.156.32.11]) by mx1.freebsd.org (Postfix) with ESMTP id 36BA38FC08 for ; Thu, 13 Jan 2011 10:15:51 +0000 (UTC) Received: by rete.cz (Postfix, from userid 33) id 1FD915180F3; Thu, 13 Jan 2011 10:04:20 +0100 (CET) To: freebsd-stable@freebsd.org From: Albert Grayson MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20110113091938.1FD915180F3@rete.cz> Date: Thu, 13 Jan 2011 10:04:20 +0100 (CET) Subject: NEW ORDER!! 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, 13 Jan 2011 10:15:51 -0000 Hello, I am interested in purchasing some of your products, I will like to know if you can ship directly to SPAIN , I also want you to know my mode of payment for this order is via Credit Card. Get back to me if you can ship to that destination and also if you accept the payment type I indicated. Kindly return this email with your price list of your products.. Store Name: ALBERT D.P.P LIMITED : Shipping Address: "Parcela 20, Calle Budapest, San Pedro de Alcantara, 29670, Marbella , Spain Albert From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 15:02:40 2011 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 F0F071065672 for ; Thu, 13 Jan 2011 15:02:40 +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 85B5F8FC0C for ; Thu, 13 Jan 2011 15:02:40 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B18F.dip.t-dialin.net [87.179.177.143]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id A9CF4844187; Thu, 13 Jan 2011 15:43:14 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id A4E772A57; Thu, 13 Jan 2011 15:43:11 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p0DEgnCj035874; Thu, 13 Jan 2011 15:42:49 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 13 Jan 2011 15:42:49 +0100 Message-ID: <20110113154249.12101reh2to1rqe8@webmail.leidinger.net> Date: Thu, 13 Jan 2011 15:42:49 +0100 From: Alexander Leidinger To: Boris Kochergin References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> <4D2BD0A7.9060003@langille.org> <4D2C810E.2070007@libeljournal.com> <4D2E4C61.80407@acm.poly.edu> In-Reply-To: <4D2E4C61.80407@acm.poly.edu> 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: A9CF4844187.A6B94 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.351, required 6, autolearn=disabled, RDNS_NONE 1.27, TW_ZF 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1295534599.307@wHnyKe6sz+6M2z6jxGK5Aw X-EBL-Spam-Status: No Cc: freebsd-stable , Chris Forgeron Subject: Re: ZFS - hot spares : automatic or 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, 13 Jan 2011 15:02:41 -0000 Quoting Boris Kochergin (from Wed, 12 Jan 2011 19:50:41 -0500): > On 01/12/11 19:32, Chris Forgeron wrote: >> Solaris runs a separate process called Fault Management Daemon >> (fmd) that looks to handle this logic - This means that it's really >> not inside the ZFS code to handle this, and FreeBSD would need >> something similar, hopefully less kludgy than a user script. >> >> I wonder if anyone has been eyeing the fma code in the cddl with a >> thought for porting it - It looks to be a really neat bit of code - >> I'm still quite new with it, having only been working with Solaris >> the last few months. It depends upon a lot of standardized kernel notifications. Basically (big picture view) it is the same as our devd (reacting to events) with some logig what to do with it (which we can do without our devd too). > Would the people with custom hot-spare scripts, or nothing automated > at all, be content if the sysutils/geomWatch program grew support > for hot spares in a future version? I already became somewhat > familiar with the userland ZFS API when I added ZFS support to it. I had a look at geomWatch and it seems it is polling based. For something like zfs hotspare replacement you normally want to have the reaction event based (= devd). I even go further and think that things which geomWatch is doing, should be done with devd (may it be directly, or by delegating some events via a non-existing-yet interface (which could be even script driven) to another daemon). It may be that this would need some more events to be produced by different geom parts. IMO it would be great if those people with hotspare-scripts would publish them. This way a joined effort could be initiated to come up with some generic way of handling this which could be included in the base system. Bye, Alexander. -- Whatever creates the greatest inconvenience for the largest number must happen. 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 Thu Jan 13 15:07:28 2011 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 0E9141065673 for ; Thu, 13 Jan 2011 15:07:28 +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 9D0E28FC17 for ; Thu, 13 Jan 2011 15:07:27 +0000 (UTC) Received: (qmail 6891 invoked from network); 13 Jan 2011 15:07:26 -0000 Received: from unknown (HELO ?10.0.0.179?) (spawk@128.238.64.31) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 13 Jan 2011 15:07:26 -0000 Message-ID: <4D2F1534.7010500@acm.poly.edu> Date: Thu, 13 Jan 2011 10:07:32 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101106 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexander Leidinger References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> <4D2BD0A7.9060003@langille.org> <4D2C810E.2070007@libeljournal.com> <4D2E4C61.80407@acm.poly.edu> <20110113154249.12101reh2to1rqe8@webmail.leidinger.net> In-Reply-To: <20110113154249.12101reh2to1rqe8@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Chris Forgeron Subject: Re: ZFS - hot spares : automatic or 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, 13 Jan 2011 15:07:28 -0000 On 01/13/11 09:42, Alexander Leidinger wrote: > Quoting Boris Kochergin (from Wed, 12 Jan 2011 > 19:50:41 -0500): > >> On 01/12/11 19:32, Chris Forgeron wrote: > >>> Solaris runs a separate process called Fault Management Daemon (fmd) >>> that looks to handle this logic - This means that it's really not >>> inside the ZFS code to handle this, and FreeBSD would need something >>> similar, hopefully less kludgy than a user script. >>> >>> I wonder if anyone has been eyeing the fma code in the cddl with a >>> thought for porting it - It looks to be a really neat bit of code - >>> I'm still quite new with it, having only been working with Solaris >>> the last few months. > > It depends upon a lot of standardized kernel notifications. Basically > (big picture view) it is the same as our devd (reacting to events) > with some logig what to do with it (which we can do without our devd > too). > >> Would the people with custom hot-spare scripts, or nothing automated >> at all, be content if the sysutils/geomWatch program grew support for >> hot spares in a future version? I already became somewhat familiar >> with the userland ZFS API when I added ZFS support to it. > > I had a look at geomWatch and it seems it is polling based. For > something like zfs hotspare replacement you normally want to have the > reaction event based (= devd). I even go further and think that things > which geomWatch is doing, should be done with devd (may it be > directly, or by delegating some events via a non-existing-yet > interface (which could be even script driven) to another daemon). It > may be that this would need some more events to be produced by > different geom parts. > > IMO it would be great if those people with hotspare-scripts would > publish them. This way a joined effort could be initiated to come up > with some generic way of handling this which could be included in the > base system. > > Bye, > Alexander. > Did a little research. In at least the ZFS case, it appears that events are available through devctl(4) and are therefore accessible through devd: http://2007.asiabsdcon.org/papers/P16-paper.pdf - section 3.7 -Boris From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 15:39:21 2011 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 F24E31065673; Thu, 13 Jan 2011 15:39:21 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from aa003msb.fastweb.it (aa003msb.fastweb.it [85.18.95.82]) by mx1.freebsd.org (Postfix) with ESMTP id AE2C68FC13; Thu, 13 Jan 2011 15:39:21 +0000 (UTC) Received: from mail.commit.it (89.97.230.172) by aa003msb.fastweb.it (8.5.016.6) id 4CD8A5DF05764D1F; Thu, 13 Jan 2011 16:27:46 +0100 Received: from [192.168.44.97] (host24-44-dynamic.12-79-r.retail.telecomitalia.it [79.12.44.24]) (authenticated bits=0) by mail.commit.it (8.14.4/8.14.4) with ESMTP id p0DFPVaN092739 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 13 Jan 2011 16:25:32 +0100 (CET) (envelope-from aturetta@commit.it) Message-ID: <4D2F19E9.3060006@commit.it> Date: Thu, 13 Jan 2011 16:27:37 +0100 From: Angelo Turetta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Thomas Dean References: <201101130456.p0D4ucPM066526@red.freebsd.org> In-Reply-To: <201101130456.p0D4ucPM066526@red.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, bug-followup@freebsd.org Subject: Re: i386/153947: Make buildworld fails in hastd/token.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: Thu, 13 Jan 2011 15:39:22 -0000 On 13/01/2011 05:56, Thomas Dean wrote: > cc -O2 -pipe -I/usr/src/sbin/hastd -DINET -DINET6 -DYY_NO_UNPUT -DYY_NO_INPUT -DHAVE_CRYPTO -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c token.c > cc1: warnings being treated as errors > /usr/src/sbin/hastd/token.l:456: warning: function declaration isn't a prototype > *** Error code 1 > > Stop in /usr/src/sbin/hastd. > *** Error code 1 >> How-To-Repeat: > Install FreeBSD 8.1 from DVD > cvsup RELENG_8 from cvsup6.freebsd.org > make buildworld I can confirm it happens also on this STABLE build: FreeBSD 8.1-STABLE #1: Tue Oct 5 14:02:34 CEST 2010 Angelo Turetta Modena - Italy From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 19:02:29 2011 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 7ABC11065697 for ; Thu, 13 Jan 2011 19:02:29 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 339288FC1B for ; Thu, 13 Jan 2011 19:02:28 +0000 (UTC) Received: by gyf3 with SMTP id 3so834631gyf.13 for ; Thu, 13 Jan 2011 11:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kVw1OFJi8lSHTdGeoU44mz3eOBxU4/T6Nb8KwbnxKyw=; b=K8w4ScFr8HLss0xYo84Kwdu5BZnxUDo9amD8qC6Gx+ZUBTVH+Ovgf/bEt09u+xvOkO RHoOl+hvsA3QkXyMvJfy9SngRmWB+Vb0wNMQYRPtoHlzdiwPfOjii7eTaqlVLoq2lMR5 EYRUmaCwxObznVPYTVs0tN8q7ws2PklwECbfw= 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=V+5wLda0HZ21uAH1U3IXmPyYMJoK+GXfYsYEciupZYwXu3diwZrQ5+Sr9f9Y+VBsk4 1NFoV+vFoCOFopPjzj6s0C+aatlsXydNlOF5gvCpcx/Q3SfsiPNv3sKSRO3+O4bNKbCn 9BcKc2x++cHrfyp6OpHFmsTNiaO8NgB04vvUE= MIME-Version: 1.0 Received: by 10.90.115.5 with SMTP id n5mr600agc.199.1294945347010; Thu, 13 Jan 2011 11:02:27 -0800 (PST) Received: by 10.90.153.20 with HTTP; Thu, 13 Jan 2011 11:02:26 -0800 (PST) In-Reply-To: <4D2F1534.7010500@acm.poly.edu> References: <4D228F41.7040403@langille.org> <4D23504D.8060103@libeljournal.com> <4D2BD0A7.9060003@langille.org> <4D2C810E.2070007@libeljournal.com> <4D2E4C61.80407@acm.poly.edu> <20110113154249.12101reh2to1rqe8@webmail.leidinger.net> <4D2F1534.7010500@acm.poly.edu> Date: Thu, 13 Jan 2011 11:02:26 -0800 Message-ID: From: Freddie Cash To: Boris Kochergin Content-Type: text/plain; charset=UTF-8 Cc: Alexander Leidinger , freebsd-stable , Chris Forgeron Subject: Re: ZFS - hot spares : automatic or 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, 13 Jan 2011 19:02:29 -0000 On Thu, Jan 13, 2011 at 7:07 AM, Boris Kochergin wrote: > Did a little research. In at least the ZFS case, it appears that events are > available through devctl(4) and are therefore accessible through devd: > > http://2007.asiabsdcon.org/papers/P16-paper.pdf - section 3.7 PC-BSD has the following additions to their /etc/devd.conf file: # Sample ZFS problem reports handling. notify 10 { match "system" "ZFS"; match "type" "zpool"; action "logger -p kern.err 'ZFS: failed to load zpool $pool'"; }; notify 10 { match "system" "ZFS"; match "type" "vdev"; action "logger -p kern.err 'ZFS: vdev failure, zpool=$pool type=$type'"; }; notify 10 { match "system" "ZFS"; match "type" "data"; action "logger -p kern.warn 'ZFS: zpool I/O failure, zpool=$pool error=$zio_err'"; }; notify 10 { match "system" "ZFS"; match "type" "io"; action "logger -p kern.warn 'ZFS: vdev I/O failure, zpool=$pool path=$vdev_path offset=$zio_offset size=$zio_size error=$zio_err'"; }; notify 10 { match "system" "ZFS"; match "type" "checksum"; action "logger -p kern.warn 'ZFS: checksum mismatch, zpool=$pool path=$vdev_path offset=$zio_offset size=$zio_size'"; }; So it's very (relatively) easy to configure devd to do this. We just need some scripts to plug into the action lines above. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 20:05:01 2011 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 DC62C106566B for ; Thu, 13 Jan 2011 20:05:01 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9548FC1F for ; Thu, 13 Jan 2011 20:05:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id 83CE5806F for ; Thu, 13 Jan 2011 20:45:20 +0100 (CET) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id E723B8053; Thu, 13 Jan 2011 20:45:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Alban Hertroys In-Reply-To: Date: Thu, 13 Jan 2011 20:45:07 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20110112070009.GB20924@lava.net> <20110112223229.GB65854@rancor.immure.com> To: Chris H X-Mailer: Apple Mail (2.1082) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Jan 13 20:45:20 2011 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 74,4d2f565011879296619823 X-DSPAM-Factors: 27, Message-Id*F2693A78EDA8+solfertje.student.utwente.nl>, 0.40000, From*Alban, 0.40000, just, 0.40000, >+, 0.40000, Mime-Version*Message, 0.40000, html+PUBLIC, 0.40000, all+>, 0.40000, an, 0.40000, trees, 0.40000, trees, 0.40000, 10, 0.40000, 8"?>+>, 0.40000, org/TR/xhtml1/DTD/xhtml1+strict, 0.40000, cut, 0.40000, of, 0.40000, >+instances, 0.40000, References* > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > I do hope you didn't orphan a -tag there? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:74,4d2f565011879296619823! From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 20:19:15 2011 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 9F29F1065670 for ; Thu, 13 Jan 2011 20:19:15 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ01.datapipe-corp.net (exfesmq01.datapipe-corp.net [64.106.130.71]) by mx1.freebsd.org (Postfix) with ESMTP id 62EEE8FC17 for ; Thu, 13 Jan 2011 20:19:15 +0000 (UTC) Received: from nat.myhome (64.106.131.250) by EXFESMQ01.datapipe-corp.net (64.106.130.71) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 Jan 2011 15:09:02 -0500 Date: Thu, 13 Jan 2011 14:09:22 -0600 From: "Paul A. Procacci" To: Alban Hertroys Message-ID: <20110113200922.GN99551@nat.myhome> References: <20110112070009.GB20924@lava.net> <20110112223229.GB65854@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" , "cliftonr@lava.net" , Chris H Subject: Re: sed is broken under freebsd? 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, 13 Jan 2011 20:19:15 -0000 On Thu, Jan 13, 2011 at 02:45:07PM -0500, Alban Hertroys wrote: > On 13 Jan 2011, at 6:10, Chris H wrote: > > FWIW On a hunch, I just performed an experimentwith sed(1) > > against gsed on 50,000 html documents. My mission; to replace all > > instances of: > > > > > > > > with: > > > > > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > > > > > I do hope you didn't orphan a -tag there? > > Alban Hertroys > > -- > If you can't see the forest for the trees, > cut the trees and you'll see there is no forest. > > > !DSPAM:74,4d2f565011879296619823! > > > _______________________________________________ > 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" It was just an experiement. ~Paul This message may contain confidential or privileged information. If you ar= e not the intended recipient, please advise us immediately and delete this = message. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm f= or further information on confidentiality and the risks of non-secure elect= ronic communication. If you cannot access these links, please notify us by = reply message and we will send the contents to you. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 13 21:26:59 2011 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 1990D1065673 for ; Thu, 13 Jan 2011 21:26:59 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (t1850.greatnet.de [83.133.124.96]) by mx1.freebsd.org (Postfix) with ESMTP id 7E49B8FC1B for ; Thu, 13 Jan 2011 21:26:58 +0000 (UTC) Received: (qmail 30356 invoked from network); 13 Jan 2011 21:00:16 -0000 Received: from p5b37a68b.dip.t-dialin.net (HELO dijkstra) (smtpallow@91.55.166.139) by t1850.greatnet.de with ESMTPA; 13 Jan 2011 21:00:16 -0000 Date: Thu, 13 Jan 2011 22:00:19 +0100 From: "Christopher J. Ruwe" To: freebsd-stable@freebsd.org Message-ID: <20110113220019.0c18c7ef@dijkstra> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/xUWri8O063jwbqEtcgFEIOs"; protocol="application/pgp-signature" Subject: geli problems after installkernel & installworld 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, 13 Jan 2011 21:26:59 -0000 --Sig_/xUWri8O063jwbqEtcgFEIOs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I use a mostly geli encrypted hd on my Thinkpad R500, with /compat, /usr, /tmp and /var all on the encrypted geli provider. After an upgrade of kernel and world (STABLE), I experience a weird issue: While booting, I am asked for the geli passphrase as usual. Completing password authentication for geli returns a success message, cryptosoft0: on motherboard GEOM_ELI: Device ada0p3.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software however, the zpool on geli is unavailable. Logging in a root, I can attach the geli provider manually as geli itself should do from /etc/rc.conf. After a successful zfs mount -a, I can resume as usual after manually starting the /usr/local/rc.d services.=20 Neither have I noticed a change in the device names nor any unusual messages from dmesg. Currently, I am doing a new compile run on world and kernel to attempt anew tomorrow. Am I missing something? Kind regards, --=20 Christopher J. Ruwe TZ GMT + 1 --Sig_/xUWri8O063jwbqEtcgFEIOs Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQIcBAEBAgAGBQJNL2fpAAoJEJTIKW/o3iwUBqAQANvoii7bOKutdXVemoc7BFr4 QV7BC1E+S2JTtts7ohY8aC2bsUsmRWrQK7F+hzc5gGaB784LU7XzL6l8EhJG9MTV wzZD1RVX6Yi849TE6+beVhUcxTivKI7iU3iJa7f4mvfBZZ+fwDfmF2QaS/m+tAal 5eSJH6Diwhhmy/GWkThFZKlUISwu5Jp/8PQeO8hE93HTLeouEXkBvU5wzQVsykxy o/7yJ9F+tAIfyeHhy9S7J9iwGQ3ovEK3mw0HQm5Q0AfoDmZSgHrpaUaw3p/Qnn63 8GJ0vJ1bVmTswVAY18J03X0wgCqSwswX/BlLuDHnJcIMNNm5prjwOLZS6i1s8x0X TltnOJgf0ZpGPX9Ni2maXiDI4xNIPKRWJ7zUcSWUC1/rcG8LJpmnJTtTX009kjns cjyu6QQ3R5S08ta+CoQKyXtmk2bECJVq59l1HBL18VODGc06g9NOY6ZpOI2ZUif1 buni1FYURAk01OJP4eDDaDOiOFtvWSztBqS8u8Noe10T7ehKNz5zrj/+AbU8Vb2O 8dOIF0XOxNVP7/ERZECkZ3Xk87d3uN9xpteZK7+uJwuffGpmMTHWcrV5O4SRUFnv 34Ppo6HBUWhAomBqjIuIzy+V+ut+CGcnR3R4K4KKSJxOPSqchCg1tmbOkyLjO41D TKJd+bGs2WE3wj3HDxAM =/Zij -----END PGP SIGNATURE----- --Sig_/xUWri8O063jwbqEtcgFEIOs-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 08:01:55 2011 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 B0539106564A for ; Fri, 14 Jan 2011 08:01:55 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [168.103.150.6]) by mx1.freebsd.org (Postfix) with ESMTP id 582378FC16 for ; Fri, 14 Jan 2011 08:01:55 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id p0E81jxv095217; Fri, 14 Jan 2011 00:01:51 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Fri, 14 Jan 2011 00:01:51 -0800 (PST) Message-ID: <0652cc7e3380a4dd8333ff7739396560.HRCIM@webmail.1command.com> In-Reply-To: References: <20110112070009.GB20924@lava.net> <20110112223229.GB65854@rancor.immure.com> Date: Fri, 14 Jan 2011 00:01:51 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: sed is broken under freebsd? 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, 14 Jan 2011 08:01:55 -0000 On Thu, January 13, 2011 11:45 am, Alban Hertroys wrote: > On 13 Jan 2011, at 6:10, Chris H wrote: > >> FWIW On a hunch, I just performed an experimentwith sed(1) >> against gsed on 50,000 html documents. My mission; to replace all instances of: >> >> >> >> >> with: >> >> >> >> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> >> >> > > > I do hope you didn't orphan a -tag there? LOL Good catch! Nope. I guess my copy/paste skills aren't so good, when it comes to my mail reader. :) This is the actual script I used: fixem.sh #!/bin/sh - # WARNING - there is NO turning back! for name in $(find . -type f -name '*.html') do sed -f fixem.sed <$name >temp.txt mv temp.txt $name done rm -f temp.txt fixem.sed /\/d s/\/\<\?xml\ version\=\"1\.0\"\ encoding\=\"UTF\-8\"\?\>\ \<\!DOCTYPE\ html\ PUBLIC\ \"\-\/\/W3C\/\/DTD\ XHTML\ 1\.0\ Strict\/\/EN\"\ \ \"http\:\/\/www\.w3\.org\/TR\/xhtml1\/DTD\/xhtml1\-strict\.dtd\"\>\ \\ \/s --Chris > > > Alban Hertroys > > > -- > If you can't see the forest for the trees, > cut the trees and you'll see there is no forest. > > > !DSPAM:74,4d2f565011879296619823! > > > > _______________________________________________ > 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 Fri Jan 14 08:12:21 2011 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 E4C3B1065674 for ; Fri, 14 Jan 2011 08:12:21 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [168.103.150.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB2E8FC12 for ; Fri, 14 Jan 2011 08:12:21 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id p0E8CBhk095270; Fri, 14 Jan 2011 00:12:18 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Fri, 14 Jan 2011 00:12:18 -0800 (PST) Message-ID: <4fd80e5737354bd0b141fb3fa073e3ce.HRCIM@webmail.1command.com> In-Reply-To: <0652cc7e3380a4dd8333ff7739396560.HRCIM@webmail.1command.com> References: <20110112070009.GB20924@lava.net> <20110112223229.GB65854@rancor.immure.com> <0652cc7e3380a4dd8333ff7739396560.HRCIM@webmail.1command.com> Date: Fri, 14 Jan 2011 00:12:18 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: sed is broken under freebsd? 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, 14 Jan 2011 08:12:22 -0000 On Fri, January 14, 2011 12:01 am, Chris H wrote: > > On Thu, January 13, 2011 11:45 am, Alban Hertroys wrote: > >> On 13 Jan 2011, at 6:10, Chris H wrote: >> >> >>> FWIW On a hunch, I just performed an experimentwith sed(1) >>> against gsed on 50,000 html documents. My mission; to replace all instances >>> of: >>> >>> >>> >>> >>> >>> with: >>> >>> >>> >>> >>> >> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> >>> >>> >>> >> >> >> I do hope you didn't orphan a -tag there? >> > > LOL Good catch! > Nope. I guess my copy/paste skills aren't so good, when it comes > to my mail reader. :) > > This is the actual script I used: > > > fixem.sh #!/bin/sh - > # WARNING - there is NO turning back! > for name in $(find . -type f -name '*.html') do sed -f fixem.sed <$name >temp.txt > mv temp.txt $name done rm -f temp.txt > > fixem.sed /\/d > s/\/\<\?xml\ version\=\"1\.0\"\ encoding\=\"UTF\-8\"\?\>\ \<\!DOCTYPE\ > html\ PUBLIC\ \"\-\/\/W3C\/\/DTD\ XHTML\ 1\.0\ Strict\/\/EN\"\ \ > \"http\:\/\/www\.w3\.org\/TR\/xhtml1\/DTD\/xhtml1\-strict\.dtd\"\>\ > \ dir\=\"ltr\"\>\ \/s OK I'm clearly crap when it comes to mail readers. Before someone points this out, I'll mention it now: the last line has a mistake dir\=\"ltr\"\>\ \/s should have been dir\=\"ltr\"\>\ \/g _________________________^ in other words; should have ended with a "g" 'nuf said. --Chris > > > > --Chris > > > > > > >> >> >> Alban Hertroys >> >> >> >> -- >> If you can't see the forest for the trees, >> cut the trees and you'll see there is no forest. >> >> >> !DSPAM:74,4d2f565011879296619823! >> >> >> >> >> _______________________________________________ >> 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" > > -- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 12:25:28 2011 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 F1441106564A for ; Fri, 14 Jan 2011 12:25:28 +0000 (UTC) (envelope-from quakenet1@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5718FC0A for ; Fri, 14 Jan 2011 12:25:28 +0000 (UTC) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0EARZQe011000 for ; Fri, 14 Jan 2011 21:27:35 +1100 Received: from [192.168.100.21] (c220-239-108-58.belrs4.nsw.optusnet.com.au [220.239.108.58]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0EARXeZ012165 for ; Fri, 14 Jan 2011 21:27:33 +1100 From: Jerahmy Pocott Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 21:27:32 +1100 Message-Id: <659F3C99-CA41-4685-B981-115802734D02@optusnet.com.au> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: USB Drive not showing up correctly in 8.1 (works in 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: Fri, 14 Jan 2011 12:25:29 -0000 Hello, I have a USB Drive that was working fine under 7.3, but since updating = to 8.1 no longer has the correct /dev entries. Under 7.3 it was da0s1, in 8.1 there is = now only da0 and da0a, which shouldn't exist.. # fdisk /dev/da0 shows: ******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=3D121601 heads=3D255 sectors/track=3D63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3D121601 heads=3D255 sectors/track=3D63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 1953520002 (953867 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 768/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Which is correct, and thus should result in a s1 in the dev tree.. # bsdlabel /dev/da0 shows: # /dev/da0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1953525152 16 unused 0 0 =20 c: 1953525168 0 unused 0 0 # "raw" part, = don't edit I don't think there should even be a label at that level.. # gpart list shows: Geom name: da0 fwheads: 255 fwsectors: 63 last: 1953525167 first: 0 entries: 8 scheme: BSD Providers: 1. Name: da0a Mediasize: 1000204877824 (932G) Sectorsize: 512 Mode: r0w0e0 rawtype: 0 length: 1000204877824 offset: 8192 type: !0 index: 1 end: 1953525167 start: 16 Consumers: 1. Name: da0 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r0w0e0 The scheme seems to indicate that geom is not reading the fdisk data? The dmesg output for the device is: umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: 40.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) There is also an error message during boot, which I'm not sure if it's = related but says: usbd_set_config_index: could not read device status: USB_ERR_SHORT_XFER Any ideas on how to correct this problem? Cheers! From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 14:07:39 2011 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 177E01065673 for ; Fri, 14 Jan 2011 14:07:39 +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 D04648FC0A for ; Fri, 14 Jan 2011 14:07:38 +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 1PdkJV-000CTg-SQ for freebsd-stable@freebsd.org; Fri, 14 Jan 2011 14:07:37 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PdkJV-0007GJ-Rc for freebsd-stable@freebsd.org; Fri, 14 Jan 2011 14:07:37 +0000 Date: Fri, 14 Jan 2011 14:07:37 +0000 Message-Id: To: freebsd-stable@freebsd.org From: Pete French Subject: Policy on static linking ? 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, 14 Jan 2011 14:07:39 -0000 I build code using static linking for deployment across a set of machines. For me this has a lot of advantages - I know that the code will run, no matter what the state of the ports is on the machine, and if there is a need to upgrade a library then I do it once on the build machine, rebuild the executable, and rsync it out to the leaf nodes. Only one place to track security updates, only one place where I need to have all the porst the code depends on installed. I recently wanted to use libdespatch, but I found that the port didn't install the static libraries. I filed a PR, and found out from the reponse that this was deliberate, and that a number of other ports were deliberately excluding static libraries too. Some good reasons where given, which I wont reporduce here, as you can read them at: http://www.freebsd.org/cgi/query-pr.cgi?pr=151306 Today I finally hit the problem where a critical library I am using has stopped working with static libraries (or so it appears at first glance). I was wondering what the general policy here was - should I just bite the bullet and go dynamic, and accept the maintannance headache that cases, or could we define something like 'WITH_STATIC_LIBRARIES' that could be set which would make ports install a set of static libraries (maybe into a separate /usr/local/lib/static?) so that the likes of me could continue to build static code ? I'd very much like to be able to continue to ship single executables that "just run", but if theres some policy to only have dynamic libraries in ports going forward then fair enough... -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 16:20:15 2011 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 1A2A4106566C for ; Fri, 14 Jan 2011 16:20:15 +0000 (UTC) (envelope-from thrawn@raveisking.de) Received: from smtp.presswatch.de (smtp.kantarmedia.de [212.48.122.104]) by mx1.freebsd.org (Postfix) with ESMTP id CA4818FC14 for ; Fri, 14 Jan 2011 16:20:14 +0000 (UTC) Received: from [192.168.39.2] by smtp.presswatch.de with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pdlhv-0004Mi-1R for freebsd-stable@freebsd.org; Fri, 14 Jan 2011 16:36:55 +0100 Message-ID: <4D306D96.7080002@raveisking.de> Date: Fri, 14 Jan 2011 15:36:54 +0000 From: Jan Winter User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20101211120033.DC0541065746@hub.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: umass: AutoSense failed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thrawn@raveisking.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:20:15 -0000 On 12/14/2010 20:19, Ross Alexander wrote: > On Sat, 11 Dec 2010, Harad Weiss wrote > >> Message: 7 >> Date: Fri, 10 Dec 2010 22:59:17 +0100 >> From: Harald Weis >> Subject: Re: umass: AutoSense failed >> To: freebsd-stable@freebsd.org >> Cc: Jeremy Chadwick >> Message-ID: <20101210215917.GA2447@pollux.local.net> >> Content-Type: text/plain; charset=us-ascii >> >> [big snip] >> >> The AutoSense failure occurs on two desktop computers, whether >> motherboard or not, and on three laptops. As I said, all PC's >> run 8.1-RELEASE. >> What I do not know is whether the Sony DSC (Digital Still Camera) has >> worked on 8.0-RELEASE. I didn't use it for some time, so I'm afraid >> I never tried it on 8.x. >> But I am sure it worked on all earlier releases. >> In my original post I have forgotten to mention that I never had any >> problems with all sorts of thumbdrives and USB disks. >> Fortunately, I can read the 256MB CF memory of the DSC on an Ubuntu >> laptop. >> Could it possibly be a DSC hardware problem which is ignored by Ubuntu, >> but not by FreeBSD? > > My Sony DSC camera did work under 8.0-RELEASE. It's a model DSC-W35. > It's seeing the umass problem now, and has since 8.1-PRERELEASE afair. > > This fault is the same on i386 or amd64, intel or amd chipsets, USB > 1.0 or 2.0, through hubs or straight off the m/b, etc.. I'm keeping a > backup box (intel atom / i386) running 7.3-STABLE around specifically > to work around the problem. I'd have said something eralier, but I've > gotten used to small nits poppping up and then disappearing; this one > is dragging along :( > > sincerest regards, > Ross Hi, I have similar problems. Running Freebsd 7.3 on a alix system (http://www.pcengines.ch/alix2d13.htm) I have no problems connecting usb hdd. With freebsd 8.2-PRERELEASE, I got this errors after reading some data from the usb disk: ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 476940MB (976773167 512 byte sectors: 255H 63S/T 60801C) (da0:umass-sim0:0:0:0): AutoSense failed (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): SCSI sense: NO SENSE asc:0,0 (No additional sense information) any ideas? cheers Jan From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 16:20:41 2011 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 7777410656A8 for ; Fri, 14 Jan 2011 16:20:41 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id C05FF8FC18 for ; Fri, 14 Jan 2011 16:20:31 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id BD21B1DD638; Fri, 14 Jan 2011 17:20:29 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id AFB3F170A8; Fri, 14 Jan 2011 17:20:29 +0100 (CET) Date: Fri, 14 Jan 2011 17:20:29 +0100 From: Jilles Tjoelker To: Pete French Message-ID: <20110114162029.GA17948@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Policy on static linking ? 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, 14 Jan 2011 16:20:41 -0000 On Fri, Jan 14, 2011 at 02:07:37PM +0000, Pete French wrote: > I build code using static linking for deployment across a set of > machines. For me this has a lot of advantages - I know that the > code will run, no matter what the state of the ports is on the > machine, and if there is a need to upgrade a library then I do it > once on the build machine, rebuild the executable, and rsync it out > to the leaf nodes. Only one place to track security updates, only > one place where I need to have all the porst the code depends on > installed. > I recently wanted to use libdespatch, but I found that the port > didn't install the static libraries. I filed a PR, and found out > from the reponse that this was deliberate, and that a number of > other ports were deliberately excluding static libraries too. Some > good reasons where given, which I wont reporduce here, > as you can read them at: http://www.freebsd.org/cgi/query-pr.cgi?pr=151306 > Today I finally hit the problem where a critical library I am using > has stopped working with static libraries (or so it appears at first glance). > I was wondering what the general policy here was - should I just bite the > bullet and go dynamic, and accept the maintannance headache that cases, or > could we define something like 'WITH_STATIC_LIBRARIES' that could be set > which would make ports install a set of static libraries (maybe into > a separate /usr/local/lib/static?) so that the likes of me could > continue to build static code ? I'd very much like to be able to continue > to ship single executables that "just run", but if theres some policy > to only have dynamic libraries in ports going forward then fair enough... Various features do not work with static linking because dlopen() does not work from static executables. Libraries that are also used by dlopen()ed modules should generally be linked dynamically, particularly if these libraries have global state. Things that use dlopen() include NSS (getpwnam() and the like), PAM and most "plugin" systems. If libc is statically linked, NSS falls back to a traditional mode that only supports the traditional things (e.g. no LDAP user information); I think PAM and most plugin systems do not work at all. For some system libraries, there can be kernel compatibility problems that prevent old libraries from working, although an ABI-compatible shared library is available. This has happened with 6.x's libkse: binaries statically linked to it do not run on 8.x or newer, while libkse can be remapped to libthr for binaries dynamically linked to libkse. For these reasons, static linking to libc, libpthread and similar system libraries should be reserved for /rescue/rescue and similar programs, and not used in general. Another feature only available with dynamic linking is hidden symbols that are available only inside the shared object. Compiling a library that uses this feature as a static library will make the hidden symbols visible to the application or other libraries. This may cause name clashes that otherwise wouldn't have been a problem or invite API abuse. Proper use of hidden symbols can also speed up linking and load times considerably, particularly if the code is written in C++. Other issues are static linking's requirement to list all libraries a library depends on and in the correct order. With dynamic linking, listing the indirect dependencies is unnecessary and best avoided. This is generally not very hard to fix but still needs extra effort. (For example, pkg-config has Libs.private to help with it.) If you want to link dynamically but avoid too much management overhead, consider using PCBSD's PBI system which allows you to ship all necessary .so files (except system ones) with your application. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 17:07:54 2011 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 422021065674 for ; Fri, 14 Jan 2011 17:07:54 +0000 (UTC) (envelope-from mloftis@wgops.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 159868FC18 for ; Fri, 14 Jan 2011 17:07:53 +0000 (UTC) Received: by iyb26 with SMTP id 26so2781871iyb.13 for ; Fri, 14 Jan 2011 09:07:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.36.5 with SMTP id r5mr908300ibd.134.1295023565976; Fri, 14 Jan 2011 08:46:05 -0800 (PST) Received: by 10.231.205.137 with HTTP; Fri, 14 Jan 2011 08:46:05 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Jan 2011 09:46:05 -0700 Message-ID: From: Michael Loftis To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Policy on static linking ? 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, 14 Jan 2011 17:07:54 -0000 On Fri, Jan 14, 2011 at 7:07 AM, Pete French wrote: > I build code using static linking for deployment across a set of > machines. For me this has a lot of advantages - I know that the > code will run, no matter what the state of the ports is on the > machine, and if there is a need to upgrade a library then I do it > once on the build machine, rebuild the executable, and rsync it out > to the leaf nodes. Only one place to track security updates, only > one place where I need to have all the porst the code depends on > installed. > You still have to track security updates for the rest of your system. ssh for example. Kernel bugs too (though admittedly those are much more rare). From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 17:19:23 2011 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 72BB61065670 for ; Fri, 14 Jan 2011 17:19:23 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (t1850.greatnet.de [83.133.124.96]) by mx1.freebsd.org (Postfix) with ESMTP id BB3D78FC16 for ; Fri, 14 Jan 2011 17:19:22 +0000 (UTC) Received: (qmail 1156 invoked from network); 14 Jan 2011 17:19:20 -0000 Received: from p5b37a39b.dip.t-dialin.net (HELO dijkstra) (smtpallow@91.55.163.155) by t1850.greatnet.de with ESMTPA; 14 Jan 2011 17:19:20 -0000 Date: Fri, 14 Jan 2011 18:19:25 +0100 From: "Christopher J. Ruwe" To: freebsd-stable@freebsd.org Message-ID: <20110114181925.49e5ee2d@dijkstra> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/B2fe1U9K1HHwVrHRu8nhnrl"; protocol="application/pgp-signature" Subject: Re: Next ZFSv28 patchset ready for testing. 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, 14 Jan 2011 17:19:23 -0000 --Sig_/B2fe1U9K1HHwVrHRu8nhnrl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, I would like to test Martin Matuskas patch for ZFS v28 against stable. Can I patch against any stable (like stable of today) or does it necessarily need to be the stable-tree of the date specified in the patch-file? If the latter should be true, how do I obtain a stable tree of any given date? Thanks for any help, kind regards, --=20 Christopher J. Ruwe TZ GMT + 1 --Sig_/B2fe1U9K1HHwVrHRu8nhnrl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQIcBAEBAgAGBQJNMIWiAAoJEJTIKW/o3iwU9owQAK6MrG3xi39Lw4QRUSoGKlHr tuO/QZLcjGy+D6N1hmpEKwgzXbfZO+CGknp56W2Q5wGoLrqzGFAwGSaIae8IXUP/ AUcYlCQLSJHtsTJUwXvJpRxUgOck8S+VbnITVFsvUNCZ8TUXT1NEYobzvMgj4Y76 yh+5RNWTnj0KtQ14wvnw0Eu0yMoGTEjbeeHL2vRw4Tn/Rw+g9rym5F6CzeLhUHxW OMxPST4/5+zhels1nRoIChqyQs5R02G3Wdvq7nYY9UZcJgIWFkzh6rA8T2/yIEKT DTyJlaqTSsnZsqjX9EBThd5uiAsVFDBugeBgyrhOvC9bGuOPwwESgb/tKiNhR5S9 piqY9uB9w9+YtURpIdkC0bCsVybIZ7TDKJRhj07uhtrF6wbFlO0l8Ttd0BzuyUVB kexlAi2z6bOpwWiW/IyPgVhAgfo69lF/1pd0xU+pjfxrzMECo30mqNM/OTyGUJ8H BThxFtzlhCplu8iRsDhIuSh0AjQiVhtPqtlxaigBQmqRYqD1hGd9FOZGwtpdP1++ khS4znEvDYgLHZPwbi8MV45Qw9Cf5+hgo7pgQQs47a0x7VYrXgRmGOnn/QbIgHEd AW1rQSJINMS8/wwrl48du4BpzGo31P+9IVWVnPVuZJAjk/f/mBu/7I2+tdrcm9WP jk2iEUMmZizA/ZVHpMh3 =2Y+i -----END PGP SIGNATURE----- --Sig_/B2fe1U9K1HHwVrHRu8nhnrl-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 18:48:41 2011 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 0DA501065670 for ; Fri, 14 Jan 2011 18:48:41 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4408FC17 for ; Fri, 14 Jan 2011 18:48:39 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0EImcZM003675; Sat, 15 Jan 2011 00:48:38 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D309A81.7040808@rdtc.ru> Date: Sat, 15 Jan 2011 00:48:33 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Saad References: <628423291.20110112210201@serebryakov.spb.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: geom_label, fstab without device names & swap partition? 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, 14 Jan 2011 18:48:41 -0000 On 13.01.2011 02:11, Mark Saad wrote: >>>> Use glabel(8) to label the device: >>>> >>>> # glabel label swap ada0s1b >>> >>> On a side note there is not a simple way to glabel mounted filesystem >> >> True, but for a swap partition, it's easy to disable swap, label the >> partition, and re-enable swap. :) >> >> -- >> Freddie Cash >> fjwcash@gmail.com >> > > Well the thing is I like use glabel in place of a fs label as it makes > my devices all names something similar > /dev/label/thingie rather then have /dev/ufs/rootfs and > /dev/label/swap , I'll have /dev/label/rootfs /dev/label/swap. > Also I dont think you can easily change a live label either . "tunefs -L" changes UFS label (/dev/ufs/label) and does not use extra 512 bytes of space. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 21:14:38 2011 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 ECC6B10656C0 for ; Fri, 14 Jan 2011 21:14:37 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 519A68FC13 for ; Fri, 14 Jan 2011 21:14:37 +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 p0ELEXFB079560 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 14 Jan 2011 21:14:33 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk p0ELEXFB079560 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1295039673; bh=BO5cwPfs+/ZjgTIKLnXjHKuGIYHXS49QuOAlsMTOy+M=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4D30BCAA.5090501@infracaninophile.co.uk>|Date:=20F ri,=2014=20Jan=202011=2021:14:18=20+0000|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.13)=20Gecko/20101207=20Thunderbird/3.1.7|MIME-Version:=201 .0|To:=20freebsd-stable@freebsd.org|Subject:=20Re:=20Next=20ZFSv28 =20patchset=20ready=20for=20testing.|References:=20<20110114181925 .49e5ee2d@dijkstra>|In-Reply-To:=20<20110114181925.49e5ee2d@dijkst ra>|X-Enigmail-Version:=201.1.1|OpenPGP:=20id=3D60AE908C|Content-T ype:=20multipart/signed=3B=20micalg=3Dpgp-sha1=3B=0D=0A=20protocol =3D"application/pgp-signature"=3B=0D=0A=20boundary=3D"------------ enig02CC3976FEC9C1196632C15A"; b=lM0KhiYnH8cs982HZIus2jYGLtp5ZcJ3j72fXmX5siZqIkgQFa1Ovqtwndx0nWCqb WbQ3i4kMTPzmYDTmpIHoEzqhTGsxosM1Ju8/6feAEd2XI6xmaRchGCKcqcGlJPRAPT Cj8R8hXJP1b+zfsjwDFuZDSd1nK6S+VcG/IrqNG4= Message-ID: <4D30BCAA.5090501@infracaninophile.co.uk> Date: Fri, 14 Jan 2011 21:14:18 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20110114181925.49e5ee2d@dijkstra> In-Reply-To: <20110114181925.49e5ee2d@dijkstra> X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig02CC3976FEC9C1196632C15A" X-Virus-Scanned: clamav-milter 0.96.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Subject: Re: Next ZFSv28 patchset ready for testing. 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, 14 Jan 2011 21:14:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig02CC3976FEC9C1196632C15A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14/01/2011 17:19, Christopher J. Ruwe wrote: > Hi, >=20 > I would like to test Martin Matuskas patch for ZFS v28 against stable. > Can I patch against any stable (like stable of today) or does it > necessarily need to be the stable-tree of the date specified in the > patch-file? >=20 > If the latter should be true, how do I obtain a stable tree of any > given date? >=20 > Thanks for any help, kind regards, You can generally patch against a version more recent than when the patch was released, up to a point. If there are commits to any of the files touched by the patch after the patch date, then the patch may not apply properly, or the result may not work correctly. However, in this case Martin generally produces an updated patch-set within a fairly short amount of time. To obtain a copy of the stable sources as of a specific date, depends on how you're getting the sources. csup(1) or cvsup(1) has a date parameter which you can add to your sup-file. See csup(1). svn has a number of options for checking out previous revisions. Either work out the revision corresponding to the date you want, or give the date like so: svn co -r '{ 2010-01-14 }' Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig02CC3976FEC9C1196632C15A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wvLcACgkQ8Mjk52CukIxBBACfa4l4xvdRin2voWLQ7yw2NTwC zO0An0nDXbfwR402+/QgCxuVN/1XzhAc =YyNU -----END PGP SIGNATURE----- --------------enig02CC3976FEC9C1196632C15A-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 14 22:18:07 2011 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 9EE9C106564A for ; Fri, 14 Jan 2011 22:18:07 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (t1850.greatnet.de [83.133.124.96]) by mx1.freebsd.org (Postfix) with ESMTP id 0874D8FC15 for ; Fri, 14 Jan 2011 22:18:06 +0000 (UTC) Received: (qmail 1990 invoked from network); 14 Jan 2011 22:18:04 -0000 Received: from p5b37a39b.dip.t-dialin.net (HELO dijkstra) (smtpallow@91.55.163.155) by t1850.greatnet.de with ESMTPA; 14 Jan 2011 22:18:04 -0000 Date: Fri, 14 Jan 2011 23:18:00 +0100 From: "Christopher J. Ruwe" To: freebsd-stable@freebsd.org Message-ID: <20110114231800.6dcca6f3@dijkstra> In-Reply-To: <4D30BCAA.5090501@infracaninophile.co.uk> References: <20110114181925.49e5ee2d@dijkstra> <4D30BCAA.5090501@infracaninophile.co.uk> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/wFqNHCqZYuaN_ycplqgLZ/3"; protocol="application/pgp-signature" Subject: Re: Next ZFSv28 patchset ready for testing. 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, 14 Jan 2011 22:18:07 -0000 --Sig_/wFqNHCqZYuaN_ycplqgLZ/3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 14 Jan 2011 21:14:18 +0000 Matthew Seaman wrote: > On 14/01/2011 17:19, Christopher J. Ruwe wrote: > > Hi, > >=20 > > I would like to test Martin Matuskas patch for ZFS v28 against > > stable. Can I patch against any stable (like stable of today) or > > does it necessarily need to be the stable-tree of the date > > specified in the patch-file? > >=20 > > If the latter should be true, how do I obtain a stable tree of any > > given date? > >=20 > > Thanks for any help, kind regards, >=20 > You can generally patch against a version more recent than when the > patch was released, up to a point. If there are commits to any of the > files touched by the patch after the patch date, then the patch may > not apply properly, or the result may not work correctly. >=20 [...] >=20 > To obtain a copy of the stable sources as of a specific date, depends > on how you're getting the sources. >=20 > csup(1) or cvsup(1) has a date parameter which you can add to your > sup-file. See csup(1). Thank you for your help. Pulling RELENG_8 from a specific date (18th Dec) worked just fine, as well as patching, machine is compiling now. Nothing more to do now, so I will check back after breakfast tomorrow morning. I am hoping this will also fix my geli issue on boot ... Cheers, --=20 Christopher TZ GMT + 1 --Sig_/wFqNHCqZYuaN_ycplqgLZ/3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQIcBAEBAgAGBQJNMMumAAoJEJTIKW/o3iwUGaEQAJXbpAJX8HGM2L2zN9q+m3YO H9FF2mo3XBHnbvbYArKGE5Bgg/WxPDxIOUpaptYoOcd52Eec2pi+1OyMKdrOuxft sonBY+z6VGTRB3aBoNgof8HFh7WIv4e3p9rGAzEGvZcBDncvGEPUdnLO8psOEWBr CPlbyARtLA+vkse8b1qWcaNecyewU5d1NYbXZuhaSG3qB9ZVaoCK4eay90XUifbG AfUa9NSItRQJUuF32BKMmVU4zgxlnWIg1Sg9SyS0whg+qme0/qq+wvJ/ZPzdqBXm Q/bbQdG59Han1t0TVBJ6mQnRpabocowSuSaJs1KLZYA1E3RR7/YMZzEmJUwJ0UM3 I0y5cL1fqSsW/nBKu+FLfo4W4GzdYBNhBuLSXj6h0eg1DiMfRDDXHS3th8tklgGp fVA2XekGbBqdYxbBWBHyKoFEwS77ImuwNscYf2CULFTvfingzJkbdQJTmvh5kZuI J7eGP78SZDVAm1Nvt30WSfDtA829LBAGUEFQ5Y3hDdVD95h7RG3R6fsuM/gadtdC OoPHCO0jTcDaQ+CPOUcK9wfOUEedpiHpMyl5JvrMmhEKlrWaeHoJavX+jyrM1caA KqSAwavGwHhePygkYLrn4kLtMObKGuxe7+Ck2+b5TINzPKqHl0CGL6BriM0YAg0r oFiYZsDweR3qXkVtsYcU =ymRc -----END PGP SIGNATURE----- --Sig_/wFqNHCqZYuaN_ycplqgLZ/3-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 00:37:37 2011 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 C65D71065675 for ; Sat, 15 Jan 2011 00:37:37 +0000 (UTC) (envelope-from stuartb@4gh.net) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7E6AC8FC1D for ; Sat, 15 Jan 2011 00:37:37 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 14 Jan 2011 19:08:49 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr16.lnh.mail.rcn.net (MOS 4.1.9-GA) with ESMTP id AVY94255; Fri, 14 Jan 2011 19:07:50 -0500 X-Auth-ID: stuartb.4gh@starpower.net Received: from unknown (HELO freeman.4gh.net) ([208.58.5.9]) by smtp01.lnh.mail.rcn.net with ESMTP; 14 Jan 2011 19:07:51 -0500 Received: by freeman.4gh.net (Postfix, from userid 1001) id 099E9130DA4; Fri, 14 Jan 2011 19:07:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by freeman.4gh.net (Postfix) with ESMTP id 044E4130D64 for ; Fri, 14 Jan 2011 19:07:49 -0500 (EST) Date: Fri, 14 Jan 2011 19:07:49 -0500 (EST) From: Stuart Barkley To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Policy on static linking ? 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, 15 Jan 2011 00:37:37 -0000 Being an old curmudgeon, I have historically preferred static linking for some of the points raised (no external installation dependencies, I know the application is complete and will work, use of believed good library versions, custom library patches are possible, etc). The other response about needing to be explicit at link time about the libraries in use is something I like in general. A programmer should know all the dependencies of his application. I find it really disgusting when some little application uses a library with a huge dependency base. This is especially true when the application doesn't use most of that base. Some applications pull needed library code into their own source tree and build their own versions. This can be useful in some cases. Some of the bloatware application do this to excess. If it is necessary, I don't know how anyone can make a proper and usable security declaration about an application which is dynamically linked against other libraries. On the other hand, the state of shared libraries is probably much better than the last time I actually cared. People have learned about maintaining backward compatibility, API versioning, etc. If you make good decisions about the libraries you depend upon life can be much better. Don't just select libraries that are flavor of the day but instead use libraries with good solid history and apparent ongoing support. The other response indicates that even libc with some of the core functionality doesn't work well with static linking. I'm disappointed about that state of things, but the reasons seem valid. It is also interesting about system version compatibility and providing shims for older ABIs. Also, in this day of interpreted code (perl, etc) much of that code base is equivalent to dynamically linked. At $DAYJOB I've seen a few things with their own versions of certain common libraries included. I've been curious about the reasons but haven't had time to investigate. The use of dlopen() also looks to make "plugins" much easier to do than with statically linked programs. Plugin equivalents in some of my earlier applications where much trickier to write since they also needed to be statically linked with a very reduced set of available support routines (basically none for the things I was doing at the time). Today, I probably wouldn't fight using dynamic linking. I do wish things would continue to provide static libraries unless there are specific reasons static libraries won't work. I would like to see libc remain fully functional when statically linked. I would like documentation about functionality lost when statically linking with libc. Mostly just some ramblings, Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 02:02:58 2011 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 83845106566B for ; Sat, 15 Jan 2011 02:02:58 +0000 (UTC) (envelope-from corky1951@comcast.net) 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 647108FC12 for ; Sat, 15 Jan 2011 02:02:58 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta13.emeryville.ca.mail.comcast.net with comcast id vTn51f00C1wfjNsADdpncp; Sat, 15 Jan 2011 01:49:47 +0000 Received: from comcast.net ([98.203.142.76]) by omta23.emeryville.ca.mail.comcast.net with comcast id vdpl1f00J1f6R9u8jdpmE1; Sat, 15 Jan 2011 01:49:47 +0000 Received: by comcast.net (sSMTP sendmail emulation); Fri, 14 Jan 2011 17:49:45 -0800 Date: Fri, 14 Jan 2011 17:49:45 -0800 From: Charlie Kester To: freebsd-stable@freebsd.org Message-ID: <20110115014945.GA11894@comcast.net> Mail-Followup-To: freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailer: Mutt 1.4.2.3i X-Composer: Vim 7.3 Subject: Re: Policy on static linking ? 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, 15 Jan 2011 02:02:58 -0000 On Fri 14 Jan 2011 at 06:07:37 PST Pete French wrote: > >I recently wanted to use libdespatch, but I found that the port >didn't install the static libraries. I filed a PR, and found out >from the reponse that this was deliberate, and that a number of >other ports were deliberately excluding static libraries too. Some >good reasons where given, which I wont reporduce here, >as you can read them at: http://www.freebsd.org/cgi/query-pr.cgi?pr=151306 > Interesting reading. One thing bothers me, however, about the reasons given against static linking. Surely, if a port statically links to a library, it calls out that library on a LIB_DEPENDS line and the dependency is reflected in the package database? So, if a security issue comes up with the library, it wouldn't be difficult to flag the dependent port as one that needs to be recompiled using the newly-patched library? The user only gets the patches to the shared library after he reads and responds to the security notice, or when he's doing a normal update of his ports. Correct? Well then, what's different about the scenario when it's a static library? What am I missing here? From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 02:59:50 2011 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 DFA511065674 for ; Sat, 15 Jan 2011 02:59:50 +0000 (UTC) (envelope-from nicolai.mollerup@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 607398FC12 for ; Sat, 15 Jan 2011 02:59:50 +0000 (UTC) Received: by gxk8 with SMTP id 8so1408843gxk.13 for ; Fri, 14 Jan 2011 18:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=f9fZ2xfDc4eF9mub54EUSGye9XjM3ay/Cy3M5akRO/0=; b=TE2884+zSWzHQPf567s7hAwjHsaqdirIZP1Ppwtmj/3xZpeuhrIzQmjeUnPbkbuAN3 SzBP95dad51gpBX6zpovi4gHWxmXjgtX7yoIhaf/cJjlFduuYVZXNBJ2lYpZfYAsYXns qN3hOd3G6Bo2srWDZP1oNYCfmZOKFTFO1VY6g= 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=H367x1xO+YsJATfgECQaQrzhsc7WniRotAbZBPDSF7/5N/9+zIB1jO4ygJ8bBHFNR0 cO06GPq5Tn4cMB9B5pd4x3FEwBp3/cyohuHdhhk3nYIyjon+AnStVNxJJzwzajwYGhxE oDThc701xE+36Kt78k0QXKE6VKRFB3JU0vohQ= MIME-Version: 1.0 Received: by 10.101.67.8 with SMTP id u8mr1059718ank.45.1295058788055; Fri, 14 Jan 2011 18:33:08 -0800 (PST) Received: by 10.100.166.11 with HTTP; Fri, 14 Jan 2011 18:33:08 -0800 (PST) In-Reply-To: <4D309A81.7040808@rdtc.ru> References: <628423291.20110112210201@serebryakov.spb.ru> <4D309A81.7040808@rdtc.ru> Date: Sat, 15 Jan 2011 03:33:08 +0100 Message-ID: From: Nicolai Mollerup To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: geom_label, fstab without device names & swap partition? 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, 15 Jan 2011 02:59:51 -0000 >> >> Well the thing is I like use glabel in place of a fs label as it makes >> my devices all names something similar >> /dev/label/thingie rather then have /dev/ufs/rootfs and >> /dev/label/swap =A0, I'll have /dev/label/rootfs /dev/label/swap. >> Also I dont think you can easily change a live label either . > > "tunefs -L" changes UFS label (/dev/ufs/label) and does not use extra 512= bytes of space. > If you read the original post, swap is mentioned. UFS labels doesnt really work with swap partitions. Therefore glabel is the more obvious choice for simple names to partitions, and honestly 512 bytes on harddrive... I would recommend using gpart to create partitions and labels, and then put them in a gmirror for future convenience. #gmirror status Name Status Components mirror/root COMPLETE gpt/root0 mirror/var COMPLETE gpt/var0 mirror/tmp COMPLETE gpt/tmp0 mirror/usr COMPLETE gpt/usr0 mirror/swap COMPLETE gpt/swap0 This way its very easy to add an extra harddrive and add that to the mirror if needed later on. /Nicolai From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 09:07:14 2011 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 16D891065673 for ; Sat, 15 Jan 2011 09:07:14 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id A26878FC08 for ; Sat, 15 Jan 2011 09:07:13 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id C8A44138529; Sat, 15 Jan 2011 10:07:12 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dhB-Nj5Kiqns; Sat, 15 Jan 2011 10:07:10 +0100 (CET) Received: from [10.9.8.1] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id 856E2138521; Sat, 15 Jan 2011 10:07:10 +0100 (CET) Message-ID: <4D3163BE.9020607@FreeBSD.org> Date: Sat, 15 Jan 2011 10:07:10 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "Christopher J. Ruwe" References: <20110114181925.49e5ee2d@dijkstra> In-Reply-To: <20110114181925.49e5ee2d@dijkstra> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Next ZFSv28 patchset ready for testing. 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, 15 Jan 2011 09:07:14 -0000 To use with newer stable (or releng/8.2) use a more recent patch from: http://people.freebsd.org/~mm/patches/zfs/v28/ Cheers, mm Dňa 14.01.2011 18:19, Christopher J. Ruwe wrote / napísal(a): > Hi, > > I would like to test Martin Matuskas patch for ZFS v28 against stable. > Can I patch against any stable (like stable of today) or does it > necessarily need to be the stable-tree of the date specified in the > patch-file? > > If the latter should be true, how do I obtain a stable tree of any > given date? > > Thanks for any help, kind regards, From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 10:11:51 2011 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 0A08810658C6 for ; Sat, 15 Jan 2011 10:11:51 +0000 (UTC) (envelope-from jyavenard@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7F9E8FC17 for ; Sat, 15 Jan 2011 10:11:50 +0000 (UTC) Received: by iyb26 with SMTP id 26so3335740iyb.13 for ; Sat, 15 Jan 2011 02:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hn+sNM9XMEt6z9UwsTDUGucP5X/B0QGKHWDyjqV3U+k=; b=FpCHFZjjZ5c6B+2MIn7S7T+NDHd/toQ9H3zzYrCHHDC4ynsFTsOM7blzm7T+1nncCW rRBrrTgz3BBvWqJr+LWXjlh0Xtwr7Ta/YZUfgTy3sIRZGghWIFWBeTYB3f93YrO0AyjV ShpiruDcmV+WqpIOJxSciFf82XAzfKrr09Jbg= 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=TzEMDkIxb4ea+H5m3smpT3HnFoIIwrTVQxCAm1u8T8I52dRiL+s5+9BJMaT36aG3fX gX+rri2PyEMPqU5ctpebaI+9xy/PSq92+UPCP6vGM03zrNzcMDxrCSRnQq3Fa6J/4G0r RT8ZVom2nqiXZM9/U6Fcp1DLTOl/qDCq5KuLw= MIME-Version: 1.0 Received: by 10.42.169.9 with SMTP id z9mr1962474icy.89.1295086310245; Sat, 15 Jan 2011 02:11:50 -0800 (PST) Received: by 10.42.172.69 with HTTP; Sat, 15 Jan 2011 02:11:50 -0800 (PST) In-Reply-To: References: Date: Sat, 15 Jan 2011 21:11:50 +1100 Message-ID: From: Jean-Yves Avenard To: Pete French Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org" Subject: Re: Policy on static linking ? 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, 15 Jan 2011 10:11:51 -0000 On Friday, 14 January 2011, Pete French wrote: > I build code using static linking for deployment across a set of > machines. For me this has a lot of advantages - I know that the > code will run, no matter what the state of the ports is on the > machine, and if there is a need to upgrade a library then I do it > once on the build machine, rebuild the executable, and rsync it out > to the leaf nodes. Only one place to track security updates, only > one place where I need to have all the porst the code depends on > installed. I actually tried to compile a port against another and have it link statically, but I couldn't find a way to do so without hacking the configure script. I was wondering if there was another (and easier) way to do so... I use ldap for authentication purposes, along with pam_ldap and nss_ldap If I compile openldap-client against openssl from ports, then it creates massive problems elsewhere. For example, base ssh server will now crash due to using different libcrypto. compiling ports will also become impossible as bsd tar itself crash (removing ldap call from nsswitch.conf is required to work again) I was then advised in the freebsd forums to uninstall openssl port, compile openldap against openssl base, install it, then re-install openssl port. (I have to use openssl from ports with apache/subversion to fix a bug with TLSv1 making svn commit crash under some circumstances) I dislike this method, because should openldap gets upgraded again and be linked against openssl port, I will lock myself out of the machine again due to sshd crashing. Just like what happened today :( So how can I configure openldap-client to link against libssl and libcrypto statically? Thanks From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 16:03:35 2011 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 AECDD106566C; Sat, 15 Jan 2011 16:03:35 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 022508FC08; Sat, 15 Jan 2011 16:03:34 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0FG3SnN009800; Sat, 15 Jan 2011 22:03:29 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D31C54B.60504@rdtc.ru> Date: Sat, 15 Jan 2011 22:03:23 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: bug-followup@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: i386/153947: Make buildworld fails in hastd/token.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: Sat, 15 Jan 2011 16:03:35 -0000 This also breaks source upgrade path from RELENG_7. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 16:35:45 2011 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 691311065674 for ; Sat, 15 Jan 2011 16:35:45 +0000 (UTC) (envelope-from lists@pingle.org) Received: from willow.pingle.org (willow.pingle.org [68.76.213.30]) by mx1.freebsd.org (Postfix) with ESMTP id 360428FC12 for ; Sat, 15 Jan 2011 16:35:44 +0000 (UTC) Received: from willow.pingle.org (unknown [127.0.0.1]) by willow.pingle.org (Postfix) with ESMTP id 97C391149D for ; Sat, 15 Jan 2011 11:20:36 -0500 (EST) X-Virus-Scanned: amavisd-new at pingle.org Received: from willow.pingle.org ([127.0.0.1]) by willow.pingle.org (willow.pingle.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55foaJ+44jAy for ; Sat, 15 Jan 2011 11:20:34 -0500 (EST) Received: from [192.168.20.12] (hpcw.hpcisp.com [68.76.213.13]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jim) by willow.pingle.org (Postfix) with ESMTPSA id 7D0CF11497 for ; Sat, 15 Jan 2011 11:20:34 -0500 (EST) Message-ID: <4D31C94B.2030807@pingle.org> Date: Sat, 15 Jan 2011 11:20:27 -0500 From: Jim Pingle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: FreeBSD References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Policy on static linking ? 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, 15 Jan 2011 16:35:45 -0000 On 1/15/2011 5:11 AM, Jean-Yves Avenard wrote: > If I compile openldap-client against openssl from ports, then it > creates massive problems elsewhere. [snip problems] > I dislike this method, because should openldap gets upgraded again and > be linked against openssl port, I will lock myself out of the machine > again due to sshd crashing. Just like what happened today :( Problems like that are why I do my package compiling in a jail, or a VM, and not on a live system. Jails are simple to setup these days and it's handy to be able to just blow away the jail and recreate it if things go wonky with dependencies when experimenting with package builds. (Or snapshot a VM before trying) I've taken a stab or two at compiling ports static in the past and also came up empty. It would be really nice to be able to build a single tbz package that would run once installed and that didn't have to pull down every other dependency individually. There are a number of ways that dependency tracking with packages can go sideways, and it isn't fun when trying to ensure that said packages install OK when transplanting them to other machines... Jim From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 17:01:45 2011 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 8C323106566C; Sat, 15 Jan 2011 17:01:45 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id D40798FC16; Sat, 15 Jan 2011 17:01:44 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0FH1hSC010385; Sat, 15 Jan 2011 23:01:43 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D31D2F2.3070704@rdtc.ru> Date: Sat, 15 Jan 2011 23:01:38 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: bug-followup@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.ORG Subject: Re: kern/138341: [nanobsd] [patch] 8.0-BETA3: nanobsd build broken due to sysipc kernel module 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, 15 Jan 2011 17:01:45 -0000 'make MODULES_WITH_WORLD=yes buildworld' is still broken for 8.2-PRERELEASE. Here is a patch for RELENG_8 sources updated today: --- sys/modules/cryptodev/Makefile.orig 2010-08-23 12:13:44.000000000 +0700 +++ sys/modules/cryptodev/Makefile 2010-08-23 12:13:52.000000000 +0700 @@ -3,6 +3,6 @@ .PATH: ${.CURDIR}/../../opencrypto KMOD = cryptodev SRCS = cryptodev.c -SRCS += bus_if.h device_if.h +SRCS += bus_if.h device_if.h opt_compat.h .include --- sys/modules/dtrace/lockstat/Makefile.orig 2009-09-16 23:05:25.000000000 +0800 +++ sys/modules/dtrace/lockstat/Makefile 2009-09-16 23:05:45.000000000 +0800 @@ -5,7 +5,7 @@ KMOD= lockstat SRCS= lockstat.c -SRCS+= vnode_if.h +SRCS+= vnode_if.h opt_kdtrace.h CFLAGS+= -I${.CURDIR}/../../../cddl/compat/opensolaris \ -I${.CURDIR}/../../../cddl/contrib/opensolaris/uts/common \ --- sys/modules/mqueue/Makefile.orig 2010-04-24 17:47:03.000000000 +0700 +++ sys/modules/mqueue/Makefile 2010-04-24 17:47:14.000000000 +0700 @@ -5,6 +5,6 @@ KMOD= mqueuefs SRCS= uipc_mqueue.c \ vnode_if.h \ - opt_posix.h + opt_posix.h opt_compat.h .include --- sys/modules/sysvipc/sysvmsg/Makefile.orig 2009-08-30 19:12:16.000000000 +0800 +++ sys/modules/sysvipc/sysvmsg/Makefile 2009-09-19 01:12:18.000000000 +0800 @@ -3,6 +3,6 @@ .PATH: ${.CURDIR}/../../../kern KMOD= sysvmsg -SRCS= sysv_msg.c opt_sysvipc.h +SRCS= sysv_msg.c opt_sysvipc.h opt_compat.h .include --- sys/modules/sysvipc/sysvsem/Makefile.orig 2009-08-30 19:52:13.000000000 +0800 +++ sys/modules/sysvipc/sysvsem/Makefile 2009-08-30 19:52:33.000000000 +0800 @@ -3,6 +3,6 @@ .PATH: ${.CURDIR}/../../../kern KMOD= sysvsem -SRCS= sysv_sem.c opt_sysvipc.h +SRCS= sysv_sem.c opt_sysvipc.h opt_compat.h .include From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 21:31:14 2011 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 E4DBC106566C for ; Sat, 15 Jan 2011 21:31:14 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 902428FC0A for ; Sat, 15 Jan 2011 21:31:14 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9641D45EA7; Sat, 15 Jan 2011 22:31:12 +0100 (CET) Received: from localhost (89-73-192-49.dynamic.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0466A45E87; Sat, 15 Jan 2011 22:31:06 +0100 (CET) Date: Sat, 15 Jan 2011 22:30:56 +0100 From: Pawel Jakub Dawidek To: "Christopher J. Ruwe" Message-ID: <20110115213056.GE5335@garage.freebsd.pl> References: <20110113220019.0c18c7ef@dijkstra> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DqhR8hV3EnoxUkKN" Content-Disposition: inline In-Reply-To: <20110113220019.0c18c7ef@dijkstra> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: geli problems after installkernel & installworld 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, 15 Jan 2011 21:31:15 -0000 --DqhR8hV3EnoxUkKN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 13, 2011 at 10:00:19PM +0100, Christopher J. Ruwe wrote: > I use a mostly geli encrypted hd on my Thinkpad R500, > with /compat, /usr, /tmp and /var all on the encrypted geli provider. >=20 > After an upgrade of kernel and world (STABLE), I experience a weird > issue: While booting, I am asked for the geli passphrase as usual. > Completing password authentication for geli returns a success message, >=20 > cryptosoft0: on motherboard > GEOM_ELI: Device ada0p3.eli created. > GEOM_ELI: Encryption: AES-CBC 256 > GEOM_ELI: Crypto: software >=20 > however, the zpool on geli is unavailable. >=20 > Logging in a root, I can attach the geli provider manually as geli > itself should do from /etc/rc.conf. After a successful zfs mount -a, I > can resume as usual after manually starting the /usr/local/rc.d > services.=20 >=20 > Neither have I noticed a change in the device names nor any unusual > messages from dmesg. Currently, I am doing a new compile run on world > and kernel to attempt anew tomorrow. >=20 > Am I missing something? Can you show the output of 'geli list' from a running system? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --DqhR8hV3EnoxUkKN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk0yEg8ACgkQForvXbEpPzTT5ACdGLG/0bL0qOdOeHOQuJwRXf4x hO4An1ahfgmXWK8fmGWXm9Yx93Z2oip7 =IuDq -----END PGP SIGNATURE----- --DqhR8hV3EnoxUkKN-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 15 22:48:59 2011 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 38CEB106564A for ; Sat, 15 Jan 2011 22:48:59 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id B4CBD8FC08 for ; Sat, 15 Jan 2011 22:48:58 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id ADDD81DD634; Sat, 15 Jan 2011 23:48:57 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 9B211174CB; Sat, 15 Jan 2011 23:48:57 +0100 (CET) Date: Sat, 15 Jan 2011 23:48:57 +0100 From: Jilles Tjoelker To: Jean-Yves Avenard Message-ID: <20110115224857.GA42408@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , Pete French Subject: Re: Policy on static linking ? 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, 15 Jan 2011 22:48:59 -0000 On Sat, Jan 15, 2011 at 09:11:50PM +1100, Jean-Yves Avenard wrote: > On Friday, 14 January 2011, Pete French wrote: > > I build code using static linking for deployment across a set of > > machines. For me this has a lot of advantages - I know that the > > code will run, no matter what the state of the ports is on the > > machine, and if there is a need to upgrade a library then I do it > > once on the build machine, rebuild the executable, and rsync it out > > to the leaf nodes. Only one place to track security updates, only > > one place where I need to have all the porst the code depends on > > installed. > I actually tried to compile a port against another and have it link > statically, but I couldn't find a way to do so without hacking the > configure script. I was wondering if there was another (and easier) > way to do so... > I use ldap for authentication purposes, along with pam_ldap and nss_ldap > If I compile openldap-client against openssl from ports, then it > creates massive problems elsewhere. > For example, base ssh server will now crash due to using different > libcrypto. compiling ports will also become impossible as bsd tar > itself crash (removing ldap call from nsswitch.conf is required to > work again) > I was then advised in the freebsd forums to uninstall openssl port, > compile openldap against openssl base, install it, then re-install > openssl port. > (I have to use openssl from ports with apache/subversion to fix a bug > with TLSv1 making svn commit crash under some circumstances) > I dislike this method, because should openldap gets upgraded again and > be linked against openssl port, I will lock myself out of the machine > again due to sshd crashing. Just like what happened today :( > So how can I configure openldap-client to link against libssl and > libcrypto statically? I think this can be solved with a symbol versioning trick. By applying a different version to all symbols from each OpenSSL version, the dynamic linker will be able to distinguish between different versions of OpenSSL and will use the correct OpenSSL version each object was linked to, even if there are multiple OpenSSL versions in the process. Note that each OpenSSL version should still have its own SONAME (the security/openssl port does this). The version script can be as simple as (substituting the version) OPENSSL_0.9.8 { global: *; }; and needs to be in the top level and in the engines directory. For it to work completely, both base and the port need to be patched. Old binaries continue to work but the benefit only appears after recompilation. The SONAME needs to be bumped when the version string is changed or deleted (but not when it is initially added), otherwise binaries will stop working. This also means that making the change cannot be undone without breaking binary compatibility. What will not work is allocating an OpenSSL structure in one object linked to one OpenSSL version and then using it in another object linked to another OpenSSL version. That would require true symbol versioning, keeping compatibility with old versions in the same library with the same SONAME. Unlike the approach I propose, that would be a lot of work and can only be done by the OpenSSL project, and I think their policy is not to do such extra work for ABI compatibility. If they change their mind they will probably start with the symver version of the previous release so as to remain compatible with what various Linux distributions are doing. Also, a side effect is that it is no longer possible to cheat by symlinking different OpenSSL versions. The approach has been used by Debian for some time. Links: http://chris.dzombak.name/blog/2010/03/building-openssl-with-symbol-versioning/ http://chris.dzombak.name/files/openssl/openssl-0.9.8l-symbolVersioning.diff http://rt.openssl.org/Ticket/Display.html?id=1222&user=guest&pass=guest -- Jilles Tjoelker