From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 05:24: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 01789106566C for ; Sun, 6 Feb 2011 05:24:17 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 60BB58FC12 for ; Sun, 6 Feb 2011 05:24:15 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-198-167.lns6.adl6.internode.on.net [203.122.198.167]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p164nDHs043032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 6 Feb 2011 15:19:14 +1030 (CST) (envelope-from darius@dons.net.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 6 Feb 2011 15:19:12 +1030 To: freebsd-stable Stable Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Subject: Xorg in swwrt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2011 05:24:17 -0000 I updated ports (portmaster -a basically) on this 8.2-PRE box and now I = find X takes a long, long time to start up and uses lots of CPU. It = shows the wchan as swwrt. eg.. last pid: 21791; load averages: 0.12, 0.29, 0.23 = up 0+16:09:07 15:16:15 496 processes: 2 running, 494 sleeping CPU: 0.0% user, 0.0% nice, 46.7% system, 0.0% interrupt, 53.3% idle Mem: 190M Active, 33M Inact, 3217M Wired, 198M Cache, 15M Buf, 171M Free Swap: 4096M Total, 621M Used, 3475M Free, 15% Inuse, 212K Out PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 21787 fiona 1 76 0 168M 134M swwrt 0 0:04 32.37% = Xorg 21788 darius 1 76 0 31860K 4868K pause 1 0:00 1.17% zsh 2081 darius 4 44 0 113M 11620K ucond 1 9:45 0.10% = python2.6 656 root 1 44 0 24392K 1096K select 1 3:44 0.00% ppp 1881 darius 32 52 0 135M 8804K uwait 0 2:24 0.00% = python2.6 Does anyone else see this? If it matters I am using the xf86-video-ati driver (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is = 0x0000 (=3D=3D) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (--) RADEON(0): Chipset: "ATI Radeon HD 4200" (ChipID =3D 0x9710) (--) RADEON(0): Linear framebuffer at 0x00000000d8000000 (II) RADEON(0): PCI card detected [snip] (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 (II) RADEON(0): Depth moves disabled by default (II) RADEON(0): Allocating from a screen of 131008 kb (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset = 0x00b7c000 (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset = 0x00b80000 (II) RADEON(0): Will use 11760 kb for front buffer at offset 0x00000000 (II) RADEON(0): Will use 64 kb for PCI GART at offset 0x07ff0000 (II) RADEON(0): Will use 11760 kb for back buffer at offset 0x00b84000 (II) RADEON(0): Will use 11760 kb for depth buffer at offset 0x01700000 (II) RADEON(0): Will use 47616 kb for textures at offset 0x0227c000 (II) RADEON(0): Will use 48080 kb for X Server offscreen at offset = 0x050fc000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEON(0): [drm] framebuffer handle =3D 0xd8000000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle =3D 0x3 (II) RADEON(0): [drm] installed DRM signal handler [in swwrt] Does anyone else see this? Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 09:19: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 723BE10656C5 for ; Sun, 6 Feb 2011 09:19:00 +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 52DDB8FC15 for ; Sun, 6 Feb 2011 09:18:59 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 4ZJz1g0011GXsucA1ZJze8; Sun, 06 Feb 2011 09:18:59 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta07.emeryville.ca.mail.comcast.net with comcast id 4ZJy1g00M2tehsa8UZJyuC; Sun, 06 Feb 2011 09:18:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5E9FB9B427; Sun, 6 Feb 2011 01:18:58 -0800 (PST) Date: Sun, 6 Feb 2011 01:18:58 -0800 From: Jeremy Chadwick To: Daniel O'Connor Message-ID: <20110206091858.GA50782@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 Stable Subject: Re: Xorg in swwrt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2011 09:19:00 -0000 On Sun, Feb 06, 2011 at 03:19:12PM +1030, Daniel O'Connor wrote: > I updated ports (portmaster -a basically) on this 8.2-PRE box and now I find X takes a long, long time to start up and uses lots of CPU. It shows the wchan as swwrt. > > eg.. > last pid: 21791; load averages: 0.12, 0.29, 0.23 up 0+16:09:07 15:16:15 > 496 processes: 2 running, 494 sleeping > CPU: 0.0% user, 0.0% nice, 46.7% system, 0.0% interrupt, 53.3% idle > Mem: 190M Active, 33M Inact, 3217M Wired, 198M Cache, 15M Buf, 171M Free > Swap: 4096M Total, 621M Used, 3475M Free, 15% Inuse, 212K Out > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 21787 fiona 1 76 0 168M 134M swwrt 0 0:04 32.37% Xorg > 21788 darius 1 76 0 31860K 4868K pause 1 0:00 1.17% zsh > 2081 darius 4 44 0 113M 11620K ucond 1 9:45 0.10% python2.6 > 656 root 1 44 0 24392K 1096K select 1 3:44 0.00% ppp > 1881 darius 32 52 0 135M 8804K uwait 0 2:24 0.00% python2.6 > > Does anyone else see this? I don't use X, but: The swwrt state is induced by function swap_pager_putpages() in src/sys/vm/swap_pager.c. It seems to imply that there's a certain degree of swapping going on in/out of the process, but the code is beyond my understanding. I see 621MB of swap used on that machine, so it doesn't sound that far-fetched. It would also help to know when your kernel was built (uname -a), since there have been changed during the 8.2-PRERELEASE lifetime to the above code file. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/swap_pager.c procstat -kk and procstat -v on PID 21787 might also be helpful. -- | 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 Feb 6 09:28: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 E9A85106566B for ; Sun, 6 Feb 2011 09:28:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 852218FC1C for ; Sun, 6 Feb 2011 09:28:14 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p169RWtI000581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Feb 2011 11:27:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p169RWRc003568; Sun, 6 Feb 2011 11:27:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p169RWGB003567; Sun, 6 Feb 2011 11:27:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Feb 2011 11:27:32 +0200 From: Kostik Belousov To: "Daniel O'Connor" Message-ID: <20110206092732.GH78089@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SKW69dzTt3T8RCN0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable Stable Subject: Re: Xorg in swwrt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2011 09:28:16 -0000 --SKW69dzTt3T8RCN0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 06, 2011 at 03:19:12PM +1030, Daniel O'Connor wrote: > I updated ports (portmaster -a basically) on this 8.2-PRE box and now I f= ind X takes a long, long time to start up and uses lots of CPU. It shows th= e wchan as swwrt. >=20 > eg.. > last pid: 21791; load averages: 0.12, 0.29, 0.23 = up 0+16:09:07 15:16:15 > 496 processes: 2 running, 494 sleeping > CPU: 0.0% user, 0.0% nice, 46.7% system, 0.0% interrupt, 53.3% idle > Mem: 190M Active, 33M Inact, 3217M Wired, 198M Cache, 15M Buf, 171M Free > Swap: 4096M Total, 621M Used, 3475M Free, 15% Inuse, 212K Out >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMM= AND > 21787 fiona 1 76 0 168M 134M swwrt 0 0:04 32.37% Xorg swwrt means waiting for the syncronous swap-out to finish. This is consistent with the top indicating the non-trivial amount of swap space used and swapout happen right now. Look at the working set of the application you are starting. Another thing that is standing out is huge wired count. > 21788 darius 1 76 0 31860K 4868K pause 1 0:00 1.17% zsh > 2081 darius 4 44 0 113M 11620K ucond 1 9:45 0.10% pyth= on2.6 > 656 root 1 44 0 24392K 1096K select 1 3:44 0.00% ppp > 1881 darius 32 52 0 135M 8804K uwait 0 2:24 0.00% pyth= on2.6 >=20 > Does anyone else see this? > If it matters I am using the xf86-video-ati driver > (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is = 0x0000 > (=3D=3D) RADEON(0): RGB weight 888 > (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) > (--) RADEON(0): Chipset: "ATI Radeon HD 4200" (ChipID =3D 0x9710) > (--) RADEON(0): Linear framebuffer at 0x00000000d8000000 > (II) RADEON(0): PCI card detected >=20 > [snip] >=20 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (II) RADEON(0): Depth moves disabled by default > (II) RADEON(0): Allocating from a screen of 131008 kb > (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00b7c000 > (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x00b80000 > (II) RADEON(0): Will use 11760 kb for front buffer at offset 0x00000000 > (II) RADEON(0): Will use 64 kb for PCI GART at offset 0x07ff0000 > (II) RADEON(0): Will use 11760 kb for back buffer at offset 0x00b84000 > (II) RADEON(0): Will use 11760 kb for depth buffer at offset 0x01700000 > (II) RADEON(0): Will use 47616 kb for textures at offset 0x0227c000 > (II) RADEON(0): Will use 48080 kb for X Server offscreen at offset 0x050f= c000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:01:05.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0 > (II) [drm] DRM interface version 1.2 > (II) [drm] DRM open master succeeded. > (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. > (II) RADEON(0): [drm] framebuffer handle =3D 0xd8000000 > (II) RADEON(0): [drm] added 1 reserved context for kernel > (II) RADEON(0): X context handle =3D 0x3 > (II) RADEON(0): [drm] installed DRM signal handler > [in swwrt] >=20 > Does anyone else see this? >=20 > Thanks. >=20 > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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" --SKW69dzTt3T8RCN0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1OaYMACgkQC3+MBN1Mb4hRBwCglYr4DBXYD1ivqbEdy4VMhM4d vzAAoOyrrWTg/Y2Ax3Xal5NPbbeVimCz =oAUS -----END PGP SIGNATURE----- --SKW69dzTt3T8RCN0-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 09:30: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 98F24106566B for ; Sun, 6 Feb 2011 09:30:20 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2002:d596:2a92:2:155::]) by mx1.freebsd.org (Postfix) with ESMTP id 5207A8FC12 for ; Sun, 6 Feb 2011 09:30:20 +0000 (UTC) Received: from tykburk.tyknet.cn.dom (unknown [IPv6:2002:5996:79d2:1:224:8cff:fe02:de01]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 100F7638DAB; Sun, 6 Feb 2011 10:30:18 +0100 (CET) X-DKIM: OpenDKIM Filter v2.2.2 mail.tyknet.dk 100F7638DAB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1296984619; bh=baOvvf7JBVvFr4FATGjLtU6+XgZ6m3tN+scezzKcMU4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=THP6c8BwrSADCYhdZEVdlh7VirhgbWNfs6oXoQtNdhNWUrCD5VjdmL6+ePkh+zKZ4 xiqZnIchcH3kdd0CnHqB4Vwj6AiZL/5ktwr3pDvl6DXQriKuMRUB5szerheRmKLV0Y CkL0SwPO19FzdXk1AbcyfH7w6SNdLxJqFTA4zKo0= Message-ID: <4D4E6A2A.9010101@gibfest.dk> Date: Sun, 06 Feb 2011 10:30:18 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101231 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jan Henrik Sylvester References: <1296763905.31910.37.camel@bauer.cse.buffalo.edu> <4D4B2E83.9090301@janh.de> In-Reply-To: <4D4B2E83.9090301@janh.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.2-RC3/7.4-RC3 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 09:30:20 -0000 On 03.02.2011 23:38, Jan Henrik Sylvester wrote: > On 01/-10/-28163 20:59, Ken Smith wrote: >> The freebsd-update(8) utility supports binary upgrades of i386 and amd64 >> systems running earlier FreeBSD releases. Systems running 8.0-RELEASE, >> 8.1-RELEASE, 8.2-BETA1, 8.2-RC1 or 8.2-RC2 can upgrade as follows: >> >> # freebsd-update upgrade -r 8.2-RC3 > > While it does work on i386, it fails on amd64: > > Fetching metadata signature for 8.2-RC3 from update5.FreeBSD.org... > failed. > Fetching metadata signature for 8.2-RC3 from update4.FreeBSD.org... > failed. > Fetching metadata signature for 8.2-RC3 from update2.FreeBSD.org... > failed. > Fetching metadata signature for 8.2-RC3 from update3.FreeBSD.org... > failed. > > In contrast to the other releases, betas, and candidates, there is no > amd64 directory listed for 8.2-RC3, only i386: > > http://update4.freebsd.org/8.2-RC3/ > > (It has been this way for a few days now, but since there was no > announcement, I thought it was still being worked on.) > Hello, For what it's worth, I am still seeing the same thing on an AMD64 8.2-RC2 system: $ sudo freebsd-update -v debug upgrade -r 8.2-RC3 Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching public key from update4.FreeBSD.org... fetch: http://update4.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update5.FreeBSD.org... fetch: http://update5.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update2.FreeBSD.org... fetch: http://update2.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update3.FreeBSD.org... fetch: http://update3.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. No mirrors remaining, giving up. Best regards Thomas Steen Rasmussen From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 09:41: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 ACE68106566B for ; Sun, 6 Feb 2011 09:41:27 +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 1F8978FC13 for ; Sun, 6 Feb 2011 09:41:26 +0000 (UTC) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta03.westchester.pa.mail.comcast.net with comcast id 4ZhS1g0010QuhwU53ZhSDX; Sun, 06 Feb 2011 09:41:26 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta02.westchester.pa.mail.comcast.net with comcast id 4ZhR1g00T2tehsa3NZhSjU; Sun, 06 Feb 2011 09:41:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7F9C99B427; Sun, 6 Feb 2011 01:41:24 -0800 (PST) Date: Sun, 6 Feb 2011 01:41:24 -0800 From: Jeremy Chadwick To: Kostik Belousov Message-ID: <20110206094124.GA51336@icarus.home.lan> References: <20110206092732.GH78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110206092732.GH78089@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Daniel O'Connor , freebsd-stable Stable Subject: Re: Xorg in swwrt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2011 09:41:27 -0000 On Sun, Feb 06, 2011 at 11:27:32AM +0200, Kostik Belousov wrote: > On Sun, Feb 06, 2011 at 03:19:12PM +1030, Daniel O'Connor wrote: > > I updated ports (portmaster -a basically) on this 8.2-PRE box and now I find X takes a long, long time to start up and uses lots of CPU. It shows the wchan as swwrt. > > > > eg.. > > last pid: 21791; load averages: 0.12, 0.29, 0.23 up 0+16:09:07 15:16:15 > > 496 processes: 2 running, 494 sleeping > > CPU: 0.0% user, 0.0% nice, 46.7% system, 0.0% interrupt, 53.3% idle > > Mem: 190M Active, 33M Inact, 3217M Wired, 198M Cache, 15M Buf, 171M Free > > Swap: 4096M Total, 621M Used, 3475M Free, 15% Inuse, 212K Out > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 21787 fiona 1 76 0 168M 134M swwrt 0 0:04 32.37% Xorg > swwrt means waiting for the syncronous swap-out to finish. > This is consistent with the top indicating the non-trivial amount of > swap space used and swapout happen right now. > > Look at the working set of the application you are starting. > Another thing that is standing out is huge wired count. Regarding the large wired count: I'm willing to bet ZFS is in use on the machine, which would explain this (specifically ARC usage). -- | 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 Feb 6 10:13: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 DBE89106564A for ; Sun, 6 Feb 2011 10:12:59 +0000 (UTC) (envelope-from me@janh.de) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id 683768FC12 for ; Sun, 6 Feb 2011 10:12:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id A1C439001D; Sun, 6 Feb 2011 11:12:57 +0100 (CET) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FOoZCCW8te68; Sun, 6 Feb 2011 11:12:57 +0100 (CET) Received: from nb981.math (f054009092.adsl.alicedsl.de [78.54.9.92]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 57A9B9000A; Sun, 6 Feb 2011 11:12:57 +0100 (CET) Message-ID: <4D4E7423.4030104@janh.de> Date: Sun, 06 Feb 2011 11:12:51 +0100 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101219 Thunderbird/3.1.7 MIME-Version: 1.0 To: Thomas Steen Rasmussen References: <1296763905.31910.37.camel@bauer.cse.buffalo.edu> <4D4B2E83.9090301@janh.de> <4D4E6A2A.9010101@gibfest.dk> In-Reply-To: <4D4E6A2A.9010101@gibfest.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable-list freebsd Subject: Re: FreeBSD 8.2-RC3/7.4-RC3 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 10:13:00 -0000 On 02/06/2011 10:30, Thomas Steen Rasmussen wrote: > On 03.02.2011 23:38, Jan Henrik Sylvester wrote: >> On 01/-10/-28163 20:59, Ken Smith wrote: >>> The freebsd-update(8) utility supports binary upgrades of i386 and amd64 >>> systems running earlier FreeBSD releases. Systems running 8.0-RELEASE, >>> 8.1-RELEASE, 8.2-BETA1, 8.2-RC1 or 8.2-RC2 can upgrade as follows: >>> >>> # freebsd-update upgrade -r 8.2-RC3 >> >> While it does work on i386, it fails on amd64: >> >> Fetching metadata signature for 8.2-RC3 from update5.FreeBSD.org... >> failed. >> Fetching metadata signature for 8.2-RC3 from update4.FreeBSD.org... >> failed. >> Fetching metadata signature for 8.2-RC3 from update2.FreeBSD.org... >> failed. >> Fetching metadata signature for 8.2-RC3 from update3.FreeBSD.org... >> failed. >> >> In contrast to the other releases, betas, and candidates, there is no >> amd64 directory listed for 8.2-RC3, only i386: >> >> http://update4.freebsd.org/8.2-RC3/ >> >> (It has been this way for a few days now, but since there was no >> announcement, I thought it was still being worked on.) >> > Hello, > > For what it's worth, I am still seeing the same thing on an AMD64 > 8.2-RC2 system: > > $ sudo freebsd-update -v debug upgrade -r 8.2-RC3 > Looking up update.FreeBSD.org mirrors... 4 mirrors found. > Fetching public key from update4.FreeBSD.org... fetch: > http://update4.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found > failed. > Fetching public key from update5.FreeBSD.org... fetch: > http://update5.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found > failed. > Fetching public key from update2.FreeBSD.org... fetch: > http://update2.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found > failed. > Fetching public key from update3.FreeBSD.org... fetch: > http://update3.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found > failed. > No mirrors remaining, giving up. That is not the same thing. It is looking for "8.2-PRERELEASE": Your system is not on a binary release (a RELEASE, a BETA, or a RC) and cannot (regularly) be updated by freebsd-update. I have done freebsd-updates 8.1-RELEASE -> 8.2-BETA1 -> 8.2-RC1 -> 8.2-RC2 on amd64 successfully (as well as 8.2-RC1 -> 8.2-RC2 on i386). The bits are all there. For 8.2-RC3 and 7.4-RC3 the amd64 signatures are missing while the i386 ones are there: http://update4.freebsd.org/8.2-RC3/ Both amd64 and i386 are there for 8.2-RC2 (and every other RELEASE, BETA, and RC): http://update4.freebsd.org/8.2-RC2/ Interestingly, while the signature is missing, the binary patches are there for amd64 (and i386): http://update4.freebsd.org/to-8.2-RC3/ Cheers, Jan Henrik From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 11: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 E2127106564A for ; Sun, 6 Feb 2011 11:11:50 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 669948FC08 for ; Sun, 6 Feb 2011 11:11:49 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-198-167.lns6.adl6.internode.on.net [203.122.198.167]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p16BBPbh064633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 6 Feb 2011 21:41:26 +1030 (CST) (envelope-from darius@dons.net.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20110206092732.GH78089@deviant.kiev.zoral.com.ua> Date: Sun, 6 Feb 2011 21:41:24 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110206092732.GH78089@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1082) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable Stable Subject: Re: Xorg in swwrt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2011 11:11:51 -0000 On 06/02/2011, at 19:57, Kostik Belousov wrote: >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND >> 21787 fiona 1 76 0 168M 134M swwrt 0 0:04 32.37% = Xorg > swwrt means waiting for the syncronous swap-out to finish. > This is consistent with the top indicating the non-trivial amount of > swap space used and swapout happen right now. OK. There are a lot of daemons running, however it does the swwrt thing even = on a fresh boot, and even when there is a lot of free space. I wonder if it is doing something silly like trying to get some = contiguous memory or similar.. > Look at the working set of the application you are starting. > Another thing that is standing out is huge wired count. Yep, it's running ZFS :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 12:50: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 8B43E106566C for ; Sun, 6 Feb 2011 12:50:56 +0000 (UTC) (envelope-from spil.oss@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 57D9D8FC16 for ; Sun, 6 Feb 2011 12:50:55 +0000 (UTC) Received: by iwn39 with SMTP id 39so3749575iwn.13 for ; Sun, 06 Feb 2011 04:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=/ojvyefebwz0O8wPKoKjNnpUYEKCqf8gZXA1lYkbT0M=; b=tMoz9y299kepiEXlA0c0SabEf+gKxcRqFz6aAwu2G1Vx+ih1qiU+M0+8N9JS0+UBJF mFsocFZ9YNMTDQCmS/YsXPh3XPbpoWqCc25hL59fyTFcw8ntb4Gs2kap2mOHoBZ/31xl kUFM+D8uHBBGJK5+9JxnMseC84wqyDeCzDcEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=BSVP640R8npQPztSICGkXbvutci8AvY+Mu9V9WazVA6X7CBnQZq1XE8pCowwoWxTeS xCzz/DoQNf+ajmH3t/40CAMI1efu82pTuz2/3/uMGeQmxOQXnswy5R7bV/sAkF6TQbbR CgbI7Jvu9pBpE1hF2+HUqQiSQuFom0CCd/eEM= MIME-Version: 1.0 Received: by 10.42.239.136 with SMTP id kw8mr17064710icb.502.1296995023850; Sun, 06 Feb 2011 04:23:43 -0800 (PST) Received: by 10.42.159.65 with HTTP; Sun, 6 Feb 2011 04:23:43 -0800 (PST) Date: Sun, 6 Feb 2011 13:23:43 +0100 Message-ID: From: Spil Oss To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: bridge, ipv6 and rtadvd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 12:50:56 -0000 Hi All, Don't know if this is expected behaviour. My LAN (bge0) and WLAN (wlan0) are bridged in bridge0. I tried to run rtadvd on bridge0 but that didn't result in ipv6 addresses on my network. Tried running rtadvd directly /usr/sbin/rtadvd -c /etc/rtadvd.conf -f -D and saw the requests coming in from the client but that didn't result in a working ipv6 network. "Wild guessing" I tried loading it with /usr/sbin/rtadvd -f -D bge0 and I had a functional ipv6 network..... Is this intended behaviour? Am I doing something wrong? One of the other quirks I found was that the example rtadvd.conf line from http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html does not work, the :addrs#1: makes rtadvd report " bridge0 isn't defined in the configuration file or the configuration file doesn't exist." Kind regards, Spil. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 14:14:32 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 8FC58106564A for ; Sun, 6 Feb 2011 14:14:32 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 5676E8FC08 for ; Sun, 6 Feb 2011 14:14:32 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id CE894DD283; Sun, 6 Feb 2011 15:14:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Sun, 6 Feb 2011 15:14:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: spil.oss@gmail.com X-Mailer: Apple Mail (2.1082) Cc: freebsd-stable@freebsd.org Subject: Re: bridge, ipv6 and rtadvd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2011 14:14:32 -0000 Am 06.02.2011 um 13:23 schrieb Spil Oss: > Hi All, >=20 > Don't know if this is expected behaviour. >=20 > My LAN (bge0) and WLAN (wlan0) are bridged in bridge0. I tried to run > rtadvd on bridge0 but that didn't result in ipv6 addresses on my > network. Tried running rtadvd directly /usr/sbin/rtadvd -c > /etc/rtadvd.conf -f -D and saw the requests coming in from the client > but that didn't result in a working ipv6 network. "Wild guessing" I > tried loading it with /usr/sbin/rtadvd -f -D bge0 and I had a > functional ipv6 network..... >=20 > Is this intended behaviour? Am I doing something wrong? It appears to be intentional; there was some discussion a couple years = back, and the current behavior is for virtual interfaces to not receive = link-local addresses. Since I prefer to have bridge0 as the "main" interface, I simply = manually configured a link local address: ipv6_enable=3D"YES" ipv6_gateway_enable=3D"YES" ipv6_network_interfaces=3D"bridge0 gif0" ipv6_ifconfig_bridge0=3D"fe80::21c:c0ff:fe7d:8c50%bridge0" ipv6_ifconfig_bridge0_alias0=3D"2001:470:1f0b:XXXX::1 prefixlen 64" ipv6_ifconfig_gif0=3D"2001:470:1f0a:XXXX::2 2001:470:1f0a:XXXX::1 = prefixlen 128" $ cat /etc/rtadvd.conf=20 bridge0:\ :addrs#1:addr=3D"2001:470:1f0b:XXXX::":raflags#64: The IPv4 side of gif0 is brought up through a linkup script triggered by = mpd when my DSL connection comes up; that also updates the endpoint = address for the HE tunnel. Oh, this is on -stable from Dec 4. HTH, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 15:15:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 2062E1065672 for ; Sun, 6 Feb 2011 15:15:36 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id E786015031E for ; Sun, 6 Feb 2011 15:15:35 +0000 (UTC) Received: (qmail 72307 invoked from network); 6 Feb 2011 15:15:41 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 6 Feb 2011 15:15:41 -0000 Message-ID: <4D4EBB1D.8040000@freebsd.org> Date: Sun, 06 Feb 2011 07:15:41 -0800 From: Colin Percival User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101220 Thunderbird/3.0.11 MIME-Version: 1.0 To: FreeBSD Stable X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: (8.2|7.4)-RC3 amd64 bits in place now X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2011 15:15:36 -0000 Hi all, I forgot to upload some of the amd64 RC3 bits to the mirrors earlier. They should be in place now. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 21:17: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 DF748106566C for ; Sun, 6 Feb 2011 21:17:00 +0000 (UTC) (envelope-from greg@bonett.org) Received: from bonett.org (bonett.org [66.249.7.150]) by mx1.freebsd.org (Postfix) with ESMTP id BC7A98FC13 for ; Sun, 6 Feb 2011 21:17:00 +0000 (UTC) Received: from [192.168.1.216] (unknown [76.91.19.169]) by bonett.org (Postfix) with ESMTPSA id 91713124367 for ; Sun, 6 Feb 2011 21:01:15 +0000 (UTC) From: Greg Bonett To: freebsd-stable Content-Type: text/plain; charset="UTF-8" Date: Sun, 06 Feb 2011 13:01:14 -0800 Message-ID: <1297026074.23922.8.camel@ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 21:17:01 -0000 Hi all, I am experiencing hard lockup when running 8.1-RELEASE amd64. The last two times it has happened I was running a zpool scrub (high cpu and io load). /var/log/messages has some errors looking like: kernel: ad0: FAILURE - READ_DMA4 but these didn't seem to correspond to the exact time of the lockup. any suggestions? Thanks, Greg From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 21:40:32 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 839421065670 for ; Sun, 6 Feb 2011 21:40:32 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id E1A578FC15 for ; Sun, 6 Feb 2011 21:40:31 +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 BF44A13DF42; Mon, 7 Feb 2011 00:40:29 +0300 (MSK) Date: Mon, 7 Feb 2011 00:40:23 +0300 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <787079038.20110207004023@serebryakov.spb.ru> To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------6921DF2E50B683" Cc: "Vogel, Jack" Subject: em0 hangs without any messages like "Watchdog timeout", only down/up reset it. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 21:40:32 -0000 ------------6921DF2E50B683 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hello, Freebsd-stable. My em0 (the same, copy'n'paste hardware info from previous mnessage): em0@pci0:0:25:0: class=3D0x020000 card=3D0x82681043 chip=3D0x10bd808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xfea40000, size 131072, ena= bled bar [14] =3D type Memory, range 32, base 0xfea79000, size 4096, enabl= ed bar [18] =3D type I/O Port, range 32, base 0xdc00, size 32, enabled cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit cap 09[e0] =3D vendor (length 6) Intel cap 2 version 0 It is on-board LAN on Q35-based MoBo (ASUS P5E-VM DO) It hangs under load without any output. When it works with POLLING, it prints "Watchdog timeout" and reset automatically several times a day, but without POLLING it simply hangs with same frequency. It is 8.2-PRERELEASE (from RELENG_8), cvsupped AFTER 22 Jan (last commit to e1000 drivers family). Locally system works, but mbufs are overfilled. "ifconfig em0 down && ifconfig em0 up" solves problem. Output of different diagnostic tools (vmstat, netstat, ifconfig, sysctl of dev.em.0 tree, top -S) are attached in one file. Early (about half year ago) this sytem works without any problems with net. --=20 // Black Lion AKA Lev Serebryakov ------------6921DF2E50B683 Content-Type: application/octet-stream; name="net.hangup.log" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="net.hangup.log" Pj4+IGlmY29uZmlnIGVtMAplbTA6IGZsYWdzPThjNDM8VVAsQlJPQURDQVNULFJVTk5JTkcs T0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9 MjE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VN LFRTTzQsV09MX01BR0lDPgoJZXRoZXIgMDA6MWU6OGM6NzU6MDM6MGQKCWluZXQgMTkyLjE2 OC4xMzQuMyBuZXRtYXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE5Mi4xNjguMTM0LjI1NQoJ bWVkaWE6IEV0aGVybmV0IDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+CglzdGF0dXM6IGFjdGl2 ZQo8PDwgaWZjb25maWcgZW0wCj4+PiB2bXN0YXQgLW0KICAgICAgICAgVHlwZSBJblVzZSBN ZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQogICAgICAgbW9kdWxlICAgMTUyICAg IDE5SyAgICAgICAtICAgICAgMTUyICAxMjgKICAgICAgICAgIFVTQiAgICA3NiAgICA2Nksg ICAgICAgLSAgICAgICA4MCAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgsNDA5NgogICAg IG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAKICAgQ0FNIHBlcmlw aCAgICAyMiAgICAgNksgICAgICAgLSAgICAgICA0NCAgMTYsMzIsNjQsMjU2CiAgICAgcGNp X2xpbmsgICAgMTYgICAgIDJLICAgICAgIC0gICAgICAgMTYgIDY0LDEyOAogICAgICBhY3Bp c2VtICAgIDE5ICAgICAzSyAgICAgICAtICAgICAgIDE5ICAxMjgKICAgICAgc3VicHJvYyAg IDQ4OSAgIDQxNksgICAgICAgLSAgICA3MDc4NCAgNTEyLDQwOTYKICAgICAgICAgcHJvYyAg ICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgCiAgICAgIHNlc3Npb24gICAgMjMgICAg IDNLICAgICAgIC0gICAgIDQ2OTcgIDEyOAogICAgICAgICBwZ3JwICAgIDI1ICAgICA0SyAg ICAgICAtICAgICA0OTU3ICAxMjgKICAgICAgICAgY3JlZCAgICA2MiAgICAxMEsgICAgICAg LSAgNjcxODI3MiAgNjQsMjU2CiAgICAgIHVpZGluZm8gICAgIDggICAgIDNLICAgICAgIC0g IDExMjA3MjAgIDEyOCwyMDQ4CiAgICAgICBwbGltaXQgICAgMTIgICAgIDNLICAgICAgIC0g ICAgNjAzNzkgIDI1NgogICAgYWNwaV9wZXJmICAgICAyICAgICAxSyAgICAgICAtICAgICAg ICAyICAxMjgKICAgICAgQ0FNIFhQVCAgIDI5MyAgIDQyNUsgICAgICAgLSAgICAgIDQxNCAg MTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgKICAgICAgIERFVkZTMSAgIDE0NiAgICA3M0sg ICAgICAgLSAgICAgIDE1OCAgNTEyCiAgICBzeXNjdGx0bXAgICAgIDAgICAgIDBLICAgICAg IC0gICAgIDE2NjIgIDE2LDMyLDY0LDEyOCwyNTYKICAgIHN5c2N0bG9pZCAgMzUzNSAgIDE3 NUsgICAgICAgLSAgICAgMzYyOCAgMTYsMzIsNjQsMTI4CiAgICAgICBzeXNjdGwgICAgIDAg ICAgIDBLICAgICAgIC0gICAgMzcyOTMgIDE2LDMyLDY0CiAgICAgIGNhbGxvdXQgICAgIDEg ICA1MTJLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgICB1bXR4ICAgNTIyICAgIDY2SyAg ICAgICAtICAgICAgNTIyICAxMjgKICAgICBwMTAwMy4xYiAgICAgMSAgICAgMUsgICAgICAg LSAgICAgICAgMSAgMTYKICAgICAgICAgU1dBUCAgICAgMiAgIDU0OUsgICAgICAgLSAgICAg ICAgMiAgNjQKICAgICAgIERFVkZTMyAgIDE3MiAgICA0M0sgICAgICAgLSAgICAgIDE4NSAg MjU2CiAgICAgICBidXMtc2MgICAgNzEgICA0MTNLICAgICAgIC0gICAgIDEyNTEgIDE2LDMy LDY0LDEyOCwyNTYsNTEyLDIwNDgsNDA5NgogICAgICAgICAgYnVzICAgNjQwICAgIDY1SyAg ICAgICAtICAgICA0NDQwICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgIGRldnN0 YXQgICAgMTQgICAgMjlLICAgICAgIC0gICAgICAgMTQgIDMyLDQwOTYKIGV2ZW50aGFuZGxl ciAgICA2NyAgICAgNksgICAgICAgLSAgICAgICA2NyAgNjQsMTI4CiAgICAgICAgIGtvYmog ICAgOTMgICAzNzJLICAgICAgIC0gICAgICAxMTUgIDQwOTYKICAgICAgUGVyLWNwdSAgICAg MSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMzIKICAgICAgICBERVZGUyAgICAyMiAgICAg MUsgICAgICAgLSAgICAgICAyMyAgMTYsMTI4CiAgICAgICAgIHJtYW4gICAyMDIgICAgMjVL ICAgICAgIC0gICAgICA2MjMgIDE2LDMyLDEyOAogICAgICAgREVWRlNQICAgICAxICAgICAx SyAgICAgICAtICAgICAgICAzICA2NAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAg ICAtICAgICAyMTQ0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAg cGZzX25vZGVzICAgIDIxICAgICA2SyAgICAgICAtICAgICAgIDIxICAyNTYKICAgICAgICBz dGFjayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgNiAgMjU2CiAgICB0YXNrcXVldWUg ICAgMTUgICAgIDJLICAgICAgIC0gICAgICAgMTUgIDE2LDMyLDEyOAogICAgICAgVW5pdG5v ICAgIDEwICAgICAxSyAgICAgICAtICAgICAgMTAwICAzMiw2NAogICAgICAgICAgaW92ICAg ICAwICAgICAwSyAgICAgICAtICAgOTQ5MzAxICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAg ICAgc2VsZWN0ICAgMTkwICAgIDI0SyAgICAgICAtIDExNDAyMzk0ODIwICAxMjgsNTEyLDEw MjQKICAgICBpb2N0bG9wcyAgICAgMCAgICAgMEsgICAgICAgLSAyMzgyNzQxNzEgIDE2LDMy LDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICAgICBtc2cgICAgIDQgICAg MzBLICAgICAgIC0gICAgICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2VtICAgICA0ICAg IDExSyAgICAgICAtICAgICAgICA0ICA1MTIsMTAyNAogICAgICAgICAgc2htICAgICAxICAg IDIwSyAgICAgICAtICAgICAgICAxICAKICAgICAgICAgIHR0eSAgICAyMCAgICAyMEsgICAg ICAgLSAgICAgICAzMiAgMTAyNCwyMDQ4CiAgICAgICAgICBwdHMgICAgIDAgICAgIDBLICAg ICAgIC0gICAgICAgIDYgIDI1NgogICAgIG1idWZfdGFnICAgICAwICAgICAwSyAgICAgICAt ICAgICAgIDgzICAzMgogICAgICAgIHNobWZkICAgICAxICAgICA4SyAgICAgICAtICAgICAg ICAxICAKICAgICAgICAgR0VPTSAgIDE3NSAgICAzOEsgICAgICAgLSAgICAgIDc1NyAgMTYs MzIsNjQsMTI4LDI1Niw1MTIsMTAyNAogICAgICAgICAgcGNiICAgIDkyICAgIDE1SyAgICAg ICAtICA2ODU3OTk3ICAxNiwzMiwxMDI0LDIwNDgsNDA5NgogICAgICAgc29uYW1lICAgICA2 ICAgICAxSyAgICAgICAtIDI2OTY1MDIxICAxNiwzMiwxMjgKICAgICAgICAgIGFjbCAgICAg MCAgICAgMEsgICAgICAgLSAgICAyMDIyMCAgNDA5NgogICAgICAgYmlvYnVmICAgICAwICAg ICAwSyAgICAgICAtICAgICAgMTI3ICAyMDQ4CiAgICAgdmZzY2FjaGUgICAgIDEgIDEwMjRL ICAgICAgIC0gICAgICAgIDEgIAogICBjbF9zYXZlYnVmICAgICAwICAgICAwSyAgICAgICAt ICAgIDU5NzI0ICA2NCwxMjgKICBleHBvcnRfaG9zdCAgICAgMiAgICAgMUsgICAgICAgLSAg ICAgICAgMiAgMjU2CiAgICAgdmZzX2hhc2ggICAgIDEgICA1MTJLICAgICAgIC0gICAgICAg IDEgIAogICAgICAgdm5vZGVzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYK ICB2bm9kZW1hcmtlciAgICAgMCAgICAgMEsgICAgICAgLSAgIDI5NDQ5MyAgNTEyCiAgICAg ICAgbW91bnQgICAxMDQgICAgIDZLICAgICAgIC0gICAgICAzMDQgIDE2LDMyLDY0LDEyOCwy NTYsNTEyCiAgICAgICAgICBCUEYgICAgIDcgICAgIDlLICAgICAgIC0gICAgICAgMjAgIDEy OCwyNTYsNTEyLDQwOTYKICBldGhlcl9tdWx0aSAgICAxMiAgICAgMUsgICAgICAgLSAgICAg ICAyNiAgMTYsNjQKICAgICAgIGlmYWRkciAgICAxNCAgICAgN0sgICAgICAgLSAgICAgICAx NyAgMzIsNTEyLDQwOTYKICAgICAgICBpZm5ldCAgICAgMyAgICAgNUsgICAgICAgLSAgICAg ICAgMyAgMTI4LDIwNDgKICAgICAgICBjbG9uZSAgICAgMiAgICAgOEsgICAgICAgLSAgICAg ICAgMiAgNDA5NgogICAgICAgYXJwY29tICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAx ICAxNgogICAgICBsbHRhYmxlICAgICAzICAgICAySyAgICAgICAtICAgICAgIDU2ICAyNTYs NTEyCiAgICAgIGZ3X3hmZXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDEgIDI1Ngog ICAgIGZpcmV3aXJlICAgIDExICAgIDM1SyAgICAgICAtICAgICAgIDE0ICA2NCwxMjgsNTEy LDEwMjQsMjA0OCw0MDk2CiAgICAgIHNjc2lfZGEgICAgIDAgICAgIDBLICAgICAgIC0gICAg ICAgMTYgIDE2CiAgICAgICBrYmRtdXggICAgIDYgICAgMTBLICAgICAgIC0gICAgICAgIDYg IDE2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgICAgTEVEICAgICAxICAgICAxSyAgICAg ICAtICAgICAgICAxICAxMjgKICAgICAgIGlzYWRldiAgICAgNSAgICAgMUsgICAgICAgLSAg ICAgICAgNSAgMTI4CiAgICAgcm91dGV0YmwgICAgMTQgICAgIDRLICAgICAgIC0gICAxNzAx ODEgIDMyLDY0LDEyOCwyNTYsNTEyCiAgICAgICAgIGlnbXAgICAgIDIgICAgIDFLICAgICAg IC0gICAgICAgIDIgIDI1NgpDQU0gZGV2IHF1ZXVlICAgICA4ICAgICAxSyAgICAgICAtICAg ICAgICA4ICAxMjgKICAgIENBTSBxdWV1ZSAgICA0MyAgICAgM0sgICAgICAgLSAgICAgIDE0 OCAgMTYsMzIsNjQsMjU2CiAgICAgIENBTSBTSU0gICAgIDggICAgIDJLICAgICAgIC0gICAg ICAgIDggIDI1NgogIGlwX21vcHRpb25zICAgICA0ICAgICAxSyAgICAgICAtICAgICAgICA4 ICA2NCwyNTYKICAgICBpbl9tdWx0aSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgNSAg MjU2CiAgIGluX21maWx0ZXIgICAgIDIgICAgIDJLICAgICAgIC0gICAgICAgIDQgIDEwMjQK ICAgIGhvc3RjYWNoZSAgICAgMSAgICAyOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgc3lu Y2FjaGUgICAgIDEgICAgOTZLICAgICAgIC0gICAgICAgIDEgIAogICAgICBORlMgRkhBICAg ICAxICAgICAySyAgICAgICAtICAgICAgMzM5ICA2NCwyMDQ4CiAgICAgICAgICBycGMgICAz NDggICAxNzlLICAgICAgIC0gICAgIDExMzcgIDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgKYXVk aXRfZXZjbGFzcyAgIDE3MiAgICAgNksgICAgICAgLSAgICAgIDIxMSAgMzIKICAgICBzYXZl ZGlubyAgICAgMCAgICAgMEsgICAgICAgLSAgICAzNzMzNSAgMjU2CiAgICBuZXdkaXJibGsg ICAgIDAgICAgIDBLICAgICAgIC0gICAgICA1OTMgIDY0CiAgICAgICBkaXJyZW0gICAgIDAg ICAgIDBLICAgICAgIC0gICAyMTY1NTAgIDY0CiAgICAgICAgbWtkaXIgICAgIDAgICAgIDBL ICAgICAgIC0gICAgICAzMjggIDY0CiAgICAgICBkaXJhZGQgICAgIDIgICAgIDFLICAgICAg IC0gICAyMTY3MzMgIDY0CiAgICAgZnJlZWZpbGUgICAgIDIgICAgIDFLICAgICAgIC0gICAx MDQ0NjMgIDY0CiAgICAgZnJlZWJsa3MgICAgIDIgICAgIDFLICAgICAgIC0gICAxMDQ3NzIg IDI1NgogICAgIGZyZWVmcmFnICAgICAwICAgICAwSyAgICAgICAtICAgMTczNDgzICA2NAog ICBhbGxvY2luZGlyICAgICAwICAgICAwSyAgICAgICAtICAgNzE3ODEzICAxMjgKICAgICBp bmRpcmRlcCAgICAgMCAgICAgMEsgICAgICAgLSAgICAxMzgwOCAgNjQKICBhbGxvY2RpcmVj dCAgICAgMyAgICAgMUsgICAgICAgLSAgIDQ0Njk4MiAgMjU2CiAgICBibXNhZmVtYXAgICAg IDIgICAgIDFLICAgICAgIC0gICAxMDA1OTcgIDEyOAogICAgICAgbmV3YmxrICAgICAxICAg ICAxSyAgICAgICAtICAxMTY0Nzk2ICA2NCw1MTIKICAgICBpbm9kZWRlcCAgICAgNyAgIDUx NEsgICAgICAgLSAgIDIzODAxNSAgMjU2CiAgICAgIHBhZ2VkZXAgICAgIDMgICAxMjlLICAg ICAgIC0gICAgMzI0NzYgIDEyOAogIHVmc19kaXJoYXNoICAgMzI1ICAgMTAxSyAgICAgICAt ICAgNjIxNjQ0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICB1ZnNfbW91bnQgICAg MTUgICAxMjdLICAgICAgIC0gICAgICAgMTUgIDUxMiwyMDQ4LDQwOTYKICAgICAgVU1BSGFz aCAgICAgMyAgICAxMUsgICAgICAgLSAgICAgICAxMCAgNTEyLDEwMjQsMjA0OCw0MDk2CiAg ZGRiX2NhcHR1cmUgICAgIDEgICAgNDhLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgYWNw aWNhICAzODM3ICAgMzkzSyAgICAgICAtICAgIDg4NjE1ICAxNiwzMiw2NCwxMjgsMjU2LDUx MiwxMDI0LDIwNDgKICAgICAgICAgY2RldiAgICAgOCAgICAgMksgICAgICAgLSAgICAgICAg OCAgMjU2CiAgICB2bV9wZ2RhdGEgICAgIDIgICAxMjlLICAgICAgIC0gICAgICAgIDIgIDEy OAogICAgICBhY3BpZGV2ICAgIDc4ICAgICA1SyAgICAgICAtICAgICAgIDc4ICA2NAogICAg ICAgIHNpZ2lvICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NAogICAgIGZpbGVk ZXNjICAgIDYxICAgIDc3SyAgICAgICAtICAgMTEwMTQ5ICAxNiwzMiw2NCwxMjgsMjU2LDUx MiwxMDI0LDIwNDgsNDA5NgogICAgICAgICBrZW52ICAgIDc4ICAgIDExSyAgICAgICAtICAg ICAgIDgyICAxNiwzMiw2NCwxMjgKICAgICAgaW9fYXBpYyAgICAgMSAgICAgMksgICAgICAg LSAgICAgICAgMSAgMjA0OAogICAgICAga3F1ZXVlICAgICAyICAgIDEzSyAgICAgICAtICAg MjYzMTY2ICAyNTYsMjA0OCw0MDk2CiAgICAgIG1lbWRlc2MgICAgIDEgICAgIDRLICAgICAg IC0gICAgICAgIDEgIDQwOTYKICAgICBhY3BpdGFzayAgICAgMSAgICAgMksgICAgICAgLSAg ICAgICAgMSAgMjA0OAogICAgcHJvYy1hcmdzICAgIDI3ICAgICAySyAgICAgICAtICAgMjAw NDE1ICAxNiwzMiw2NCwxMjgsMjU2CiAgICAgYXRrYmRkZXYgICAgIDIgICAgIDFLICAgICAg IC0gICAgICAgIDIgIDY0CiAgICAgIGl0aHJlYWQgICAgNzYgICAgMTJLICAgICAgIC0gICAg ICAgNzYgIDMyLDEyOCwyNTYKICAgICAgZW50cm9weSAgMTAyNCAgICA2NEsgICAgICAgLSAg ICAgMTAyNCAgNjQKICAgICAgICAgVUFSVCAgICAgMyAgICAgMksgICAgICAgLSAgICAgICAg MyAgMTYsNTEyLDEwMjQKICAgICAgIEtUUkFDRSAgIDEwMCAgICAxM0sgICAgICAgLSAgICAg IDEwMCAgMTI4CiAgICAgICBsaW5rZXIgICAgNTcgICAgIDZLICAgICAgIC0gICAgICAgNjMg IDE2LDMyLDY0LDEyOCw1MTIKICAgICAgICBsb2NrZiAgICA1MyAgICAgNksgICAgICAgLSAg NjM1OTM0NCAgNjQsMTI4CiAgICAgICAgIHRlbXAgICAgMjIgICA0MDFLICAgICAgIC0gIDE0 MTAzMzkgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICBkZXZi dWYgMjAyMzAgMzU5MzNLICAgICAgIC0gICAgMjAzMjkgIDE2LDMyLDY0LDEyOCwyNTYsNTEy LDEwMjQsMjA0OCw0MDk2CiAgICAgICBVU0JkZXYgICAgNDcgICAgMTJLICAgICAgIC0gICAg ICAgNDcgIDY0LDEyOCwxMDI0CiAgICAgbmV4dXNkZXYgICAgIDMgICAgIDFLICAgICAgIC0g ICAgICAgIDMgIDE2CiAgIHJhaWQ1X2RhdGEgICAgIDYgIDUzODlLICAgICAgIC0gMjM1NDE2 NzU3ICAxNiw2NCw1MTIsNDA5Ngo8PDwgdm1zdGF0IC1tCj4+PiBuZXRzdGF0IC1tCjEyNjg2 LzYxODQvMTg4NzAgbWJ1ZnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsKQo0MjY3LzU4 NzcvMTAxNDQvMjA0ODAwIG1idWYgY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3Rv dGFsL21heCkKNDIzOS81ODU4IG1idWYrY2x1c3RlcnMgb3V0IG9mIHBhY2tldCBzZWNvbmRh cnkgem9uZSBpbiB1c2UgKGN1cnJlbnQvY2FjaGUpCjAvMjUxLzI1MS8xOTIwMDAgNGsgKHBh Z2Ugc2l6ZSkganVtYm8gY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21h eCkKMC8wLzAvNjQwMCA5ayBqdW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUv dG90YWwvbWF4KQowLzAvMC8zMjAwIDE2ayBqdW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJl bnQvY2FjaGUvdG90YWwvbWF4KQoxMTcwNUsvMTQzMDRLLzI2MDA5SyBieXRlcyBhbGxvY2F0 ZWQgdG8gbmV0d29yayAoY3VycmVudC9jYWNoZS90b3RhbCkKMC8wLzAgcmVxdWVzdHMgZm9y IG1idWZzIGRlbmllZCAobWJ1ZnMvY2x1c3RlcnMvbWJ1ZitjbHVzdGVycykKMC8wLzAgcmVx dWVzdHMgZm9yIGp1bWJvIGNsdXN0ZXJzIGRlbmllZCAoNGsvOWsvMTZrKQowLzAvMCBzZmJ1 ZnMgaW4gdXNlIChjdXJyZW50L3BlYWsvbWF4KQowIHJlcXVlc3RzIGZvciBzZmJ1ZnMgZGVu aWVkCjAgcmVxdWVzdHMgZm9yIHNmYnVmcyBkZWxheWVkCjAgcmVxdWVzdHMgZm9yIEkvTyBp bml0aWF0ZWQgYnkgc2VuZGZpbGUKMCBjYWxscyB0byBwcm90b2NvbCBkcmFpbiByb3V0aW5l cwo8PDwgbmV0c3RhdCAtbQo+Pj4gdG9wIC1TbmQgMQpsYXN0IHBpZDogNzAzNDQ7ICBsb2Fk IGF2ZXJhZ2VzOiAgMC4wMCwgIDAuMDAsICAwLjAwICB1cCA5KzE3OjM5OjMwICAgIDE2OjM5 OjU0CjExNCBwcm9jZXNzZXM6IDMgcnVubmluZywgOTIgc2xlZXBpbmcsIDE5IHdhaXRpbmcK Ck1lbTogOTNNIEFjdGl2ZSwgMTM3M00gSW5hY3QsIDM3OE0gV2lyZWQsIDc2TSBDYWNoZSwg MjEzTSBCdWYsIDUzTSBGcmVlClN3YXA6IDQwOTZNIFRvdGFsLCAzOTZLIFVzZWQsIDQwOTVN IEZyZWUKCgogIFBJRCBVU0VSTkFNRSAgICAgIFRIUiBQUkkgTklDRSAgIFNJWkUgICAgUkVT IFNUQVRFICAgQyAgIFRJTUUgICBXQ1BVIENPTU1BTkQKICAgMTEgcm9vdCAgICAgICAgICAg IDIgMTcxIGtpMzEgICAgIDBLICAgIDMySyBSVU4gICAgIDAgMzcxLjJIIDIwMC4wMCUgaWRs ZQogICAxMiByb290ICAgICAgICAgICAxOSAtNjAgICAgLSAgICAgMEsgICAzMDRLIFdBSVQg ICAgMCAzNzY6NDcgIDAuMTAlIGludHIKMzUyNDMgcnRvcnJlbnQgICAgICAgIDMgIDQ0ICAg IDAgOTgwNDRLIDgxNDI4SyBzZWxlY3QgIDEgIDM5LjFIICAwLjAwJSB0cmFuc21pc3Npb24t ZGFlbW9uCiAgICAwIHJvb3QgICAgICAgICAgICA5IC02OCAgICAwICAgICAwSyAgIDEyOEsg LSAgICAgICAxICA3ODozMiAgMC4wMCUga2VybmVsCiAgIDE0IHJvb3QgICAgICAgICAgIDMz IC02NCAgICAtICAgICAwSyAgIDUyOEsgLSAgICAgICAxICAzMzoyMSAgMC4wMCUgdXNiCiAg IDIwIHJvb3QgICAgICAgICAgICAyICAtOCAgICAtICAgICAwSyAgICAzMksgZ3I1ZG8gICAx ICAzMTowMSAgMC4wMCUgZ19yYWlkNQogICAgNCByb290ICAgICAgICAgICAgMSAgLTggICAg LSAgICAgMEsgICAgMTZLIC0gICAgICAgMCAgMjQ6NDIgIDAuMDAlIGdfZG93bgogICAgMyBy b290ICAgICAgICAgICAgMSAgLTggICAgLSAgICAgMEsgICAgMTZLIC0gICAgICAgMSAgMTg6 NTMgIDAuMDAlIGdfdXAKICAgMTcgcm9vdCAgICAgICAgICAgIDEgIDQ0ICAgIC0gICAgIDBL ICAgIDE2SyBzeW5jZXIgIDEgIDE2OjA3ICAwLjAwJSBzeW5jZXIKICAgMTMgcm9vdCAgICAg ICAgICAgIDEgLTE2ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDEgIDEyOjAyICAwLjAw JSB5YXJyb3cKICAgIDcgcm9vdCAgICAgICAgICAgIDEgIDQ0ICAgIC0gICAgIDBLICAgIDE2 SyBwc2xlZXAgIDEgICA2OjE3ICAwLjAwJSBwYWdlZGFlbW9uCiAgNzk5IHJvb3QgICAgICAg ICAgICAxICA0NCAgICAwIDIxMDY0SyAgMjc2MEsgc2VsZWN0ICAxICAgMDozMyAgMC4wMCUg bm1iZAo0MTE3MCB1dWNwICAgICAgICAgICAgMSAgNDQgICAgMCAgNjkyMEsgIDEzMjhLIHNl bGVjdCAgMSAgIDA6MzMgIDAuMDAlIG1lZ2F0ZWMKICAgIDIgcm9vdCAgICAgICAgICAgIDEg IC04ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDEgICAwOjI4ICAwLjAwJSBnX2V2ZW50 CiAgODcxIHJvb3QgICAgICAgICAgICAxICA0NCAgICAwIDExNzkySyAgMTk4OEsgc2VsZWN0 ICAxICAgMDoyOCAgMC4wMCUgbnRwZAogICAxOCByb290ICAgICAgICAgICAgMSAgNDQgICAg LSAgICAgMEsgICAgMTZLIHZscnV3dCAgMSAgIDA6MjYgIDAuMDAlIHZubHJ1CjQxMTcyIHV1 Y3AgICAgICAgICAgICAxICA0NCAgICAwIDEwOTMySyAgMjE3Nksgc2VsZWN0ICAxICAgMDox NCAgMC4wMCUgdXBzZAogMTA0MCByb290ICAgICAgICAgICAgMSAgNDQgICAgMCAxMjAyMEsg IDI5NTZLIHNlbGVjdCAgMSAgIDA6MTIgIDAuMDAlIHNlbmRtYWlsCgo8PDwgdG9wIC1TbmQg MQo+Pj4gc3lzY3RsIGRldi5lbS4wCmRldi5lbS4wLiVkZXNjOiBJbnRlbChSKSBQUk8vMTAw MCBOZXR3b3JrIENvbm5lY3Rpb24gNy4xLjkKZGV2LmVtLjAuJWRyaXZlcjogZW0KZGV2LmVt LjAuJWxvY2F0aW9uOiBzbG90PTI1IGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuR0JF QwpkZXYuZW0uMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgxMGJkIHN1YnZl bmRvcj0weDEwNDMgc3ViZGV2aWNlPTB4ODI2OCBjbGFzcz0weDAyMDAwMApkZXYuZW0uMC4l cGFyZW50OiBwY2kwCmRldi5lbS4wLm52bTogLTEKZGV2LmVtLjAuZGVidWc6IC0xCmRldi5l bS4wLnJ4X2ludF9kZWxheTogMjAwCmRldi5lbS4wLnR4X2ludF9kZWxheTogMjAwCmRldi5l bS4wLnJ4X2Fic19pbnRfZGVsYXk6IDQwMDAKZGV2LmVtLjAudHhfYWJzX2ludF9kZWxheTog NDAwMApkZXYuZW0uMC5yeF9wcm9jZXNzaW5nX2xpbWl0OiA0MDk2CmRldi5lbS4wLmZsb3df Y29udHJvbDogMwpkZXYuZW0uMC5saW5rX2lycTogMApkZXYuZW0uMC5tYnVmX2FsbG9jX2Zh aWw6IDAKZGV2LmVtLjAuY2x1c3Rlcl9hbGxvY19mYWlsOiAwCmRldi5lbS4wLmRyb3BwZWQ6 IDAKZGV2LmVtLjAudHhfZG1hX2ZhaWw6IDEKZGV2LmVtLjAucnhfb3ZlcnJ1bnM6IDAKZGV2 LmVtLjAud2F0Y2hkb2dfdGltZW91dHM6IDQKZGV2LmVtLjAuZGV2aWNlX2NvbnRyb2w6IDEw NzQ3OTA5NzYKZGV2LmVtLjAucnhfY29udHJvbDogNjcxNDE2MzQKZGV2LmVtLjAuZmNfaGln aF93YXRlcjogODE5MgpkZXYuZW0uMC5mY19sb3dfd2F0ZXI6IDY2OTIKZGV2LmVtLjAucXVl dWUwLnR4ZF9oZWFkOiAzMzM5CmRldi5lbS4wLnF1ZXVlMC50eGRfdGFpbDogMzMwMgpkZXYu ZW0uMC5xdWV1ZTAudHhfaXJxOiAwCmRldi5lbS4wLnF1ZXVlMC5ub19kZXNjX2F2YWlsOiAw CmRldi5lbS4wLnF1ZXVlMC5yeGRfaGVhZDogMTg1NgpkZXYuZW0uMC5xdWV1ZTAucnhkX3Rh aWw6IDE4NTUKZGV2LmVtLjAucXVldWUwLnJ4X2lycTogMApkZXYuZW0uMC5tYWNfc3RhdHMu ZXhjZXNzX2NvbGw6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnNpbmdsZV9jb2xsOiAwCmRldi5l bS4wLm1hY19zdGF0cy5tdWx0aXBsZV9jb2xsOiAwCmRldi5lbS4wLm1hY19zdGF0cy5sYXRl X2NvbGw6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmNvbGxpc2lvbl9jb3VudDogMApkZXYuZW0u MC5tYWNfc3RhdHMuc3ltYm9sX2Vycm9yczogMApkZXYuZW0uMC5tYWNfc3RhdHMuc2VxdWVu Y2VfZXJyb3JzOiAwCmRldi5lbS4wLm1hY19zdGF0cy5kZWZlcl9jb3VudDogMTYxNwpkZXYu ZW0uMC5tYWNfc3RhdHMubWlzc2VkX3BhY2tldHM6IDE4MjE0CmRldi5lbS4wLm1hY19zdGF0 cy5yZWN2X25vX2J1ZmY6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJlY3ZfdW5kZXJzaXplOiAw CmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X2ZyYWdtZW50ZWQ6IDUKZGV2LmVtLjAubWFjX3N0 YXRzLnJlY3Zfb3ZlcnNpemU6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJlY3ZfamFiYmVyOiAw CmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X2VycnM6IDEzMQpkZXYuZW0uMC5tYWNfc3RhdHMu Y3JjX2VycnM6IDEyNgpkZXYuZW0uMC5tYWNfc3RhdHMuYWxpZ25tZW50X2VycnM6IDAKZGV2 LmVtLjAubWFjX3N0YXRzLmNvbGxfZXh0X2VycnM6IDEKZGV2LmVtLjAubWFjX3N0YXRzLnhv bl9yZWN2ZDogMTczOQpkZXYuZW0uMC5tYWNfc3RhdHMueG9uX3R4ZDogMApkZXYuZW0uMC5t YWNfc3RhdHMueG9mZl9yZWN2ZDogMjkzNApkZXYuZW0uMC5tYWNfc3RhdHMueG9mZl90eGQ6 IDAKZGV2LmVtLjAubWFjX3N0YXRzLnRvdGFsX3BrdHNfcmVjdmQ6IDU0MTU2NzMyMQpkZXYu ZW0uMC5tYWNfc3RhdHMuZ29vZF9wa3RzX3JlY3ZkOiA1NDE1NDQyOTAKZGV2LmVtLjAubWFj X3N0YXRzLmJjYXN0X3BrdHNfcmVjdmQ6IDIxMTMwCmRldi5lbS4wLm1hY19zdGF0cy5tY2Fz dF9wa3RzX3JlY3ZkOiA2MjcyCmRldi5lbS4wLm1hY19zdGF0cy5yeF9mcmFtZXNfNjQ6IDAK ZGV2LmVtLjAubWFjX3N0YXRzLnJ4X2ZyYW1lc182NV8xMjc6IDAKZGV2LmVtLjAubWFjX3N0 YXRzLnJ4X2ZyYW1lc18xMjhfMjU1OiAwCmRldi5lbS4wLm1hY19zdGF0cy5yeF9mcmFtZXNf MjU2XzUxMTogMApkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzUxMl8xMDIzOiAwCmRl di5lbS4wLm1hY19zdGF0cy5yeF9mcmFtZXNfMTAyNF8xNTIyOiAwCmRldi5lbS4wLm1hY19z dGF0cy5nb29kX29jdGV0c19yZWN2ZDogNTg5NDMxMDIyMjUKZGV2LmVtLjAubWFjX3N0YXRz Lmdvb2Rfb2N0ZXRzX3R4ZDogMTM1NTExMDgxNDQyMgpkZXYuZW0uMC5tYWNfc3RhdHMudG90 YWxfcGt0c190eGQ6IDEwNDI0OTA1MTIKZGV2LmVtLjAubWFjX3N0YXRzLmdvb2RfcGt0c190 eGQ6IDEwNDI0OTA1MTIKZGV2LmVtLjAubWFjX3N0YXRzLmJjYXN0X3BrdHNfdHhkOiA0NjIz CmRldi5lbS4wLm1hY19zdGF0cy5tY2FzdF9wa3RzX3R4ZDogMjM2MzMKZGV2LmVtLjAubWFj X3N0YXRzLnR4X2ZyYW1lc182NDogMApkZXYuZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzY1 XzEyNzogMApkZXYuZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzEyOF8yNTU6IDAKZGV2LmVt LjAubWFjX3N0YXRzLnR4X2ZyYW1lc18yNTZfNTExOiAwCmRldi5lbS4wLm1hY19zdGF0cy50 eF9mcmFtZXNfNTEyXzEwMjM6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnR4X2ZyYW1lc18xMDI0 XzE1MjI6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnRzb190eGQ6IDMyNjM3MDYyMApkZXYuZW0u MC5tYWNfc3RhdHMudHNvX2N0eF9mYWlsOiAwCmRldi5lbS4wLmludGVycnVwdHMuYXNzZXJ0 czogMzUwMzEwNjg1CmRldi5lbS4wLmludGVycnVwdHMucnhfcGt0X3RpbWVyOiAwCmRldi5l bS4wLmludGVycnVwdHMucnhfYWJzX3RpbWVyOiAwCmRldi5lbS4wLmludGVycnVwdHMudHhf cGt0X3RpbWVyOiAwCmRldi5lbS4wLmludGVycnVwdHMudHhfYWJzX3RpbWVyOiAwCmRldi5l bS4wLmludGVycnVwdHMudHhfcXVldWVfZW1wdHk6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy50 eF9xdWV1ZV9taW5fdGhyZXNoOiAwCmRldi5lbS4wLmludGVycnVwdHMucnhfZGVzY19taW5f dGhyZXNoOiAwCmRldi5lbS4wLmludGVycnVwdHMucnhfb3ZlcnJ1bjogMApkZXYuZW0uMC53 YWtlOiAwCjw8PCBzeXNjdGwgZGV2LmVtLjAKPj4+IHN5c2N0bCBuZXQuaXNyCm5ldC5pc3Iu bnVtdGhyZWFkczogMQpuZXQuaXNyLm1heHByb3Q6IDE2Cm5ldC5pc3IuZGVmYXVsdHFsaW1p dDogMjU2Cm5ldC5pc3IubWF4cWxpbWl0OiAxMDI0MApuZXQuaXNyLmJpbmR0aHJlYWRzOiAw Cm5ldC5pc3IubWF4dGhyZWFkczogMQpuZXQuaXNyLmRpcmVjdDogMQpuZXQuaXNyLmRpcmVj dF9mb3JjZTogMQo8PDwgc3lzY3RsIG5ldC5pc3IK ------------6921DF2E50B683-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 01:32: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 D7260106566B for ; Mon, 7 Feb 2011 01:32:28 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mh0.csub.edu (mh0.csub.edu [136.168.1.94]) by mx1.freebsd.org (Postfix) with ESMTP id B859F8FC17 for ; Mon, 7 Feb 2011 01:32:28 +0000 (UTC) Received: from [136.168.251.248] ([136.168.251.248]) (authenticated bits=0) by mh0.csub.edu (8.14.3/8.14.3) with ESMTP id p1715CYo034960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Feb 2011 17:05:13 -0800 (PST) (envelope-from raj@csub.edu) X-DKIM: Sendmail DKIM Filter v2.8.3 mh0.csub.edu p1715CYo034960 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=csub.edu; s=mailhub.csub.edu; t=1297040713; bh=H9XtytvF6BT+AgX/uXxzARIhDXk=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=UjYN6u81WXGLtYaqLC59n2p1i5qi/Y5HCiFgOKu9pP6tHavTEfrJXoSbwnW8/KpuJ Hbe/kH2/752Oltq6eaDnWwfKPHPz7kh+yD1Y1anMg6u9CZRk9P5nxhEFl3aZfmsYgk q28gfasbPS65HXPdvL++yJnhkw61Y8h4u+7HKxso= Message-ID: <4D4F4544.3010606@csub.edu> Date: Sun, 06 Feb 2011 17:05:08 -0800 From: Russell Jackson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: bind 9.6.2 dnssec validation bug X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 01:32:28 -0000 I haven't seen any mention of this anywhere. Are there any plans to update BIND in the 8.1/8.2 branches? https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record -- Russell A. Jackson Network Analyst California State University, Bakersfield From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 04:55: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 802B1106564A for ; Mon, 7 Feb 2011 04:55:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 5D50B8FC15 for ; Mon, 7 Feb 2011 04:55:02 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 4ssD1g0030mlR8UA7sv2ok; Mon, 07 Feb 2011 04:55:02 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta11.emeryville.ca.mail.comcast.net with comcast id 4sv11g00R2tehsa8Xsv2eP; Mon, 07 Feb 2011 04:55:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 939C69B422; Sun, 6 Feb 2011 20:55:01 -0800 (PST) Date: Sun, 6 Feb 2011 20:55:01 -0800 From: Jeremy Chadwick To: Greg Bonett Message-ID: <20110207045501.GA15568@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1297026074.23922.8.camel@ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 04:55:03 -0000 On Sun, Feb 06, 2011 at 01:01:14PM -0800, Greg Bonett wrote: > Hi all, > I am experiencing hard lockup when running 8.1-RELEASE amd64. The last > two times it has happened I was running a zpool scrub (high cpu and io > load). /var/log/messages has some errors looking like: > kernel: ad0: FAILURE - READ_DMA4 > > but these didn't seem to correspond to the exact time of the lockup. > > any suggestions? Given that you're running 8.1-RELEASE, what sort of ZFS tunings are you using in /boot/loader.conf? Tuning is required on this version. The ad0 READ_DMA48 errors could indicate you have a hard disk with bad blocks or is going bad in a different manner. Please install ports/sysutils/smartmontools and provide output of "smartctl -a /dev/ad0" here and I can help you determine that. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 04:58: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 B0C21106564A for ; Mon, 7 Feb 2011 04:58:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 516D98FC08 for ; Mon, 7 Feb 2011 04:58:04 +0000 (UTC) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id 4sos1g0030xGWP85Fsy5LK; Mon, 07 Feb 2011 04:58:05 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta12.westchester.pa.mail.comcast.net with comcast id 4sy41g00U2tehsa3Ysy4SW; Mon, 07 Feb 2011 04:58:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E96BF9B422; Sun, 6 Feb 2011 20:58:02 -0800 (PST) Date: Sun, 6 Feb 2011 20:58:02 -0800 From: Jeremy Chadwick To: Russell Jackson Message-ID: <20110207045802.GB15568@icarus.home.lan> References: <4D4F4544.3010606@csub.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D4F4544.3010606@csub.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: bind 9.6.2 dnssec validation bug X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 04:58:05 -0000 On Sun, Feb 06, 2011 at 05:05:08PM -0800, Russell Jackson wrote: > I haven't seen any mention of this anywhere. Are there any plans to > update BIND in the 8.1/8.2 branches? > > https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record This was discussed vehemently in December 2010: http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/thread.html#60640 RELENG_8 (8.2-PRERELEASE as of the time of this writing) now has the official 9.6.3 as of a commit done by Doug Barton only a few hours ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/ http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/README As for whether or not this will be backported to the RELENG_8_1 tag, I would say "probably", but Doug would be authoritative on that. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 06:16: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 0B3F1106566C for ; Mon, 7 Feb 2011 06:16:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id AA2C38FC0A for ; Mon, 7 Feb 2011 06:16:23 +0000 (UTC) Received: (qmail 19756 invoked by uid 399); 7 Feb 2011 06:16:21 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Feb 2011 06:16:21 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D4F8E34.7030904@FreeBSD.org> Date: Sun, 06 Feb 2011 22:16:20 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D4F4544.3010606@csub.edu> <20110207045802.GB15568@icarus.home.lan> In-Reply-To: <20110207045802.GB15568@icarus.home.lan> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Russell Jackson , freebsd-stable@freebsd.org Subject: Re: bind 9.6.2 dnssec validation bug X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 06:16:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/06/2011 20:58, Jeremy Chadwick wrote: | On Sun, Feb 06, 2011 at 05:05:08PM -0800, Russell Jackson wrote: |> I haven't seen any mention of this anywhere. Are there any plans to |> update BIND in the 8.1/8.2 branches? |> |> https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record | | This was discussed vehemently in December 2010: | | http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/thread.html#60640 Different issue. :) | RELENG_8 (8.2-PRERELEASE as of the time of this writing) now has the | official 9.6.3 as of a commit done by Doug Barton only a few hours ago: | | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/ | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/README The 9.6.3 update was in ports the same day it was released, and is now in HEAD and RELENG_8. It's not relevant to RELENG_7, which is the issue that Jeremy posted above. I've sent the information about this problem to the release engineers, whether or not it makes it into 8.2-RELEASE is completely in their hands. However, the material that I sent them about this problem boiled down to the following: 1. This IS a significant bug for those who have DNSSEC validation enabled, however 2. Only a minority of our users have it enabled, and the named.conf in the base does not. 3. The bug can be worked around by restarting the affected name server _after_ it sees the new DS record, however 4. The only way to detect this problem is to wait for it to break. There are also the additional long-standing points that the latest releases of BIND are always in the ports, and anyone doing "serious" DNSSEC at this stage will want to be running 9.7.x (or the upcoming 9.8.x) because it supports RFC 5011 trust anchor rollover, among other nice DNSSEC features. | As for whether or not this will be backported to the RELENG_8_1 tag, I | would say "probably", but Doug would be authoritative on that. Back-porting it that far is definitely not being considered at the moment, and is unlikely to happen. hth, Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNT440AAoJEFzGhvEaGryED28IAJfW8yLH1YngzaKCMvopeZXq HQ5DstQpg9X9vSsqGABh/2A1rtFQsyUOIEK9Af/Rsc1X9w9MNgkEDDNfrJdk0JRK NiJuemPgZGaunhXcXZTyUOuHJOAtJJds/Tcabw2nZv/bagM9KGApOCSuBzbWpam/ 90pOttSKoMs5gxHn75BcSjxRiu4mYiEo7wgkdxF8OwEedHSI6y6SQoMXMgmYkjXS mpOR8AOtrHxN17an7yn26o6Sh3gUW5BSbsIHW921yiDv+lf0N8cT5+T+Livbso/k tciZMZbMExWt02gAzotOjdMX5npkDz4/dMT9L6R6rrPecsDnvdxWE+2gf73a0Lc= =n/On -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 06:34: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 0C588106564A for ; Mon, 7 Feb 2011 06:34:40 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mh1.csub.edu (mh1.csub.edu [136.168.1.95]) by mx1.freebsd.org (Postfix) with ESMTP id DC4828FC0C for ; Mon, 7 Feb 2011 06:34:39 +0000 (UTC) Received: from [136.168.251.248] ([136.168.251.248]) (authenticated bits=0) by mh1.csub.edu (8.14.3/8.14.3) with ESMTP id p176Yc1f047060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Feb 2011 22:34:38 -0800 (PST) (envelope-from raj@csub.edu) X-DKIM: Sendmail DKIM Filter v2.8.3 mh1.csub.edu p176Yc1f047060 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=csub.edu; s=mailhub.csub.edu; t=1297060479; bh=cnzMU9Pkk2nppDdJhkDCwAUnyMk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=RENnHoAVrFhqW8l3YUlZ0K+whbLXmefejq3vwqGMUftyrYREB5Oj6K8PTUHHOxFS1 FZpBsTsBFOnl2jBBikOeHovwBKLkx5jiBilLvYfeATIJitEZijFV91XDxPuqNKzoV1 2rVor7zzSUFQjt1pfGFpvg2EsSHTNx0Dy3Gd2uPI= Message-ID: <4D4F927C.7040103@csub.edu> Date: Sun, 06 Feb 2011 22:34:36 -0800 From: Russell Jackson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Doug Barton References: <4D4F4544.3010606@csub.edu> <20110207045802.GB15568@icarus.home.lan> <4D4F8E34.7030904@FreeBSD.org> In-Reply-To: <4D4F8E34.7030904@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Jeremy Chadwick Subject: Re: bind 9.6.2 dnssec validation bug X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 06:34:40 -0000 On 02/06/2011 10:16 PM, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/06/2011 20:58, Jeremy Chadwick wrote: > | On Sun, Feb 06, 2011 at 05:05:08PM -0800, Russell Jackson wrote: > |> I haven't seen any mention of this anywhere. Are there any plans to > |> update BIND in the 8.1/8.2 branches? > |> > |> > https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record > | > | This was discussed vehemently in December 2010: > | > | > http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/thread.html#60640 > > Different issue. :) > > | RELENG_8 (8.2-PRERELEASE as of the time of this writing) now has the > | official 9.6.3 as of a commit done by Doug Barton only a few hours ago: > | > | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/ > | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/README > > The 9.6.3 update was in ports the same day it was released, and is now > in HEAD and RELENG_8. It's not relevant to RELENG_7, which is the issue > that Jeremy posted above. I've sent the information about this problem > to the release engineers, whether or not it makes it into 8.2-RELEASE is > completely in their hands. However, the material that I sent them about > this problem boiled down to the following: > > 1. This IS a significant bug for those who have DNSSEC validation > enabled, however > 2. Only a minority of our users have it enabled, and the named.conf in > the base does not. > 3. The bug can be worked around by restarting the affected name server > _after_ it sees the new DS record, however > 4. The only way to detect this problem is to wait for it to break. > > There are also the additional long-standing points that the latest > releases of BIND are always in the ports, and anyone doing "serious" > DNSSEC at this stage will want to be running 9.7.x (or the upcoming > 9.8.x) because it supports RFC 5011 trust anchor rollover, among other > nice DNSSEC features. > > | As for whether or not this will be backported to the RELENG_8_1 tag, I > | would say "probably", but Doug would be authoritative on that. > > Back-porting it that far is definitely not being considered at the > moment, and is unlikely to happen. > Looks like I should just suck it up and start using the bind97 port. Thanks. -- Russell A. Jackson Network Analyst California State University, Bakersfield From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 07:50:43 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 DC4E6106566B for ; Mon, 7 Feb 2011 07:50:43 +0000 (UTC) (envelope-from greg@bonett.org) Received: from bonett.org (bonett.org [66.249.7.150]) by mx1.freebsd.org (Postfix) with ESMTP id 944928FC15 for ; Mon, 7 Feb 2011 07:50:43 +0000 (UTC) Received: from [192.168.1.216] (unknown [76.91.19.169]) by bonett.org (Postfix) with ESMTPSA id 202F0124367; Mon, 7 Feb 2011 07:50:42 +0000 (UTC) From: Greg Bonett To: Jeremy Chadwick In-Reply-To: <20110207045501.GA15568@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> Content-Type: text/plain; charset="UTF-8" Date: Sun, 06 Feb 2011 23:50:41 -0800 Message-ID: <1297065041.754.12.camel@ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 07:50:43 -0000 Thanks for the response. I have no tunings in /boot/loader.conf according to http://wiki.freebsd.org/ZFSTuningGuide for amd64 "FreeBSD 7.2+ has improved kernel memory allocation strategy and no tuning may be necessary on systems with more than 2 GB of RAM. " I have 8GB of ram. do you think this is wrong? Handbook recommends these (but says their test system has 1gb ram): vm.kmem_size="330M" vm.kmem_size_max="330M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" what do you recommend? I think the ad0: FAILURE - READ_DMA4 errors may be from a bad sata cable (or rather, a 12in sata cable connecting a drive that is one inch away) I'm ordering a new drive bay to improve this, but should a bad cable cause lockups? Thanks for your help. Here's my smartctl output: #smartctl -a /dev/ad0 smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.1-RELEASE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Green (Adv. Format) family Device Model: WDC WD10EARS-00Y5B1 Serial Number: WD-WCAV55616522 Firmware Version: 80.00A80 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: Exact ATA specification draft version not indicated Local Time is: Sun Feb 6 23:42:17 2011 PST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (20460) 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: ( 236) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x3031) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 121 121 021 Pre-fail Always - 6933 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 30 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 2664 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 28 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 27 193 Load_Cycle_Count 0x0032 135 135 000 Old_age Always - 196151 194 Temperature_Celsius 0x0022 125 114 000 Old_age Always - 22 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 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% 1536 - 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. On Sun, 2011-02-06 at 20:55 -0800, Jeremy Chadwick wrote: > On Sun, Feb 06, 2011 at 01:01:14PM -0800, Greg Bonett wrote: > > Hi all, > > I am experiencing hard lockup when running 8.1-RELEASE amd64. The last > > two times it has happened I was running a zpool scrub (high cpu and io > > load). /var/log/messages has some errors looking like: > > kernel: ad0: FAILURE - READ_DMA4 > > > > but these didn't seem to correspond to the exact time of the lockup. > > > > any suggestions? > > Given that you're running 8.1-RELEASE, what sort of ZFS tunings are you > using in /boot/loader.conf? Tuning is required on this version. > > The ad0 READ_DMA48 errors could indicate you have a hard disk with bad > blocks or is going bad in a different manner. Please install > ports/sysutils/smartmontools and provide output of "smartctl -a > /dev/ad0" here and I can help you determine that. > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 08:18: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 D547A106566B for ; Mon, 7 Feb 2011 08:18:44 +0000 (UTC) (envelope-from zbeeble@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 952D28FC15 for ; Mon, 7 Feb 2011 08:18:44 +0000 (UTC) Received: by iyb26 with SMTP id 26so4358302iyb.13 for ; Mon, 07 Feb 2011 00:18:44 -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=fhIFgLsbazmmYSNkiIeLkti0ywjC0EuuaEtfMqTHaSY=; b=bX9wKLIdycV7rXtb+wtjFkLQpEpgHYn75YgtcRQZFMdmbfdO0u0GHLpLX5pcGzojtK 9pSMf6XR6y+e8yoIxdh/K9582r94Npn97jzcoe7WM4IFm9dM5a5alR68+WLSA0n40qPu MgZ/jzKim7HghiYdR8MX9rglNJu7xlA5iX6Rs= 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=NgHIDalZpOM3fUk/aI10saeDx+AacJ+bel65CuVCBXTf9g8FdGK+xX2JsjiVGqupr3 Ax4gtpKqMfqjqInu5sxNKokZCVhwNpZorkSO+MmY/D9l/MvJ2nbBdlODRUXVTF4K1BWN AkXUmpoxbUyNeCzmu7XB3kJtWEWsdT2KOQz6I= MIME-Version: 1.0 Received: by 10.231.171.197 with SMTP id i5mr17046149ibz.54.1297065042684; Sun, 06 Feb 2011 23:50:42 -0800 (PST) Received: by 10.231.39.70 with HTTP; Sun, 6 Feb 2011 23:50:42 -0800 (PST) In-Reply-To: <20110207045501.GA15568@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> Date: Mon, 7 Feb 2011 02:50:42 -0500 Message-ID: From: Zaphod Beeblebrox To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Greg Bonett , freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 08:18:44 -0000 On Sun, Feb 6, 2011 at 11:55 PM, Jeremy Chadwick wrote: > Given that you're running 8.1-RELEASE, what sort of ZFS tunings are you > using in /boot/loader.conf? =A0Tuning is required on this version I haven't seen any new tuning recommendations. Has the tuning required on an 8G amd64 platform changed from 8.0 to 8.1? From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 08:55: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 C465F106564A for ; Mon, 7 Feb 2011 08:55:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 700708FC1D for ; Mon, 7 Feb 2011 08:55:39 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4wui1g0011ei1Bg55wvgPK; Mon, 07 Feb 2011 08:55:40 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta24.westchester.pa.mail.comcast.net with comcast id 4wvf1g0042tehsa3kwvfGQ; Mon, 07 Feb 2011 08:55:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B25549B422; Mon, 7 Feb 2011 00:55:37 -0800 (PST) Date: Mon, 7 Feb 2011 00:55:37 -0800 From: Jeremy Chadwick To: Greg Bonett Message-ID: <20110207085537.GA20545@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1297065041.754.12.camel@ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 08:55:40 -0000 On Sun, Feb 06, 2011 at 11:50:41PM -0800, Greg Bonett wrote: > Thanks for the response. > I have no tunings in /boot/loader.conf > according to http://wiki.freebsd.org/ZFSTuningGuide for amd64 > "FreeBSD 7.2+ has improved kernel memory allocation strategy and no > tuning may be necessary on systems with more than 2 GB of RAM. " > I have 8GB of ram. > do you think this is wrong? > > Handbook recommends these (but says their test system has 1gb ram): > vm.kmem_size="330M" > vm.kmem_size_max="330M" > vfs.zfs.arc_max="40M" > vfs.zfs.vdev.cache.size="5M" > > what do you recommend? The Wiki is outdated, I'm sorry to say. Given that you have 8GB RAM, I would recommend these settings. Please note that some of these have become the defaults in 8.1 (depending on when your kernel was built and off of what source date), and in what will soon be 8.2: /boot/loader.conf : # # ZFS tuning parameters # NOTE: Be sure to see /etc/sysctl.conf for additional tunings # # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. vm.kmem_size="8192M" vfs.zfs.arc_max="6144M" # Disable ZFS prefetching # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html # Increases overall speed of ZFS, but when disk flushing/writes occur, # system is less responsive (due to extreme disk I/O). # NOTE: Systems with 8GB of RAM or more have prefetch enabled by default. vfs.zfs.prefetch_disable="1" # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA # on 2010/05/24. # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html vfs.zfs.zio.use_uma="0" # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This # should increase throughput and decrease the "bursty" stalls that # happen during immense I/O with ZFS. # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html vfs.zfs.txg.timeout="5" /etc/sysctl.conf : # # ZFS tuning parameters # NOTE: Be sure to see /boot/loader.conf for additional tunings # # Increase number of vnodes; we've seen vfs.numvnodes reach 115,000 # at times. Default max is a little over 200,000. Playing it safe... kern.maxvnodes=250000 # Set TXG write limit to a lower threshold. This helps "level out" # the throughput rate (see "zpool iostat"). A value of 256MB works well # for systems with 4GB of RAM, while 1GB works well for us w/ 8GB on # disks which have 64MB cache. vfs.zfs.txg.write_limit_override=1073741824 Be aware that the vfs.zfs.txg.write_limit_override tuning you see above may need to be adjusted for your system. It's up to you to figure out what works best in your environment. > I think the ad0: FAILURE - READ_DMA4 errors may be from a bad sata cable > (or rather, a 12in sata cable connecting a drive that is one inch away) > I'm ordering a new drive bay to improve this, but should a bad cable > cause lockups? Semantic point: it's READ_DMA48, not READ_DMA4. The "48" indicates 48-bit LBA addressing. There is no 4-bit LBA addressing mode. The term "lock up" is also too vague. If by "lock up" you mean "the system seems alive, hitting NumLock on the console keyboard toggles the LED", then the kernel is very likely spending too much of its time spinning in something (such as waiting for commands to return from the SATA controller, which could also indirectly be the controller waiting for the disk to respond to commands). If by "lock up" you mean "the system is literally hard locked, nothing responds, I have to hit physical Reset or power-cycle the box", then no, a bad cable should not be able to cause that. > #smartctl -a /dev/ad0 > > === START OF INFORMATION SECTION === > Model Family: Western Digital Caviar Green (Adv. Format) family > Device Model: WDC WD10EARS-00Y5B1 First thing to note is that this is one of those new 4KB sector drives. I have no personal experience with them, but they have been talked about on the FreeBSD lists for quite some time, especially with regards to ZFS. The discussions involve performance. Just a FYI point. > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 > 3 Spin_Up_Time 0x0027 121 121 021 Pre-fail Always - 6933 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 30 > 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 > 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 > 9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 2664 > 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 > 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 28 > 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 27 > 193 Load_Cycle_Count 0x0032 135 135 000 Old_age Always - 196151 > 194 Temperature_Celsius 0x0022 125 114 000 Old_age Always - 22 > 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 > 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 > 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 > 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 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% 1536 Your disk looks "almost" fine. There are no indicators of bad blocks or CRC errors (which indicate bad SATA cables or physical PCB problems on the disk) -- that's the good part. The bad part: Attribute 193. Your disk is literally "load cycling" (which is somewhat equivalent to a power cycle; I'd rather not get into explaining what it is, but it's not good) on a regular basis. This problem with certain models of Western Digital disks has been discussed on the FreeBSD lists before. There have been statements made by users that Western Digital has indirectly acknowledged this problem, and fixed it in a later drive firmware revision. Please note that in some cases WD did not increment/change the firmware revision string in their fix, so you can't rely on that to determine anything. Would this behaviour cause READ_DMAxx and WRITE_DMAxx errors? Absolutely, no doubt about it. My recommendations: talk to Western Digital Technical Support and explain the problem, point them to this thread, and get a fixed/upgraded firmware from them. If they do not acknowledge the problem or you get stonewalled, I recommend replacing the drive entirely with a different model (I highly recommend the Caviar Black drives, which do not have this problem). If they give you a replacement firmware, you'll probably need a DOS boot disk to accomplish this, and need to make sure your BIOS does not have AHCI mode enabled (DOS won't find the disk). You can always re-enable AHCI after the upgrade. If you don't have a DOS boot disk, you'll need to explain to Western Digital that you need them to give you a bootable ISO that can allow you to perform the upgrade. If you need me to dig up mailing lists posts about this problem I can do so, but it will take me some time. The discussions might have been for a non-4K-sector Green drive as well, but it doesn't matter, the problem is known at this point. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 09:01: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 F091F106564A for ; Mon, 7 Feb 2011 09:01:20 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id CE34E8FC14 for ; Mon, 7 Feb 2011 09:01:20 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p1791KYT017519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 7 Feb 2011 01:01:20 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p1791JKQ017518 for freebsd-stable@freebsd.org; Mon, 7 Feb 2011 01:01:19 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA05699; Mon, 7 Feb 11 00:54:42 PST Date: Mon, 07 Feb 2011 00:53:14 -0800 From: perryh@pluto.rain.com To: freebsd-stable@freebsd.org Message-Id: <4d4fb2fa.1SlxGA2eA/1ZnThg%perryh@pluto.rain.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_4d4fb2fa.2fyW/KoxitQVnB0sLEBgqhJojRSolpeB2cP7k/ChHeHL/5/p" Subject: minor data-typing error in 8.1 fs/devfs/devfs_vnops.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: Mon, 07 Feb 2011 09:01:21 -0000 This is a multi-part message in MIME format. --=_4d4fb2fa.2fyW/KoxitQVnB0sLEBgqhJojRSolpeB2cP7k/ChHeHL/5/p Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Noticed while digging through devfs_read_f() and devfs_write_f() in the course of investigating some unexpected (by me) geom behavior: ... int ioflag, error, resid; ... resid = uio->uio_resid; ... if (uio->uio_resid != resid || ... IOW resid (an int) is being assigned from and compared with uio->uio_resid (an ssize_t). I suppose it's probably harmless on any arch where an (int) is at least as large as an (ssize_t), but strictly speaking it does look like a bug -- or am I missing something? --=_4d4fb2fa.2fyW/KoxitQVnB0sLEBgqhJojRSolpeB2cP7k/ChHeHL/5/p Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devfs_vnops.c-resid-patch" --- fs/devfs/devfs_vnops.c-81R Sun Jun 13 19:09:06 2010 +++ - Sun Feb 6 23:58:34 2011 @@ -1046,7 +1046,8 @@ devfs_read_f(struct file *fp, struct uio *uio, struct ucred *cred, int flags, struct thread *td) { struct cdev *dev; - int ioflag, error, resid; + int ioflag, error; + ssize_t resid; struct cdevsw *dsw; struct file *fpop; @@ -1489,7 +1490,8 @@ devfs_write_f(struct file *fp, struct uio *uio, struct ucred *cred, int flags, struct thread *td) { struct cdev *dev; - int error, ioflag, resid; + int error, ioflag; + ssize_t resid; struct cdevsw *dsw; struct file *fpop; --=_4d4fb2fa.2fyW/KoxitQVnB0sLEBgqhJojRSolpeB2cP7k/ChHeHL/5/p-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 09:03: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 E632D106564A for ; Mon, 7 Feb 2011 09:03:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id C59CF8FC08 for ; Mon, 7 Feb 2011 09:03:49 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 4x351g0030mlR8UA2x3pZF; Mon, 07 Feb 2011 09:03:49 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta11.emeryville.ca.mail.comcast.net with comcast id 4x3n1g00C2tehsa8Xx3ow4; Mon, 07 Feb 2011 09:03:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BA49D9B422; Mon, 7 Feb 2011 01:03:47 -0800 (PST) Date: Mon, 7 Feb 2011 01:03:47 -0800 From: Jeremy Chadwick To: Zaphod Beeblebrox Message-ID: <20110207090347.GB20545@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@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: Greg Bonett , freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 09:03:50 -0000 On Mon, Feb 07, 2011 at 02:50:42AM -0500, Zaphod Beeblebrox wrote: > On Sun, Feb 6, 2011 at 11:55 PM, Jeremy Chadwick > wrote: > > > Given that you're running 8.1-RELEASE, what sort of ZFS tunings are you > > using in /boot/loader.conf?  Tuning is required on this version > > I haven't seen any new tuning recommendations. Has the tuning > required on an 8G amd64 platform changed from 8.0 to 8.1? They're discussed practically on a monthly basis on the mailing lists (either freebsd-fs or freebsd-stable). Keeping track of them is almost impossible at this point, which is also probably why the Wiki is outdated. See my other follow-up post to the OP regarding what most of the tunings should be. On an 8.0 system, there may be some tunings I listed off that won't work (loader(8) will complain "no such tunable" and won't boot). I think the UMA tunable is one of those. Please don't ask me "how was I supposed to know about any of this?" -- basically folks are ""expected"" to follow every single CVS or SVN commit to the FreeBSD tag you track/use, and are expected to read the diffs when there's a commit and "figure it out themselves". The release notes between 8.x and 8.x+1 don't disclose tunable changes either. If you don't like this model/approach, there are appropriate channels to send your complaints through -- but I myself simply gave up. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 10:22:52 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 CEFC0106564A for ; Mon, 7 Feb 2011 10:22:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED888FC18 for ; Mon, 7 Feb 2011 10:22:51 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p17AMm7w098865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 12:22:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p17AMm2S078570; Mon, 7 Feb 2011 12:22:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p17AMmZR078569; Mon, 7 Feb 2011 12:22:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Feb 2011 12:22:48 +0200 From: Kostik Belousov To: perryh@pluto.rain.com Message-ID: <20110207102248.GP78089@deviant.kiev.zoral.com.ua> References: <4d4fb2fa.1SlxGA2eA/1ZnThg%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U/fW6JBK3GqE0Htg" Content-Disposition: inline In-Reply-To: <4d4fb2fa.1SlxGA2eA/1ZnThg%perryh@pluto.rain.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: minor data-typing error in 8.1 fs/devfs/devfs_vnops.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: Mon, 07 Feb 2011 10:22:52 -0000 --U/fW6JBK3GqE0Htg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 07, 2011 at 12:53:14AM -0800, perryh@pluto.rain.com wrote: > Noticed while digging through devfs_read_f() and devfs_write_f() in > the course of investigating some unexpected (by me) geom behavior: >=20 > ... > int ioflag, error, resid; > ... > resid =3D uio->uio_resid; > ... > if (uio->uio_resid !=3D resid || ... >=20 > IOW resid (an int) is being assigned from and compared with > uio->uio_resid (an ssize_t). >=20 > I suppose it's probably harmless on any arch where an (int) is at > least as large as an (ssize_t), but strictly speaking it does look > like a bug -- or am I missing something? The only consequence of resid truncating uio_resid would be failure to update access time for the devfs node, which is probably not a big issue. In fact, HEAD cannot generate request for i/o greater than 4GB anyway. The type of uio_resid was increased from int to ssize_t to not break the KBI and ease indended fix to support full size_t arguments for read(2)/write(2). The change requires lots of careful review, and thus stalled. I integrated your fix into the patch, see http://people.freebsd.org/~kib/misc/uio_resid.4.patch --U/fW6JBK3GqE0Htg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1Px/cACgkQC3+MBN1Mb4g6JQCguJskZ0wfAKVf8TbTC/lUdXVj VKoAoJDyEpSmivQsboqDo9tugfwb5Q6n =v83U -----END PGP SIGNATURE----- --U/fW6JBK3GqE0Htg-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 12:22:19 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 D408D106564A; Mon, 7 Feb 2011 12:22:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB318FC08; Mon, 7 Feb 2011 12:22:19 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p17CMD46070327 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 07:22:14 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D4FE3F3.6030604@sentex.net> Date: Mon, 07 Feb 2011 07:22:11 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: lev@freebsd.org References: <787079038.20110207004023@serebryakov.spb.ru> In-Reply-To: <787079038.20110207004023@serebryakov.spb.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, "Vogel, Jack" Subject: Re: em0 hangs without any messages like "Watchdog timeout", only down/up reset it. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 12:22:19 -0000 On 2/6/2011 4:40 PM, Lev Serebryakov wrote: > Hello, Freebsd-stable. > It hangs under load without any output. When it works with POLLING, it > prints "Watchdog timeout" and reset automatically several times a day, > but without POLLING it simply hangs with same frequency. It is > 8.2-PRERELEASE (from RELENG_8), cvsupped AFTER 22 Jan (last commit to > e1000 drivers family). > > Locally system works, but mbufs are overfilled. "ifconfig em0 down > && ifconfig em0 up" solves problem. In non polling mode, do you have any special network or driver settings in /boot/loader.conf or /etc/sysctl.conf ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 12:52: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 2B3FA1065694; Mon, 7 Feb 2011 12:52:06 +0000 (UTC) (envelope-from lev@freebsd.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id DB3148FC13; Mon, 7 Feb 2011 12:52:05 +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 49F5513DF5F; Mon, 7 Feb 2011 15:52:04 +0300 (MSK) Date: Mon, 7 Feb 2011 15:52:03 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <504473738.20110207155203@serebryakov.spb.ru> To: Mike Tancsa In-Reply-To: <4D4FE3F3.6030604@sentex.net> References: <787079038.20110207004023@serebryakov.spb.ru> <4D4FE3F3.6030604@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, "Vogel, Jack" Subject: Re: em0 hangs without any messages like "Watchdog timeout", only down/up reset it. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 12:52:06 -0000 Hello, Mike. You wrote 7 =F4=E5=E2=F0=E0=EB=FF 2011 =E3., 15:22:11: >> It hangs under load without any output. When it works with POLLING, it >> prints "Watchdog timeout" and reset automatically several times a day, >> but without POLLING it simply hangs with same frequency. It is >> 8.2-PRERELEASE (from RELENG_8), cvsupped AFTER 22 Jan (last commit to >> e1000 drivers family). >>=20 >> Locally system works, but mbufs are overfilled. "ifconfig em0 down >> && ifconfig em0 up" solves problem. > In non polling mode, do you have any special network or driver settings > in /boot/loader.conf or /etc/sysctl.conf ? /boot/loader.conf: hw.em.rxd=3D4096 hw.em.txd=3D4096 net.link.ifqmaxlen=3D16384 /etc/sysctl.conf: dev.em.0.rx_int_delay=3D200 dev.em.0.tx_int_delay=3D200 dev.em.0.rx_abs_int_delay=3D4000 dev.em.0.tx_abs_int_delay=3D4000 dev.em.0.rx_processing_limit=3D4096 I'm trying to run with patch from "em driver, 82574L chip, and possibly ASPM" thread now under heavy network load. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 13:03: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 F1C77106566C; Mon, 7 Feb 2011 13:03:04 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id A9A9A8FC14; Mon, 7 Feb 2011 13:03:04 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p17D32Wh075560 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 08:03:02 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D4FED83.2010400@sentex.net> Date: Mon, 07 Feb 2011 08:02:59 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lev Serebryakov References: <787079038.20110207004023@serebryakov.spb.ru> <4D4FE3F3.6030604@sentex.net> <504473738.20110207155203@serebryakov.spb.ru> In-Reply-To: <504473738.20110207155203@serebryakov.spb.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, "Vogel, Jack" Subject: Re: em0 hangs without any messages like "Watchdog timeout", only down/up reset it. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 13:03:05 -0000 > > /boot/loader.conf: > hw.em.rxd=4096 > hw.em.txd=4096 > net.link.ifqmaxlen=16384 > > /etc/sysctl.conf: > dev.em.0.rx_int_delay=200 > dev.em.0.tx_int_delay=200 > dev.em.0.rx_abs_int_delay=4000 > dev.em.0.tx_abs_int_delay=4000 > dev.em.0.rx_processing_limit=4096 > > > I'm trying to run with patch from "em driver, 82574L chip, and > possibly ASPM" thread now under heavy network load. > Hi Lev, What if you try with just the defaults ? Not sure the patch posted by jack and sean will help as its meant for a specific type of em nic, but the RELENG_8 version I am testing with is here http://www.tancsa.com/if_em-8.c. There is a patch to jack's patch by Sean as well thats incorporated in that version ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 14:07:09 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 232421065673 for ; Mon, 7 Feb 2011 14:07:09 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A07D48FC1E for ; Mon, 7 Feb 2011 14:07:08 +0000 (UTC) Received: by eyf6 with SMTP id 6so2207704eyf.13 for ; Mon, 07 Feb 2011 06:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Gr/xYSgbW5jls1s50a5kLAtrAEN2TY0rnCdFU32OorI=; b=fm6oQ7z4s69GZLqToD9G0BqhqLI87UAMPliG6RIwb/Ho/vOxtZwfqhKx5TInSyvUDd 5pIscrNs79NayEDx+SA7Mr2J3sWC7uLkeis2f1odWASeRgCgSF91pSEiYRuQZY8/FpSK PRIPjVxEcx0zrr6owzrDBparnm8UP7qx0Cyok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=AVmSTS8w8DAj3wbrvtsQ0UR+nvxvFIUkshpJR7EKgNuQc+agzYT5PYEz3U/2EwFoXt GqwQNrShad4mBzzKXBkOl/4QVZCHCrCKE811uoYdqP7GGvydDnG4VmNz9JZZ/h4pmZ4e Iwbxes8zfO0ZbZvm17VM+bqiezFCHT5YNbgL4= Received: by 10.103.233.16 with SMTP id k16mr10857347mur.132.1297085887121; Mon, 07 Feb 2011 05:38:07 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id a6sm819372fak.3.2011.02.07.05.38.05 (version=SSLv3 cipher=OTHER); Mon, 07 Feb 2011 05:38:06 -0800 (PST) Date: Mon, 7 Feb 2011 15:37:48 +0200 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20110207133748.GA16327@tops.skynet.lt> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110119150200.GY2518@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 14:07:09 -0000 On (19/01/2011 17:27), Ivan Voras wrote: > On 19 January 2011 16:02, Kostik Belousov wrote: > > >> http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch > >> > >> I don't think this is a complete solution but it's a start. If you can, > >> try it and see if it helps. > > This is not a start, and actually a step in the wrong direction. > > Tmpfs is wrong now, but the patch would make the wrongness even bigger. > > > > Issue is that the current tmpfs calculation should not depend on the > > length of the inactive queue or the amount of free pages. This data only > > measures  the pressure on the pagedaemon, and has absolutely no relation > > to the amount of data that can be put into anonymous objects before the > > system comes out of swap. > > > > vm_lowmem handler is invoked in two situations: > > - when KVA cannot satisfy the request for the space allocation; > > - when pagedaemon have to start the scan. > > None of the situations has any direct correlation with the fact that > > tmpfs needs to check, that is "Is there enough swap to keep all my > > future anonymous memory requests ?". > > > > Might be, swap reservation numbers can be useful to the tmpfs reporting. > > Also might be, tmpfs should reserve the swap explicitely on start, instead > > of making attempts to guess how much can be allocated at random moment. > > Thank you for your explanation! I'm still not very familiar with VM > and VFS. Could you also read my report at > http://www.mail-archive.com/freebsd-current@freebsd.org/msg126491.html > ? I'm curious about the fact that there is lots of 'free' memory here > in the same situation. > > Do you think that there is something which can be done as a band-aid > without a major modification to tmpfs? It's up to user to mount tmpfs filesystems of reasonable size to prevent resource exhaustion. Anyway, enormously large tmpfs killing all your process is not the way to go. Unless there are objections, I'm planning to do the following: 1. By default set tmpfs size to max(all swap/2, all memory/2) and print warning that filesystem size should be specified manually. Max(swap/2,mem/2) is used as a band-aid for the case when no swap is setup. 3. Remove "live" filesystem size checks, i.e. do not depend on free/inact memory. 2. Add support for resizing tmpfs on the fly: mount -u -o size= /tmpfs Reserving swap for tmpfs might not be what user expects: generally I use tmpfs for work dir for building ports, it's unused most of the time. btw, what linux and opensolaris do when available mem/swap gets low due to tmpfs and how filesystem size determined at real-time? Thanks, Gleb. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 14:36: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 B2A18106566C; Mon, 7 Feb 2011 14:36:18 +0000 (UTC) (envelope-from ivoras@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 533A38FC16; Mon, 7 Feb 2011 14:36:17 +0000 (UTC) Received: by gxk8 with SMTP id 8so1800504gxk.13 for ; Mon, 07 Feb 2011 06:36:17 -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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rmxLzAOtmwo26WcUYyMy8B5BD+SN/mbYkxoyjrU940I=; b=JGu4HVCUzuwIVcY0CCF8W/AsvxgT4qts2jmEb3c7Ymm96GclxvgUqqrBf0E3WU1SRB B03GTJOwI993I51OYfAQIXuHgpGvRm8ULZRwL+qUHfhrUl0FcBRrZbWAXbluy0h6xuMl /WoydmmVfvS/YDRljSXmQbead1tUVi9Aswg2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=lTMispOnfVAD71Xe4+QozDpg8z0SFrAIyOa4XuJ62GEXZEifRd3scSqNz1/VJo8DzK Dx7HWReGwHTAERgYVD/ujzj8rdf8E2w1uYoqxRMNNFBo8ROgDHTfZsdjpEminNUWn7CP qh54zrHdHqDRzjNsoGxfXzlWTzYqlEvy8XJdw= Received: by 10.90.89.11 with SMTP id m11mr19712995agb.18.1297089377455; Mon, 07 Feb 2011 06:36:17 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.151.11.12 with HTTP; Mon, 7 Feb 2011 06:35:37 -0800 (PST) In-Reply-To: <20110207133748.GA16327@tops.skynet.lt> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110119150200.GY2518@deviant.kiev.zoral.com.ua> <20110207133748.GA16327@tops.skynet.lt> From: Ivan Voras Date: Mon, 7 Feb 2011 15:35:37 +0100 X-Google-Sender-Auth: YneYLcrX7-KEG3tpy4EENC0bbgQ Message-ID: To: Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 14:36:18 -0000 On 7 February 2011 14:37, Gleb Kurtsou wrote: > It's up to user to mount tmpfs filesystems of reasonable size to prevent > resource exhaustion. Anyway, enormously large tmpfs killing all your > process is not the way to go. Of course not, but as I see it (from admin perspective), tmpfs should behave as close to regular processes in consuming memory as possible (where possible; obviously it cannot be subject to the OOM killer :) ). The problem described in this thread is that there is enough memory in various lists and tmpfs still reports "0 bytes free". See my message: the machine had more than 8 GB of "free" memory (reported by "top") and still "0 bytes free" in tmpfs - and that's not counting inactive and other forms of used memory which could be freed or swapped out (and also not counting swap). By "as close to regular processes in consuming memory" I mean that I would expect tmpfs to allocate from the same total pool of memory as processes and be subject to the same mechanisms of VM, including swap. If that is not possible, I would (again, as an admin) like to extend the tmpfs(5) man page and other documentation with information about what types of memory will and will not count towards available to tmpfs. > Unless there are objections, I'm planning to do the following: > > 1. By default set tmpfs size to max(all swap/2, all memory/2) and print > warning that filesystem size should be specified manually. > Max(swap/2,mem/2) is used as a band-aid for the case when no swap is setu= p. You mean as a reservation, maximum limit or something else? If a tmpfs with "size" of e.g. 16 GB is configured, will the memory be preallocated? wired? I don't think there should be default hard size limits to tmpfs - it should be able to hold sudden bursts of large temp files (using swap if needed), but that could be achieved by configuring a tmpfs whose size is RAM+swap if the memory is not preallocated so not a big problem. > 3. Remove "live" filesystem size checks, i.e. do not depend on > free/inact memory. I'm for it, if it's possible in the light of #1 > 2. Add support for resizing tmpfs on the fly: > =C2=A0 =C2=A0 =C2=A0 =C2=A0mount -u -o size=3D /tmpfs ditto. > Reserving swap for tmpfs might not be what user expects: generally I use > tmpfs for work dir for building ports, it's unused most of the time. It looks like we think the opposite of it :) I would like it to be swapped out if needed, making room for running processes etc. as regular VM paging algorithms decide. Of course, if that could be controlled with a flag we'd both be happy :) > btw, what linux and opensolaris do when available mem/swap gets low due > to tmpfs and how filesystem size determined at real-time? There's some information here: http://en.wikipedia.org/wiki/Tmpfs From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 15:44: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 A3D541065670; Mon, 7 Feb 2011 15:44:27 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C94C68FC0A; Mon, 7 Feb 2011 15:44:26 +0000 (UTC) Received: by bwz12 with SMTP id 12so4961089bwz.13 for ; Mon, 07 Feb 2011 07:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=IfXnB0x7Z/1fRIbu2fAzfG6yeefBDobpgX5DbG4BEmQ=; b=NFukoqj1s0L83nEhFc+FmSoJHA6SRx7Wfotbd60avEybV1rVQ5MAyhtcPwUNvkWBRC rWFVXl6+I+SxziAyFmJvu1jHN495KVSYg77x03dldVHcSSkWY8auZVRaLkW3M96ram5V aQE4yhjxe56xXAhvv/7tIRBqTq4GXmtUmNQaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=qtRojSjuZgMXMebDFLd2zT/q+rDyDMw3+o3K6lIFY0rCkPPabTOAvqgemC90DOkCAq loAdbWyRMqxf569KgoVttAaB8FsMi5s2/XYQWTXkIUmuXrV4NnmidF2+1IwK6XqQmWQV WcQ4UmVjePH3oIs25AUnAs9CThKyLUbqr6H2Y= Received: by 10.204.16.138 with SMTP id o10mr24739bka.157.1297093465620; Mon, 07 Feb 2011 07:44:25 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id u23sm2114791bkw.21.2011.02.07.07.44.24 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 07:44:24 -0800 (PST) Date: Mon, 7 Feb 2011 17:44:06 +0200 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20110207154406.GA28877@tops.skynet.lt> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110119150200.GY2518@deviant.kiev.zoral.com.ua> <20110207133748.GA16327@tops.skynet.lt> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2011 15:44:27 -0000 On (07/02/2011 15:35), Ivan Voras wrote: > On 7 February 2011 14:37, Gleb Kurtsou wrote: > > > It's up to user to mount tmpfs filesystems of reasonable size to prevent > > resource exhaustion. Anyway, enormously large tmpfs killing all your > > process is not the way to go. > > Of course not, but as I see it (from admin perspective), tmpfs should > behave as close to regular processes in consuming memory as possible > (where possible; obviously it cannot be subject to the OOM killer :) > ). Here is key difference it's not subject to be killed by OOM killer. Thus exhausting all resource for real. I propose to enforce specifying upper limit of filesystem size by user. > The problem described in this thread is that there is enough memory in > various lists and tmpfs still reports "0 bytes free". See my message: > the machine had more than 8 GB of "free" memory (reported by "top") > and still "0 bytes free" in tmpfs - and that's not counting inactive > and other forms of used memory which could be freed or swapped out > (and also not counting swap). That's because tmpfs incorrectly checks how much memory is available including both swap and ram. In VM world that's not so easy. > By "as close to regular processes in consuming memory" I mean that I > would expect tmpfs to allocate from the same total pool of memory as > processes and be subject to the same mechanisms of VM, including swap. > If that is not possible, I would (again, as an admin) like to extend > the tmpfs(5) man page and other documentation with information about > what types of memory will and will not count towards available to > tmpfs. > > > Unless there are objections, I'm planning to do the following: > > > > 1. By default set tmpfs size to max(all swap/2, all memory/2) and print > > warning that filesystem size should be specified manually. > > Max(swap/2,mem/2) is used as a band-aid for the case when no swap is setup. > > You mean as a reservation, maximum limit or something else? If a tmpfs > with "size" of e.g. 16 GB is configured, will the memory be > preallocated? wired? Memory in tmpfs is allocated/freed as needed, there is no preallocated or reserved memory/swap. It already behaves the way you've described. I'm against preallocating or reserving memory. There is ramfs in linux that does preallocation, but it looks deprecated. > I don't think there should be default hard size limits to tmpfs - it > should be able to hold sudden bursts of large temp files (using swap > if needed), but that could be achieved by configuring a tmpfs whose > size is RAM+swap if the memory is not preallocated so not a big > problem. But there is one in Linux (Documentation/filesystems/tmpfs.txt): 59 size: The limit of allocated bytes for this tmpfs instance. The 60 default is half of your physical RAM without swap. If you 61 oversize your tmpfs instances the machine will deadlock 62 since the OOM handler will not be able to free that memory. That's actually what I've proposed: size=mem/2 vs size=max(mem/2,swap/2) Limit should be there not to panic the system. > > 3. Remove "live" filesystem size checks, i.e. do not depend on > > free/inact memory. > > I'm for it, if it's possible in the light of #1 > > > 2. Add support for resizing tmpfs on the fly: > >        mount -u -o size= /tmpfs > > ditto. It's trivial. If it can be resized, change maxsize in struct, fail otherwise. > > Reserving swap for tmpfs might not be what user expects: generally I use > > tmpfs for work dir for building ports, it's unused most of the time. > > It looks like we think the opposite of it :) I would like it to be > swapped out if needed, making room for running processes etc. as > regular VM paging algorithms decide. Of course, if that could be > controlled with a flag we'd both be happy :) Perhaps there is a bit of misunderstanding, it will be swapped out, will behave exactly as it does now, but will have sane default filesystem size limit by default, will change semantics of calculating available memory: I want it to try hard to allocate memory unless filesystem limit is hit, failing only if there is clearly memory shortage (as I said, it is for user to properly configure it). > > btw, what linux and opensolaris do when available mem/swap gets low due > > to tmpfs and how filesystem size determined at real-time? > > There's some information here: http://en.wikipedia.org/wiki/Tmpfs From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 22:03: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 33C17106566C for ; Mon, 7 Feb 2011 22:03:39 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from local.wintek.com (local.wintek.com [206.230.2.234]) by mx1.freebsd.org (Postfix) with ESMTP id F0C0E8FC14 for ; Mon, 7 Feb 2011 22:03:38 +0000 (UTC) Received: from rjk.wintek.local (172.28.1.248) by local.wintek.com (172.28.1.234) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 7 Feb 2011 16:53:13 -0500 Message-ID: <4D5069C9.20900@wintek.com> Date: Mon, 7 Feb 2011 16:53:13 -0500 From: Richard Kuhns Organization: Wintek Corporation User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101210 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Problem building gdb with up-to-date sources X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rjk@wintek.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:03:39 -0000 Hello, I just tried to run a buildworld for RELENG_8/amd64 after a fresh csup, and I'm getting the following error: /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c: In function 'fbsd_thread_get_name': /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c:442: error: 'struct ptrace_lwpinfo' has no member named 'pl_tdname' I looked in /usr/src/sys/sys/ptrace.h, and 'pl_tdname' isn't there. Running 'cvs log' on ptrace.h, though, shows: revision 1.34 date: 2010/11/22 14:42:13; author: attilio; state: Exp; lines: +2 -0 SVN rev 215679 on 2010-11-22 14:42:13Z by attilio Add the ability for GDB to printout the thread name along with other thread specific informations. In order to do that, and in order to avoid KBI breakage with existing infrastructure the following semantic is implemented: - For live programs, a new member to the PT_LWPINFO is added (pl_tdname) ... Any suggestions? I didn't see anything in /usr/src/UPDATING. Thanks in advance! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 05:34: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 13C0F106564A for ; Tue, 8 Feb 2011 05:34:41 +0000 (UTC) (envelope-from greg@bonett.org) Received: from bonett.org (bonett.org [66.249.7.150]) by mx1.freebsd.org (Postfix) with ESMTP id C40BA8FC12 for ; Tue, 8 Feb 2011 05:34:40 +0000 (UTC) Received: from [192.168.1.216] (unknown [76.91.19.169]) by bonett.org (Postfix) with ESMTPSA id A45DC124367; Tue, 8 Feb 2011 05:34:38 +0000 (UTC) From: Greg Bonett To: Jeremy Chadwick In-Reply-To: <20110207085537.GA20545@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Feb 2011 21:34:36 -0800 Message-ID: <1297143276.9417.400.camel@ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:34:41 -0000 Thank you for the help. I've implemented your suggested /boot/loader.conf and /etc/sysctrl.conf tunings. Unfortunately, after implementing these settings, I experienced another lockup. And by "lockup" I mean, nothing responding (sshd, keyboard, num lock) - had to reset. I'm trying to isolate the cause of these lockups. I rebooted the system and tried to simulate high load condition WITHOUT mounting my zfs pool. First I ran many instances of "dd if=/dev/random of=/dev/null bs=4m" to get high CPU load. The machine ran for many hours under this condition without lockup. Then I added a few "dd if=/dev/adX of=/dev/null bs=4m" to simulate some io load. After doing this it locked up immediately. Thinking I had figured out the source of the problem, I rebooted and tried to replicate this experience but was not able to. So far it has been running for two hours with six "dd if=/dev/adX" commands (one for each disk) and about a dozen "dd if=/dev/urandom" commands (to keep cpu near 100%). I'll let it keep running and see if it locks again without ever mounting zfs. any ideas? On Mon, 2011-02-07 at 00:55 -0800, Jeremy Chadwick wrote: > On Sun, Feb 06, 2011 at 11:50:41PM -0800, Greg Bonett wrote: > > Thanks for the response. > > I have no tunings in /boot/loader.conf > > according to http://wiki.freebsd.org/ZFSTuningGuide for amd64 > > "FreeBSD 7.2+ has improved kernel memory allocation strategy and no > > tuning may be necessary on systems with more than 2 GB of RAM. " > > I have 8GB of ram. > > do you think this is wrong? > > > > Handbook recommends these (but says their test system has 1gb ram): > > vm.kmem_size="330M" > > vm.kmem_size_max="330M" > > vfs.zfs.arc_max="40M" > > vfs.zfs.vdev.cache.size="5M" > > > > what do you recommend? > > The Wiki is outdated, I'm sorry to say. Given that you have 8GB RAM, I > would recommend these settings. Please note that some of these have > become the defaults in 8.1 (depending on when your kernel was built and > off of what source date), and in what will soon be 8.2: > > /boot/loader.conf : > > # > # ZFS tuning parameters > # NOTE: Be sure to see /etc/sysctl.conf for additional tunings > # > > # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. > vm.kmem_size="8192M" > vfs.zfs.arc_max="6144M" > > # Disable ZFS prefetching > # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html > # Increases overall speed of ZFS, but when disk flushing/writes occur, > # system is less responsive (due to extreme disk I/O). > # NOTE: Systems with 8GB of RAM or more have prefetch enabled by default. > vfs.zfs.prefetch_disable="1" > > # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA > # on 2010/05/24. > # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html > vfs.zfs.zio.use_uma="0" > > # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This > # should increase throughput and decrease the "bursty" stalls that > # happen during immense I/O with ZFS. > # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html > # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html > vfs.zfs.txg.timeout="5" > > > > /etc/sysctl.conf : > > # > # ZFS tuning parameters > # NOTE: Be sure to see /boot/loader.conf for additional tunings > # > > # Increase number of vnodes; we've seen vfs.numvnodes reach 115,000 > # at times. Default max is a little over 200,000. Playing it safe... > kern.maxvnodes=250000 > > # Set TXG write limit to a lower threshold. This helps "level out" > # the throughput rate (see "zpool iostat"). A value of 256MB works well > # for systems with 4GB of RAM, while 1GB works well for us w/ 8GB on > # disks which have 64MB cache. > vfs.zfs.txg.write_limit_override=1073741824 > > > Be aware that the vfs.zfs.txg.write_limit_override tuning you see above > may need to be adjusted for your system. It's up to you to figure out > what works best in your environment. > > > I think the ad0: FAILURE - READ_DMA4 errors may be from a bad sata cable > > (or rather, a 12in sata cable connecting a drive that is one inch away) > > I'm ordering a new drive bay to improve this, but should a bad cable > > cause lockups? > > Semantic point: it's READ_DMA48, not READ_DMA4. The "48" indicates > 48-bit LBA addressing. There is no 4-bit LBA addressing mode. > > The term "lock up" is also too vague. If by "lock up" you mean "the > system seems alive, hitting NumLock on the console keyboard toggles the > LED", then the kernel is very likely spending too much of its time > spinning in something (such as waiting for commands to return from the > SATA controller, which could also indirectly be the controller waiting > for the disk to respond to commands). If by "lock up" you mean "the > system is literally hard locked, nothing responds, I have to hit > physical Reset or power-cycle the box", then no, a bad cable should not > be able to cause that. > > > > #smartctl -a /dev/ad0 > > > > === START OF INFORMATION SECTION === > > Model Family: Western Digital Caviar Green (Adv. Format) family > > Device Model: WDC WD10EARS-00Y5B1 > > First thing to note is that this is one of those new 4KB sector drives. > I have no personal experience with them, but they have been talked about > on the FreeBSD lists for quite some time, especially with regards to > ZFS. The discussions involve performance. Just a FYI point. > > > SMART Attributes Data Structure revision number: 16 > > Vendor Specific SMART Attributes with Thresholds: > > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > > UPDATED WHEN_FAILED RAW_VALUE > > 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 > > 3 Spin_Up_Time 0x0027 121 121 021 Pre-fail Always - 6933 > > 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 30 > > 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 > > 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 > > 9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 2664 > > 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 > > 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 > > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 28 > > 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 27 > > 193 Load_Cycle_Count 0x0032 135 135 000 Old_age Always - 196151 > > 194 Temperature_Celsius 0x0022 125 114 000 Old_age Always - 22 > > 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 > > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 > > 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 > > 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 > > 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 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% 1536 > > Your disk looks "almost" fine. There are no indicators of bad blocks or > CRC errors (which indicate bad SATA cables or physical PCB problems on > the disk) -- that's the good part. > > The bad part: Attribute 193. Your disk is literally "load cycling" > (which is somewhat equivalent to a power cycle; I'd rather not get into > explaining what it is, but it's not good) on a regular basis. This > problem with certain models of Western Digital disks has been discussed > on the FreeBSD lists before. There have been statements made by users > that Western Digital has indirectly acknowledged this problem, and fixed > it in a later drive firmware revision. Please note that in some cases > WD did not increment/change the firmware revision string in their fix, > so you can't rely on that to determine anything. > > Would this behaviour cause READ_DMAxx and WRITE_DMAxx errors? > Absolutely, no doubt about it. > > My recommendations: talk to Western Digital Technical Support and explain > the problem, point them to this thread, and get a fixed/upgraded > firmware from them. If they do not acknowledge the problem or you get > stonewalled, I recommend replacing the drive entirely with a different > model (I highly recommend the Caviar Black drives, which do not have > this problem). > > If they give you a replacement firmware, you'll probably need a DOS boot > disk to accomplish this, and need to make sure your BIOS does not have > AHCI mode enabled (DOS won't find the disk). You can always re-enable > AHCI after the upgrade. If you don't have a DOS boot disk, you'll need > to explain to Western Digital that you need them to give you a bootable > ISO that can allow you to perform the upgrade. > > If you need me to dig up mailing lists posts about this problem I can do > so, but it will take me some time. The discussions might have been for > a non-4K-sector Green drive as well, but it doesn't matter, the problem > is known at this point. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 05:52: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 B0CC9106564A for ; Tue, 8 Feb 2011 05:52:42 +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 3FBBA8FC0C for ; Tue, 8 Feb 2011 05:52:41 +0000 (UTC) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta09.westchester.pa.mail.comcast.net with comcast id 5Hru1g0030QuhwU59HsiX2; Tue, 08 Feb 2011 05:52:42 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta02.westchester.pa.mail.comcast.net with comcast id 5Hsg1g00p2tehsa3NHshvN; Tue, 08 Feb 2011 05:52:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 419CC9B422; Mon, 7 Feb 2011 21:52:39 -0800 (PST) Date: Mon, 7 Feb 2011 21:52:39 -0800 From: Jeremy Chadwick To: Greg Bonett Message-ID: <20110208055239.GA2557@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <1297143276.9417.400.camel@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1297143276.9417.400.camel@ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:52:42 -0000 On Mon, Feb 07, 2011 at 09:34:36PM -0800, Greg Bonett wrote: > Thank you for the help. I've implemented your > suggested /boot/loader.conf and /etc/sysctrl.conf tunings. > Unfortunately, after implementing these settings, I experienced another > lockup. And by "lockup" I mean, nothing responding (sshd, keyboard, num > lock) - had to reset. > > I'm trying to isolate the cause of these lockups. I rebooted the system > and tried to simulate high load condition WITHOUT mounting my zfs pool. > First I ran many instances of "dd if=/dev/random of=/dev/null bs=4m" to > get high CPU load. The machine ran for many hours under this condition > without lockup. Then I added a few "dd if=/dev/adX of=/dev/null bs=4m" > to simulate some io load. After doing this it locked up immediately. > Thinking I had figured out the source of the problem, I rebooted and > tried to replicate this experience but was not able to. So far it has > been running for two hours with six "dd if=/dev/adX" commands (one for > each disk) and about a dozen "dd if=/dev/urandom" commands (to keep cpu > near 100%). I'll let it keep running and see if it locks again without > ever mounting zfs. > > any ideas? No NumLock LED toggling is a pretty good indicator of a hardware-level problem. An extra test would be to rebuild your kernel with debugging enabled so that when the machine locks, you could try pressing Ctrl-Alt-Esc at the VGA console and see if you drop to a db> prompt. If so, that means the machine is actually alive (well, the kernel anyway). As for causes: you could have bad memory (memtest86+ is a decent free test, but not infallible), you could have a PSU that doesn't have decent voltage ranges on its 3V, 5V, or 12V lines, you could have a PSU that doesn't provide enough power for all the devices connected to it, you could have a bad motherboard, your CPU could be overheating, you could be encountering a strange hardware/silicon bug, there could be a small or thin slice of metal laying across a single trace on the motherboard, etc... The list is enormous. Hardware problems often require a person to spend a lot of time and money, replacing a single part at a time, until the problem goes away. The only thing we know for sure at this point is that your Western Digital drive behaves erratically with regards to excessive load cycling. That is almost certainly the reason for your READ_DMA48 errors. So, you may actually be experiencing two separate issues at the same time. It's hard to tell at this point. In the meantime, can you please provide output from "dmesg" after the machine comes up? I'm curious to know what sort of hardware is in this machine, especially with regards to its storage controller. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 06:16: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 CD18F1065670 for ; Tue, 8 Feb 2011 06:16:49 +0000 (UTC) (envelope-from greg@bonett.org) Received: from bonett.org (bonett.org [66.249.7.150]) by mx1.freebsd.org (Postfix) with ESMTP id 6E8528FC0C for ; Tue, 8 Feb 2011 06:16:49 +0000 (UTC) Received: from [192.168.1.216] (unknown [76.91.19.169]) by bonett.org (Postfix) with ESMTPSA id 5C594124367; Tue, 8 Feb 2011 06:16:48 +0000 (UTC) From: Greg Bonett To: Jeremy Chadwick In-Reply-To: <20110208055239.GA2557@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <1297143276.9417.400.camel@ubuntu> <20110208055239.GA2557@icarus.home.lan> Content-Type: multipart/mixed; boundary="=-DMozRkM55wtf1recgi8S" Date: Mon, 07 Feb 2011 22:16:46 -0800 Message-ID: <1297145806.9417.413.camel@ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:16:49 -0000 --=-DMozRkM55wtf1recgi8S Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit ok, I will start trying to locate the cause of the problem. I've attached my dmesg output after boot. I'm currently downloading a liveCD to run memtest from. When you say "rebuild your kernel with debugging enabled" do you mean add the "makeoptions DEBUG=-g" option to my kernel config and rebuild? Also, I'll start logging my cpu temp and I'll see if it peaks before a lockup. (I have had one of six cores disabled thinking this might prevent overheating) Thank you for your help talking me through this. I've attached my dmesg output as dmesg.log. On Mon, 2011-02-07 at 21:52 -0800, Jeremy Chadwick wrote: > On Mon, Feb 07, 2011 at 09:34:36PM -0800, Greg Bonett wrote: > > Thank you for the help. I've implemented your > > suggested /boot/loader.conf and /etc/sysctrl.conf tunings. > > Unfortunately, after implementing these settings, I experienced another > > lockup. And by "lockup" I mean, nothing responding (sshd, keyboard, num > > lock) - had to reset. > > > > I'm trying to isolate the cause of these lockups. I rebooted the system > > and tried to simulate high load condition WITHOUT mounting my zfs pool. > > First I ran many instances of "dd if=/dev/random of=/dev/null bs=4m" to > > get high CPU load. The machine ran for many hours under this condition > > without lockup. Then I added a few "dd if=/dev/adX of=/dev/null bs=4m" > > to simulate some io load. After doing this it locked up immediately. > > Thinking I had figured out the source of the problem, I rebooted and > > tried to replicate this experience but was not able to. So far it has > > been running for two hours with six "dd if=/dev/adX" commands (one for > > each disk) and about a dozen "dd if=/dev/urandom" commands (to keep cpu > > near 100%). I'll let it keep running and see if it locks again without > > ever mounting zfs. > > > > any ideas? > > No NumLock LED toggling is a pretty good indicator of a hardware-level > problem. An extra test would be to rebuild your kernel with debugging > enabled so that when the machine locks, you could try pressing > Ctrl-Alt-Esc at the VGA console and see if you drop to a db> prompt. If > so, that means the machine is actually alive (well, the kernel anyway). > > As for causes: you could have bad memory (memtest86+ is a decent free > test, but not infallible), you could have a PSU that doesn't have decent > voltage ranges on its 3V, 5V, or 12V lines, you could have a PSU that > doesn't provide enough power for all the devices connected to it, you > could have a bad motherboard, your CPU could be overheating, you could > be encountering a strange hardware/silicon bug, there could be a small > or thin slice of metal laying across a single trace on the motherboard, > etc... The list is enormous. Hardware problems often require a person > to spend a lot of time and money, replacing a single part at a time, > until the problem goes away. > > The only thing we know for sure at this point is that your Western > Digital drive behaves erratically with regards to excessive load > cycling. That is almost certainly the reason for your READ_DMA48 > errors. > > So, you may actually be experiencing two separate issues at the > same time. It's hard to tell at this point. > > In the meantime, can you please provide output from "dmesg" after the > machine comes up? I'm curious to know what sort of hardware is in this > machine, especially with regards to its storage controller. > --=-DMozRkM55wtf1recgi8S-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 06:46: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 94CCB1065697 for ; Tue, 8 Feb 2011 06:46:35 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 722388FC12 for ; Tue, 8 Feb 2011 06:46:35 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 5Jkb1g0010b6N64AFJmany; Tue, 08 Feb 2011 06:46:34 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta03.emeryville.ca.mail.comcast.net with comcast id 5JmZ1g0042tehsa8PJmaGw; Tue, 08 Feb 2011 06:46:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A92A39B422; Mon, 7 Feb 2011 22:46:33 -0800 (PST) Date: Mon, 7 Feb 2011 22:46:33 -0800 From: Jeremy Chadwick To: Greg Bonett Message-ID: <20110208064633.GA3367@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <1297143276.9417.400.camel@ubuntu> <20110208055239.GA2557@icarus.home.lan> <1297145806.9417.413.camel@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1297145806.9417.413.camel@ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:46:35 -0000 On Mon, Feb 07, 2011 at 10:16:46PM -0800, Greg Bonett wrote: > ok, I will start trying to locate the cause of the problem. I've > attached my dmesg output after boot. I'm currently downloading a liveCD > to run memtest from. When you say "rebuild your kernel with debugging > enabled" do you mean add the "makeoptions DEBUG=-g" option to my > kernel config and rebuild? No, but that would be a useful addition as well, assuming you have the disk space on your root filesystem for modules/kernel with debugging symbols. These are the options you want to add to your kernel config: # Debugging options options BREAK_TO_DEBUGGER # Sending a serial BREAK drops to DDB options KDB # Enable kernel debugger support options KDB_TRACE # Print stack trace automatically on panic options DDB # Support DDB options GDB # Support remote GDB Documented here: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html > Also, I'll start logging my cpu temp and I'll see if it peaks before a > lockup. (I have had one of six cores disabled thinking this might > prevent overheating) Unlikely. Present-day operating systems (including Windows for that matter) are pretty good about halting processors (cores) which aren't in use/aren't needed, which greatly helps with diminishing power usage and temperatures. Each CPU model is different, so you'd have to find someone with an AMD Phenom II X6 1075T CPU and compare thermals. > Thank you for your help talking me through this. > > I've attached my dmesg output as dmesg.log. Let's look at your storage controller setup: atapci0: irq 18 atapci1: on atapci0 ata2: on atapci1 ata3: on atapci1 ata4: on atapci0 atapci2: irq 19 atapci2: AHCI v1.20 controller with 4 6Gbps ports, PM supported ata5: on atapci2 ata6: on atapci2 ata7: on atapci2 ata8: on atapci2 atapci3: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci3 ata1: on atapci3 There have been recent discussions about "problems" on the ATI IXP700/800 controllers. I do not buy AMD systems, so I can't comment on this controllers' reliability. Just a FYI point. Here's the thread: http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/thread.html#61348 I also tend to avoid JMicron controllers like the plague. I've seen too many problem reports with them over the years, regardless of OS. Now for the disk layout (I'm excluding da0, which is a USB flash disk of some kind). ad0: 953869MB at ata0-master UDMA133 SATA ad1: 953869MB at ata0-slave UDMA133 SATA ad4: 1430799MB at ata2-master UDMA100 SATA 3Gb/s ad8: 15279MB at ata4-master UDMA66 acd0: CDRW at ata4-slave UDMA33 ad10: 953869MB at ata5-master UDMA100 SATA 3Gb/s ad12: 953869MB at ata6-master UDMA100 SATA 3Gb/s ad14: 953869MB at ata7-master UDMA100 SATA 3Gb/s ad16: 953869MB at ata8-master UDMA100 SATA 3Gb/s You have a very large number of hard disks in this machine, so I sure hope you do have a decent enough PSU to handle it all. If I had to make a recommendation, it would be to decrease the number of hard disks in the machine. You have 8 of them -- one of which may be a RAM drive or something similar -- and that isn't including your CDRW drive. I would also try getting rid of the JMicron controller; I would recommend investing in a Silicon Image controller to replace it, specifically one driven by the 3124, 3132, or 3531 chips. Avoid the 3112, 3114, and 3512 chips: http://en.wikipedia.org/wiki/Silicon_Image#Product_alerts Next we have this: > ad1: TIMEOUT - READ_DMA retrying (1 retry left) LBA=1 > GEOM: ad1: partition 1 does not start on a track boundary. > GEOM: ad1: partition 1 does not end on a track boundary. > GEOM: label/1TBdisk5: partition 1 does not start on a track boundary. > GEOM: label/1TBdisk5: partition 1 does not end on a track boundary. This doesn't look good, especially the READ_DMA timeout on ad1. That's a different disk than the one you told me about before. LBA 1 is literally the 2nd block on the disk, which is a little too close to block 0 for comfort. I'd love to see "smartctl -a /dev/ad1" output here. > calcru: runtime went backwards from 82 usec to 70 usec for pid 20 (flowcleaner) > calcru: runtime went backwards from 363 usec to 317 usec for pid 8 (pagedaemon) > calcru: runtime went backwards from 111 usec to 95 usec for pid 7 (xpt_thrd) > calcru: runtime went backwards from 1892 usec to 1629 usec for pid 1 (init) > calcru: runtime went backwards from 6786 usec to 6591 usec for pid 0 (kernel) This is a problem that has plagued FreeBSD for some time. It's usually caused by EIST (est) being used, but that's on Intel platforms. AMD has something similar called Cool'n'Quiet (see cpufreq(4) man page). Are you running powerd(8) on this system? If so, try disabling that and see if these go away. > GEOM_ELI: Device label/1tbgreendisk.eli created. > GEOM_ELI: Encryption: AES-CBC 256 > GEOM_ELI: Crypto: software > {...} There was no mention of geli(8) being used on this system until now. There may be other complexities as a result of this; I don't know. Good luck. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 12:43: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 C23B4106564A for ; Tue, 8 Feb 2011 12:43:21 +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 7543C8FC08 for ; Tue, 8 Feb 2011 12:43:21 +0000 (UTC) Received: by iyb26 with SMTP id 26so5753503iyb.13 for ; Tue, 08 Feb 2011 04:43:20 -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=FKv/yb72F5R5iE344dvqqFsTHVJSy21QZMmalmBXt9M=; b=aoJ+tu/fkZC2XKPYYzoC+YU7bMHrn1/PieaBjhdO64Jc3FPIJXU+fj6L3AZcBw2fF+ rf+2mejINoEunGp/Zn9HepWmWgHU6OPeeU+3x/FhneKLYumbxy+HkUmtIEz0GA/oRhGK WYmsqatlgcWLLSvD8+MXqVNViP+8v7PThhxu8= 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=RIm/oVIkKcXktQoXrqJEZCL66PkIeeT+ct/5vr7crC5SGe4xqGxQaG+XgqB6sVfl3d OZPH+67Kg25v1nIeF3nQCzl8uuvyRhmiJK5pxDEY95BeqdkYEDppUZsnzOkrlCfODRDv 7uxYrhPQupqyrJcJVQXQFN+VMzehWKwZhZphE= MIME-Version: 1.0 Received: by 10.42.176.134 with SMTP id be6mr1113777icb.82.1297169000216; Tue, 08 Feb 2011 04:43:20 -0800 (PST) Received: by 10.42.165.66 with HTTP; Tue, 8 Feb 2011 04:43:20 -0800 (PST) In-Reply-To: <20110207090347.GB20545@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <20110207090347.GB20545@icarus.home.lan> Date: Tue, 8 Feb 2011 23:43:20 +1100 Message-ID: From: Jean-Yves Avenard To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Greg Bonett , Zaphod Beeblebrox , freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 12:43:21 -0000 On 7 February 2011 20:03, Jeremy Chadwick wrote: > They're discussed practically on a monthly basis on the mailing lists > (either freebsd-fs or freebsd-stable). =A0Keeping track of them is almost > impossible at this point, which is also probably why the Wiki is > outdated. I like Sun's take on the matter: http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Tuning= _is_Evil "Tuning is often evil and should rarely be done. First, consider that the default values are set by the people who know the most about the effects of the tuning on the software that they supply. If a better value exists, it should be the default. While alternative values might help a given workload, it could quite possibly degrade some other aspects of performance. Occasionally, catastrophically so. " Which I thing summarise perfectly ZFS "tuning". If you want to know 20 differents opinions on how zfs needs to be tuned; talk to 20 different people. Everyone has their own ideas on how it should be done ; believe a particular setting made things better. I tried them all I could read here, none of them make much significant difference, and and when they do, usually it's just for the worse. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 13:29: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 A112B1065670 for ; Tue, 8 Feb 2011 13:29:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 7FDAD8FC12 for ; Tue, 8 Feb 2011 13:29:37 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 5RGD1g00516AWCUAARVdFF; Tue, 08 Feb 2011 13:29:37 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta06.emeryville.ca.mail.comcast.net with comcast id 5RVb1g00k2tehsa8SRVcti; Tue, 08 Feb 2011 13:29:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 703C39B422; Tue, 8 Feb 2011 05:29:35 -0800 (PST) Date: Tue, 8 Feb 2011 05:29:35 -0800 From: Jeremy Chadwick To: Jean-Yves Avenard Message-ID: <20110208132935.GA13494@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <20110207090347.GB20545@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: Greg Bonett , Zaphod Beeblebrox , freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:29:38 -0000 On Tue, Feb 08, 2011 at 11:43:20PM +1100, Jean-Yves Avenard wrote: > On 7 February 2011 20:03, Jeremy Chadwick wrote: > > > They're discussed practically on a monthly basis on the mailing lists > > (either freebsd-fs or freebsd-stable).  Keeping track of them is almost > > impossible at this point, which is also probably why the Wiki is > > outdated. > > I like Sun's take on the matter: > > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Tuning_is_Evil > "Tuning is often evil and should rarely be done. > > First, consider that the default values are set by the people who know > the most about the effects of the tuning on the software that they > supply. If a better value exists, it should be the default. While > alternative values might help a given workload, it could quite > possibly degrade some other aspects of performance. Occasionally, > catastrophically so. > > " > > Which I thing summarise perfectly ZFS "tuning". > > If you want to know 20 differents opinions on how zfs needs to be > tuned; talk to 20 different people. > Everyone has their own ideas on how it should be done ; believe a > particular setting made things better. > > I tried them all I could read here, none of them make much significant > difference, and and when they do, usually it's just for the worse. Sorry, that just isn't the case. I'm not going to get into an argument on a mailing list, or privately for that matter, regarding the implication of *not* adjusting what I've shown. Even developers who are commit coding to the ZFS tree -- such as avg@ -- have advocated these settings. The documentation you reference is for Solaris and OpenSolaris. When was the last time you used either of them? Part of my day job involves maintaining and managing hundreds upon hundreds of Solaris 10 servers. Do they require tuning? Absolutely not. And that's because ZFS on FreeBSD *is not* identical (re: innards, VM, etc.) to that of ZFS on Solaris. You can dig up verification of these claims by reading freebsd-fs and freebsd-stable archives. If you want rock-solid, no-tuning-needed ZFS, run Solaris. Period. I have nothing more to say with regards to this part of the thread. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 14:52: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 14F631065675 for ; Tue, 8 Feb 2011 14:52:17 +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 9F4838FC0A for ; Tue, 8 Feb 2011 14:52:16 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate2.intern.punkt.de with ESMTP id p18EqENc056425; Tue, 8 Feb 2011 15:52:14 +0100 (CET) Received: from [217.29.45.124] ([217.29.45.124]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id p18EqEPb050825; Tue, 8 Feb 2011 15:52:14 +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: <20110207085537.GA20545@icarus.home.lan> Date: Tue, 8 Feb 2011 15:52:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E948342-DEFF-4DEB-B0DC-990B647549EB@punkt.de> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1082) Cc: freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:52:17 -0000 Hello, Jeremy, Am 07.02.2011 um 09:55 schrieb Jeremy Chadwick: > The Wiki is outdated, I'm sorry to say. Given that you have 8GB RAM, = I > would recommend these settings. > ... Thank you very much for the insight. A current summary of recommended settings is very much appreciated. Could you add values for amd64 machines with 4 and 16 GB of memory? That would help me a lot. Storage around 4 and 11 TB, respectively. Access pattern: backup storage. Kind 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 Tue Feb 8 15:15: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 647B7106564A for ; Tue, 8 Feb 2011 15:15:42 +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 EC4DC8FC18 for ; Tue, 8 Feb 2011 15:15:41 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate2.intern.punkt.de with ESMTP id p18FFeIf056828; Tue, 8 Feb 2011 16:15:40 +0100 (CET) Received: from [217.29.45.124] ([217.29.45.124]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id p18FFeiu051751; Tue, 8 Feb 2011 16:15:40 +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: Date: Tue, 8 Feb 2011 16:15:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16407D66-5303-4FF1-85D1-9372B4135C5A@punkt.de> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <6E948342-DEFF-4DEB-B0DC-990B647549EB@punkt.de> To: Tom Evans X-Mailer: Apple Mail (2.1082) Cc: freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:15:42 -0000 Hello, Am 08.02.2011 um 16:00 schrieb Tom Evans: > My home file server is similar in spec to that - Core 2 Duo, 4 GB RAM > and running 8.2-RC3/amd64, with a pool with two 6 x 1.5 TB raidz > arrays, for a total capacity of ~16 TB. The only ZFS settings I have > changed from default are: >=20 > # Allow prefetch (normally disabled for 4GB or less RAM) > vfs.zfs.prefetch_disable=3D0 > # Don't let ZFS use UMA, restricts available memory > vfs.zfs.zio.use_uma=3D0 >=20 > I think vfs.zfs.zio.use_uma defaults to 0 now anyway. >=20 > I've never had a crash related to memory pressure or any other ZFS > issue - it doesn't get that stressed. YMMV! Yes, it may - and it does ;-) With no tuning at all my FreeNAS (FreeBSD 7.3, amd64, 4 GB RAM, 4 TB = raidz2) crashes within minutes if I copy larger amounts of data via SMB or AFP = to the ZFS.=20 With these settings it's perfectly stable, but I figured from Jeremy's = that they might not be optimal: vm.kmem_size_max=3D"1024M" vm.kmem_size=3D"1024M" vfs.zfs.arc_max=3D"100M" vfs.zfs.prefetch_disable=3D"0" And with the very same settings on our bigger backup box I really need = to improve performance somehow. We are backing up >50 hosts nightly with Amanda. I got from this post that I definitely should increase memory on this machine: = http://constantin.glez.de/blog/2010/06/closer-look-zfs-vdevs-and-performan= ce Kind 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 Tue Feb 8 15:30: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 06A4A1065673 for ; Tue, 8 Feb 2011 15:30:39 +0000 (UTC) (envelope-from tevans.uk@googlemail.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 A830F8FC15 for ; Tue, 8 Feb 2011 15:30:38 +0000 (UTC) Received: by qyk8 with SMTP id 8so432195qyk.13 for ; Tue, 08 Feb 2011 07:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=A+nGJAOgERQcwmU6QYDBob29iBy0Vc1pzh5COpR5utA=; b=QJifK0ObNcHY1Arc1vwSYZyA5l84CC8e5LD0WV11btA6Rpjfp9C1y3g1n9aOm1jPTk +uBa5r1co/EABMdNelVv1TgQzQWv0S6kKLCgpGfNRaexANzyhfVlqHe5Rf0dyg3zxq4N 4VEQWGxSKsvQric2beNiN/FwEli4HhzkmESpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hlEMyBpy9sBb/v8b4/djGIXlwq4kcwvQyDcmFH7nnCzCbIJXzHLlWA2TgBom0nBHmN rD25utqwLyaga/qNd2h3/ywtMIUOE1yihUI47mX2qSDR3sMM3dAxDVw8yVNoItn1QM8+ hpmE5X24QeLmLRHyI9XHW038TX81fkaKqKx7Q= MIME-Version: 1.0 Received: by 10.229.190.204 with SMTP id dj12mr12230767qcb.101.1297177258220; Tue, 08 Feb 2011 07:00:58 -0800 (PST) Received: by 10.229.246.8 with HTTP; Tue, 8 Feb 2011 07:00:58 -0800 (PST) In-Reply-To: <6E948342-DEFF-4DEB-B0DC-990B647549EB@punkt.de> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <6E948342-DEFF-4DEB-B0DC-990B647549EB@punkt.de> Date: Tue, 8 Feb 2011 15:00:58 +0000 Message-ID: From: Tom Evans To: "Patrick M. Hausen" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:30:39 -0000 On Tue, Feb 8, 2011 at 2:52 PM, Patrick M. Hausen wrote: > Hello, Jeremy, > > Am 07.02.2011 um 09:55 schrieb Jeremy Chadwick: >> The Wiki is outdated, I'm sorry to say. =C2=A0Given that you have 8GB RA= M, I >> would recommend these settings. >> ... > > Thank you very much for the insight. A current summary of recommended > settings is very much appreciated. > > Could you add values for amd64 machines with 4 and 16 GB of memory? > That would help me a lot. Storage around 4 and 11 TB, respectively. > Access pattern: backup storage. > > Kind regards, > Patrick My home file server is similar in spec to that - Core 2 Duo, 4 GB RAM and running 8.2-RC3/amd64, with a pool with two 6 x 1.5 TB raidz arrays, for a total capacity of ~16 TB. The only ZFS settings I have changed from default are: # Allow prefetch (normally disabled for 4GB or less RAM) vfs.zfs.prefetch_disable=3D0 # Don't let ZFS use UMA, restricts available memory vfs.zfs.zio.use_uma=3D0 I think vfs.zfs.zio.use_uma defaults to 0 now anyway. I've never had a crash related to memory pressure or any other ZFS issue - it doesn't get that stressed. YMMV! Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 19:39: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 E44B41065670 for ; Tue, 8 Feb 2011 19:39:51 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from local.wintek.com (local.wintek.com [206.230.2.234]) by mx1.freebsd.org (Postfix) with ESMTP id A6BE58FC15 for ; Tue, 8 Feb 2011 19:39:50 +0000 (UTC) Received: from rjk.wintek.local (172.28.1.248) by local.wintek.com (172.28.1.234) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 8 Feb 2011 14:39:49 -0500 Message-ID: <4D519C05.2010102@wintek.com> Date: Tue, 8 Feb 2011 14:39:49 -0500 From: Richard Kuhns Organization: Wintek Corporation User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101210 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4D5069C9.20900@wintek.com> In-Reply-To: <4D5069C9.20900@wintek.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: csup not updating all files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rjk@wintek.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:39:52 -0000 Sorry to followup on my own post, but I figured out what was going on. It appears to be a problem with csup. I've been using csup to maintain 2 CVS Repositories, one at home and one at work. The last couple of times I've run csup there were lots of 'checksum mismatches', so csup said it would download the entire file. I was watching it this morning and saw it going through {/usr/src}/sys, usr.bin, and usr.sbin. It didn't, however, actually download all of the files. When it said it was finished (successfully!), the last file downloaded was in sys/netinet. This was on my home system (amd64). I tried on a machine a machine at work (i386) with the same results, except that csup stopped downloading files much earlier. I restarted the csup; it picked up where it left off (somewhere in sys/dev) complaining about checksum mismatches. It then downloaded a fair number of files but still stopped before reaching usr.bin. (Sorry I don't have hard numbers on how many files). I installed cvsup. It picked up where csup had left off (also complaining about checksums), but it updated everything and I've been able to buildworld and buildkernel without any problems. So my earlier problem was due to /usr/src/gnu being updated while /usr/src/sys/sys wasn't :-( . -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 8 21:31: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 409041065672 for ; Tue, 8 Feb 2011 21:31:59 +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 10D4E8FC0A for ; Tue, 8 Feb 2011 21:31:59 +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 B185046B09; Tue, 8 Feb 2011 16:31:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E72CA8A009; Tue, 8 Feb 2011 16:31:57 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org, rjk@wintek.com Date: Tue, 8 Feb 2011 16:31:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D5069C9.20900@wintek.com> <4D519C05.2010102@wintek.com> In-Reply-To: <4D519C05.2010102@wintek.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102081631.46450.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 08 Feb 2011 16:31:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: csup not updating all files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2011 21:31:59 -0000 On Tuesday, February 08, 2011 2:39:49 pm Richard Kuhns wrote: > Sorry to followup on my own post, but I figured out what was going on. It > appears to be a problem with csup. > > I've been using csup to maintain 2 CVS Repositories, one at home and one at work. > > The last couple of times I've run csup there were lots of 'checksum mismatches', > so csup said it would download the entire file. I was watching it this morning > and saw it going through {/usr/src}/sys, usr.bin, and usr.sbin. It didn't, > however, actually download all of the files. When it said it was finished > (successfully!), the last file downloaded was in sys/netinet. This was on my > home system (amd64). > > I tried on a machine a machine at work (i386) with the same results, except that > csup stopped downloading files much earlier. I restarted the csup; it picked up > where it left off (somewhere in sys/dev) complaining about checksum mismatches. > It then downloaded a fair number of files but still stopped before reaching > usr.bin. (Sorry I don't have hard numbers on how many files). > > I installed cvsup. It picked up where csup had left off (also complaining about > checksums), but it updated everything and I've been able to buildworld and > buildkernel without any problems. > > So my earlier problem was due to /usr/src/gnu being updated while > /usr/src/sys/sys wasn't :-( . Hmm, I noticed this recently as well, but wasn't sure if anyone else had seen this. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 9 07:07: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 981B71065693 for ; Wed, 9 Feb 2011 07:07:25 +0000 (UTC) (envelope-from greg@bonett.org) Received: from bonett.org (bonett.org [66.249.7.150]) by mx1.freebsd.org (Postfix) with ESMTP id 54F128FC0C for ; Wed, 9 Feb 2011 07:07:25 +0000 (UTC) Received: from [192.168.1.216] (unknown [76.91.19.169]) by bonett.org (Postfix) with ESMTPSA id 891FB124098; Wed, 9 Feb 2011 07:07:22 +0000 (UTC) From: Greg Bonett To: Jeremy Chadwick In-Reply-To: <20110208064633.GA3367@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <1297143276.9417.400.camel@ubuntu> <20110208055239.GA2557@icarus.home.lan> <1297145806.9417.413.camel@ubuntu> <20110208064633.GA3367@icarus.home.lan> Content-Type: multipart/mixed; boundary="=-tk2Zc8zBx+cz/jsOhEgH" Date: Tue, 08 Feb 2011 23:07:21 -0800 Message-ID: <1297235241.4729.35.camel@ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 07:07:25 -0000 --=-tk2Zc8zBx+cz/jsOhEgH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit ok, I think you're right - there is more than one problem with this system, but I think I'm starting to isolate them and make some progress. > # Debugging options > options BREAK_TO_DEBUGGER # Sending a serial BREAK drops to DDB > options KDB # Enable kernel debugger support > options KDB_TRACE # Print stack trace automatically on panic > options DDB # Support DDB > options GDB # Support remote GDB > > Documented here: > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html rebuilt my kernel with debug options, but thankfully I think I've learned how to avoid lockup for the time being. I think I am asking too much of my 650 watt power supply. I unplugged one hard drive and disabled another CPU core (now running 4 of 6). I'm sad to lose the horsepower, but I was able to complete an entire zpool scrub and other high load tasks without a lockup. > Let's look at your storage controller setup: > > atapci0: irq 18 > atapci1: on atapci0 > ata2: on atapci1 > ata3: on atapci1 > ata4: on atapci0 > atapci2: irq 19 > atapci2: AHCI v1.20 controller with 4 6Gbps ports, PM supported > ata5: on atapci2 > ata6: on atapci2 > ata7: on atapci2 > ata8: on atapci2 > atapci3: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 > ata0: on atapci3 > ata1: on atapci3 > > There have been recent discussions about "problems" on the ATI > IXP700/800 controllers. I do not buy AMD systems, so I can't comment on > this controllers' reliability. Just a FYI point. Here's the thread: > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/thread.html#61348 > > I also tend to avoid JMicron controllers like the plague. I've seen too > many problem reports with them over the years, regardless of OS. I'll look into this. I think the controller is the source of the "FAILURE - READ_LMA48" errors. I switched the disk/sata port pairing and the error stayed with the sata port, not the disk. > Now for the disk layout (I'm excluding da0, which is a USB flash disk of > some kind). > > ad0: 953869MB at ata0-master UDMA133 SATA > ad1: 953869MB at ata0-slave UDMA133 SATA > ad4: 1430799MB at ata2-master UDMA100 SATA 3Gb/s > ad8: 15279MB at ata4-master UDMA66 > acd0: CDRW at ata4-slave UDMA33 > ad10: 953869MB at ata5-master UDMA100 SATA 3Gb/s > ad12: 953869MB at ata6-master UDMA100 SATA 3Gb/s > ad14: 953869MB at ata7-master UDMA100 SATA 3Gb/s > ad16: 953869MB at ata8-master UDMA100 SATA 3Gb/s > > You have a very large number of hard disks in this machine, so I sure > hope you do have a decent enough PSU to handle it all. > > If I had to make a recommendation, it would be to decrease the number of > hard disks in the machine. You have 8 of them -- one of which may be a > RAM drive or something similar -- and that isn't including your CDRW > drive. Yes, I think this is the problem. Though, for clarification, there are only 6 spindle disks in the machine. ad4 is an external drive over esata (with it's own power), and ad8 is a CF drive. > I would also try getting rid of the JMicron controller; I would > recommend investing in a Silicon Image controller to replace it, > specifically one driven by the 3124, 3132, or 3531 chips. Avoid the > 3112, 3114, and 3512 chips: > http://en.wikipedia.org/wiki/Silicon_Image#Product_alerts Thanks for the recommendation. I'll probably pick one of these up along with a new power supply. > Next we have this: > > > ad1: TIMEOUT - READ_DMA retrying (1 retry left) LBA=1 > > GEOM: ad1: partition 1 does not start on a track boundary. > > GEOM: ad1: partition 1 does not end on a track boundary. > > GEOM: label/1TBdisk5: partition 1 does not start on a track boundary. > > GEOM: label/1TBdisk5: partition 1 does not end on a track boundary. > > This doesn't look good, especially the READ_DMA timeout on ad1. That's > a different disk than the one you told me about before. LBA 1 is > literally the 2nd block on the disk, which is a little too close to > block 0 for comfort. I'd love to see "smartctl -a /dev/ad1" output > here. I've attached the output of smartctl -a /dev/ad1. I don't think this error is being caused by the disk though. As I said above, I changed the sata port / drive pairing and this error stays with the sata port, not the drive. (so, as you said, time for a new controller) > > calcru: runtime went backwards from 82 usec to 70 usec for pid 20 (flowcleaner) > > calcru: runtime went backwards from 363 usec to 317 usec for pid 8 (pagedaemon) > > calcru: runtime went backwards from 111 usec to 95 usec for pid 7 (xpt_thrd) > > calcru: runtime went backwards from 1892 usec to 1629 usec for pid 1 (init) > > calcru: runtime went backwards from 6786 usec to 6591 usec for pid 0 (kernel) > > This is a problem that has plagued FreeBSD for some time. It's usually > caused by EIST (est) being used, but that's on Intel platforms. AMD has > something similar called Cool'n'Quiet (see cpufreq(4) man page). Are > you running powerd(8) on this system? If so, try disabling that and see > if these go away. sadly, I don't know if I'm running powerd. ps aux | grep power gives nothing, so no I guess... as far as I can tell, this error is the least of my problems right now, but i would like to fix it. > > GEOM_ELI: Device label/1tbgreendisk.eli created. > > GEOM_ELI: Encryption: AES-CBC 256 > > GEOM_ELI: Crypto: software > > {...} > > There was no mention of geli(8) being used on this system until now. > There may be other complexities as a result of this; I don't know. yeah, geli is being used on this system, sorry i forgot to mention that > Good luck. > Thanks for the help, I'm at least able to keep the machine online now. --=-tk2Zc8zBx+cz/jsOhEgH Content-Disposition: attachment; filename="ad1.smart" Content-Type: text/plain; name="ad1.smart"; charset="UTF-8" Content-Transfer-Encoding: 7bit smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.1-RELEASE-p2 amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.11 family Device Model: ST31000333AS Serial Number: 9TE1MB10 Firmware Version: CC1H 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 4 Local Time is: Tue Feb 8 07:41:31 2011 PST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 617) 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: ( 1) minutes. Extended self-test routine recommended polling time: ( 208) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x103f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 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 120 099 006 Pre-fail Always - 243069120 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 84 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 079 060 030 Pre-fail Always - 83902794 9 Power_On_Hours 0x0032 084 084 000 Old_age Always - 14308 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 84 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 093 000 Old_age Always - 56 189 High_Fly_Writes 0x003a 017 017 000 Old_age Always - 83 190 Airflow_Temperature_Cel 0x0022 076 051 045 Old_age Always - 24 (Min/Max 24/24) 194 Temperature_Celsius 0x0022 024 049 000 Old_age Always - 24 (0 17 0 0) 195 Hardware_ECC_Recovered 0x001a 050 019 000 Old_age Always - 243069120 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 96619584305016 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 412576321 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 2438661969 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 Extended offline Completed without error 00% 13221 - # 2 Extended offline Interrupted (host reset) 90% 13216 - # 3 Short offline Completed without error 00% 13207 - # 4 Extended offline Interrupted (host reset) 50% 13199 - # 5 Extended offline Completed without error 00% 13134 - # 6 Conveyance offline Completed without error 00% 13131 - 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. --=-tk2Zc8zBx+cz/jsOhEgH-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 9 09:29: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 BD861106566B for ; Wed, 9 Feb 2011 09:29:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6B68FC08 for ; Wed, 9 Feb 2011 09:29:00 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 5lTs1g0010QkzPwA5lUzk6; Wed, 09 Feb 2011 09:28:59 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta02.emeryville.ca.mail.comcast.net with comcast id 5lUy1g00T2tehsa8NlUyGX; Wed, 09 Feb 2011 09:28:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6DD579B422; Wed, 9 Feb 2011 01:28:58 -0800 (PST) Date: Wed, 9 Feb 2011 01:28:58 -0800 From: Jeremy Chadwick To: Greg Bonett Message-ID: <20110209092858.GA35033@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <1297143276.9417.400.camel@ubuntu> <20110208055239.GA2557@icarus.home.lan> <1297145806.9417.413.camel@ubuntu> <20110208064633.GA3367@icarus.home.lan> <1297235241.4729.35.camel@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1297235241.4729.35.camel@ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:29:00 -0000 On Tue, Feb 08, 2011 at 11:07:21PM -0800, Greg Bonett wrote: > rebuilt my kernel with debug options, but thankfully I think I've > learned how to avoid lockup for the time being. I think I am asking too > much of my 650 watt power supply. I unplugged one hard drive and > disabled another CPU core (now running 4 of 6). I'm sad to lose the > horsepower, but I was able to complete an entire zpool scrub and other > high load tasks without a lockup. Too much to reply to with regards to your disk setup, so I'll summarise my recommendations at this point: 1) Re-enable both CPU cores; I can't see this being responsible for the problem. I do understand the concern over added power draw, but see recommendation (4a) below. 1) Disable the JMicron SATA controller entirely. 2) Disable the ATI IXP700/800 SATA controller entirely. 3a) Purchase a Silicon Image controller (one of the models I referenced in my previous mail). Many places sell them, but lots of online vendors hide or do not disclose what ASIC they're using for the controller. You might have to look at their Driver Downloads section to find out what actual chip is used. 3b) You've stated you're using one of your drives on an eSATA cable. If you are using a SATA-to-eSATA adapter bracket[1][2], please stop immediately and use a native eSATA port instead. Adapter brackets are known to cause all sorts of problems that appear as bizarre/strange failures (xxx_DMAxx errors are quite common in this situation), not to mention with all the internal cabling and external cabling, a lot of the time people exceed the maximum SATA cable length without even realising it -- it's the entire length from the SATA port on your motherboard, to and through the adapter (good luck figuring out how much wire is used there, to the end of the eSATA cable. Native eSATA removes use of the shoddy adapters and also extends the maximum cable length (from 1 metre to 2 metres), plus provides the proper amount of power for eSATA devices (yes this matters!). Wikipedia has details[3]. Silicon Image and others do make chips that offer both internal SATA and an eSATA port on the same controller. Given your number of disks, you might have to invest in multiple controllers. 4a) Purchase a Kill-a-Watt meter and measure exactly how much power your entire PC draws, including on power-on (it will be a lot higher during power-on than during idle/use, as drives spinning up draw lots of amps). I strongly recommend the Kill-a-Watt P4600 model[4] over the P4400 model. Based on the wattage and amperage results, you should be able to determine if you're nearing the maximum draw of your PSU. 4b) However, even if you're way under-draw (say, 400W), the draw may not be the problem but instead the maximum amount of power/amperage/whatever a single physical power cable can provide. I imagine to some degree it depends on the gauge of wire being used; excessive use of Y-splitters to provide more power connectors than the physical cable provides means that you might be drawing too much across the existing gauge of cable that runs to the PSU. I have seen setups where people have 6 hard disks coming off of a single power cable (with Y-splitters and molex-to-SATA power adapters) and have their drives randomly drop off the bus. Please don't do this. A better solution might be to invest in a server-grade chassis, such as one from Supermicro, that offers a hot-swap SATA backplane. The backplane provides all the correct amounts of power to the maximum number of disks that can be connected to it. Here are some cases you can look at that[5][6][7]. Also be aware that if you're already using a hot-swap backplane, most consumer-grade ones are complete junk and have been known to cause strange anomalies; it's always best in those situations to go straight from motherboard-to-drive or card-to-drive. [1]: http://www.cooldrives.com/newesiidebrf.html [2]: http://www.cooldrives.com/essaii3gbexp.html [3]: http://en.wikipedia.org/wiki/Serial_ATA#eSATA [4]: http://www.amazon.com/dp/B000RGF29Q [5]: http://www.supermicro.com/products/chassis/4U/?chs=742 [6]: http://www.supermicro.com/products/chassis/4U/?chs=743 [7]: http://www.supermicro.com/products/chassis/4U/?chs=745 > I've attached the output of smartctl -a /dev/ad1. I don't think this > error is being caused by the disk though. After reviewing your SMART stats on the drive, I agree -- it looks perfectly healthy (for a Seagate disk). Nothing wrong there. > > > calcru: runtime went backwards from 82 usec to 70 usec for pid 20 (flowcleaner) > > > calcru: runtime went backwards from 363 usec to 317 usec for pid 8 (pagedaemon) > > > calcru: runtime went backwards from 111 usec to 95 usec for pid 7 (xpt_thrd) > > > calcru: runtime went backwards from 1892 usec to 1629 usec for pid 1 (init) > > > calcru: runtime went backwards from 6786 usec to 6591 usec for pid 0 (kernel) > > > > This is a problem that has plagued FreeBSD for some time. It's usually > > caused by EIST (est) being used, but that's on Intel platforms. AMD has > > something similar called Cool'n'Quiet (see cpufreq(4) man page). Are > > you running powerd(8) on this system? If so, try disabling that and see > > if these go away. > > sadly, I don't know if I'm running powerd. > ps aux | grep power gives nothing, so no I guess... > as far as I can tell, this error is the least of my problems right now, > but i would like to fix it. Yes that's an accurate ps/grep to use; powerd_enable="yes" in /etc/rc.conf is how you make use of it. Could you provide output from "sysctl -a | grep freq"? That might help shed some light on the above errors as well, but as I said, I'm not familiar with AMD systems. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 9 14:20: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 AC45B106566B for ; Wed, 9 Feb 2011 14:20:28 +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 509248FC12 for ; Wed, 9 Feb 2011 14:20:28 +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 p19EKKqv064481 for ; Wed, 9 Feb 2011 09:20:25 -0500 (EST) (envelope-from george@m5p.com) Received: (from george@localhost) by m5p.com (8.14.4/8.13.7/Submit) id p19EKJ5u001268; Wed, 9 Feb 2011 09:20:19 -0500 (EST) Date: Wed, 9 Feb 2011 09:20:19 -0500 (EST) Message-Id: <201102091420.p19EKJ5u001268@m5p.com> From: george+freebsd@m5p.com To: freebsd-stable@freebsd.org X-Spam-Score: -0.9 () BAYES_00,J_CHICKENPOX_35 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]); Wed, 09 Feb 2011 09:20:25 -0500 (EST) Subject: statd/lockd startup failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:20:28 -0000 Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up (with rpc.statd and rpc.lockd enabled in rc.conf), I get: Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd and slightly later: Feb 4 07:31:36 wonderland kernel: NLM: unexpected error contacting NSM, stat=5, errno=35 I can start rpc.statd and rpc.lockd manually at this point (and I have to start them to run firefox and mail with my NFS-mounted home directory and mail spool). But what might cause the above errors? -- George Mitchell From owner-freebsd-stable@FreeBSD.ORG Wed Feb 9 15:47:32 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 500FF106564A for ; Wed, 9 Feb 2011 15:47:32 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out8.libero.it (cp-out8.libero.it [212.52.84.108]) by mx1.freebsd.org (Postfix) with ESMTP id D34D58FC18 for ; Wed, 9 Feb 2011 15:47:31 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0203.4D52B47A.00F8,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.51.49.89) by cp-out8.libero.it (8.5.133) id 4D0F2C9807E642EE for freebsd-stable@freebsd.org; Wed, 9 Feb 2011 16:36:26 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.4) with ESMTP id p19FaLmu006371 for ; Wed, 9 Feb 2011 16:36:21 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <4D52B475.9070608@netfence.it> Date: Wed, 09 Feb 2011 16:36:21 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201102091420.p19EKJ5u001268@m5p.com> In-Reply-To: <201102091420.p19EKJ5u001268@m5p.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.1.2.13 Subject: Re: statd/lockd startup failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 15:47:32 -0000 On 02/09/11 15:20, george+freebsd@m5p.com wrote: > Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up > (with rpc.statd and rpc.lockd enabled in rc.conf), I get: > > Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use > Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd > > and slightly later: > > Feb 4 07:31:36 wonderland kernel: NLM: unexpected error contacting NSM, stat=5, errno=35 > > I can start rpc.statd and rpc.lockd manually at this point (and I have to > start them to run firefox and mail with my NFS-mounted home directory and > mail spool). But what might cause the above errors? -- George Mitchell FWIW I'm seeing this on 8.1 too. statd won't start and after KDE login it's no use anymore starting it manually: I have to reboot. The exact message I get is slightly different, though (no "bindresvport_sa", but something else I don't remember). I'll paste it when I'll see it again. bye av. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 9 20:23: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 B45171065784 for ; Wed, 9 Feb 2011 20:23:45 +0000 (UTC) (envelope-from chuzzwassa@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 6D7388FC23 for ; Wed, 9 Feb 2011 20:23:45 +0000 (UTC) Received: by qwj9 with SMTP id 9so445706qwj.13 for ; Wed, 09 Feb 2011 12:23:44 -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; bh=zYvF81QgRzyYK0PWMSXsecwyCx8ACCmCE3pOdDceibs=; b=G3QlRjiUhKc41Vkp+PzymxsD6Fvpa5bgmMCGExQptKotSIuqgDaGBNViSuvahAXvcl xtwZmJ5pL/+DH+GLIiacuw72kKzaHsXxxrl+0CzHbX3tKGE33SuNeRHVC7jgKAA8oUfx yWvSXBr660hFi2PWysMrIu3dB5WEqbNCC4D2I= 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=kBvaY9NnulCjn8E+RdiQJBFpjZKUbdFKCeKtmvbIdL49qKncGf/35KuiniNBKubxff 2ySlXbE/e7RV2gBtZBbqLcS9wm+ih+ApUc3UuEewFvyaulXZ22L2VQjxdkQ8qrzf8Unk nOtjrgyrvYXfpYPzEoMIZSyBkO16trfyKrM+A= MIME-Version: 1.0 Received: by 10.229.211.206 with SMTP id gp14mr15099564qcb.289.1297281328764; Wed, 09 Feb 2011 11:55:28 -0800 (PST) Received: by 10.220.12.6 with HTTP; Wed, 9 Feb 2011 11:55:28 -0800 (PST) In-Reply-To: <201102081631.46450.jhb@freebsd.org> References: <4D5069C9.20900@wintek.com> <4D519C05.2010102@wintek.com> <201102081631.46450.jhb@freebsd.org> Date: Thu, 10 Feb 2011 05:55:28 +1000 Message-ID: From: Andy Farkas To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: csup not updating all files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2011 20:23:45 -0000 On Wed, Feb 9, 2011 at 7:31 AM, John Baldwin wrote: > On Tuesday, February 08, 2011 2:39:49 pm Richard Kuhns wrote: > >> Sorry to followup on my own post, but I figured out what was going on. It >> appears to be a problem with csup. >> >> I've been using csup to maintain 2 CVS Repositories, one at home and one at work. >> >> The last couple of times I've run csup there were lots of 'checksum mismatches', >> so csup said it would download the entire file. I was watching it this morning > > Hmm, I noticed this recently as well, but wasn't sure if anyone else had seen > this. The 'checksum mismatches' are especially annoying when a new tag is applied to the tree. Practically the entire src repo is downloaded again :( -andyf From owner-freebsd-stable@FreeBSD.ORG Thu Feb 10 15:40:12 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 679CE10656AC for ; Thu, 10 Feb 2011 15:40:12 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from relay0.salford.ac.uk (relay0.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id D32898FC1D for ; Thu, 10 Feb 2011 15:40:11 +0000 (UTC) Received: (qmail 79992 invoked by uid 98); 10 Feb 2011 15:13:29 -0000 Received: from 146.87.255.121 by relay0.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.96/12655. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.037038 secs); 10 Feb 2011 15:13:29 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by relay0.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 10 Feb 2011 15:13:29 +0000 Received: (qmail 73419 invoked by uid 1002); 10 Feb 2011 15:13:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Feb 2011 15:13:27 -0000 Date: Thu, 10 Feb 2011 15:13:27 +0000 (GMT) From: "Mark Powell" To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2011 15:40:12 -0000 Hi, FreeBSD 8.1 r218475. I have a raidz2 with 6x2TB devices; 3x2tb HDD and 3 stripes of 2x1TB HDD. I have ufs / on USB flash. After boot0 starts and the USB boots it displays Drive C: is disk0 etc. for each drive. Then I can hear all the drives making noises. Sounds like the devices are being tasted, with the spinning char. This goes on for sometime. Often the machine hangs solid and I have to reset. It can take 3 or 4 attempts before the OS boots. I can tell it's hung by pressing the caps lock key. If the capslock light doesn't work I hit reset and cross my fingers. It's been like this for as long as I can remember (i.e. many different source trees). How can I fix this? I thought it might be a BIOS fault and not FBSD, so I was considering a new motherboard. However, if I have ufs / can't I stop all this tasting/zfs nonsense at boot and let the kernel do it all later and therefore not susceptible to any possible BIOS faults? I tried to rebuild with: LOADER_ZFS_SUPPORT=no in make.conf, but it seems to make no difference. Any ideas? Thanks. -- Mark Powell - UNIX System Administrator - The University of Salford IT Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 6624 www.pgp.com for PGP key From owner-freebsd-stable@FreeBSD.ORG Thu Feb 10 15:46: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 3C3D0106566B for ; Thu, 10 Feb 2011 15:46:51 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C9CC88FC19 for ; Thu, 10 Feb 2011 15:46:50 +0000 (UTC) Received: by bwz12 with SMTP id 12so2130056bwz.13 for ; Thu, 10 Feb 2011 07:46:49 -0800 (PST) Received: by 10.204.121.142 with SMTP id h14mr20935019bkr.93.1297352809579; Thu, 10 Feb 2011 07:46:49 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id x38sm96473bkj.13.2011.02.10.07.46.48 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 07:46:48 -0800 (PST) Message-ID: <4D540867.7050503@my.gd> Date: Thu, 10 Feb 2011 16:46:47 +0100 From: Damien Fleuriot 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2011 15:46:51 -0000 On 2/10/11 4:13 PM, Mark Powell wrote: > Hi, > FreeBSD 8.1 r218475. > I have a raidz2 with 6x2TB devices; 3x2tb HDD and 3 stripes of 2x1TB HDD. > I have ufs / on USB flash. > After boot0 starts and the USB boots it displays Drive C: is disk0 > etc. for each drive. Then I can hear all the drives making noises. > Sounds like the devices are being tasted, with the spinning char. This > goes on for sometime. Often the machine hangs solid and I have to reset. > It can take 3 or 4 attempts before the OS boots. I can tell it's hung by > pressing the caps lock key. If the capslock light doesn't work I hit > reset and cross my fingers. > It's been like this for as long as I can remember (i.e. many different > source trees). > How can I fix this? > I thought it might be a BIOS fault and not FBSD, so I was considering > a new motherboard. However, if I have ufs / can't I stop all this > tasting/zfs nonsense at boot and let the kernel do it all later and > therefore not susceptible to any possible BIOS faults? > I tried to rebuild with: > > LOADER_ZFS_SUPPORT=no > > in make.conf, but it seems to make no difference. > Any ideas? > Thanks. > Hi Mark, AFAIK (and people will correct me if I'm wrong), there is no ZFS support whatsoever at boot unless you've asked zfs_load="YES" in your loader.conf and installed the zfs bootcode. You say you have a raidz2 so I take it your server was working before ? The question I'm asking here is: before what ? Did you upgrade from 8.0 to 8.1 ? It may not be the best piece of advice you'll receive but I would try the following: 1/ a verbose boot, you never know. 2/ unplug a disk, try to boot, rinse/repeat until it works, to identify a potentially *very* faulty drive. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 10 15:47:46 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 8ECF610656A6 for ; Thu, 10 Feb 2011 15:47:46 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 4439F8FC1A for ; Thu, 10 Feb 2011 15:47:46 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 2D696D682 for ; Thu, 10 Feb 2011 16:47:43 +0100 (CET) Date: Thu, 10 Feb 2011 16:47:37 +0100 From: Ollivier Robert To: freebsd-stable@freebsd.org Message-ID: <20110210154737.GA1356@roberto-al.eurocontrol.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Thu, 10 Feb 2011 16:47:43 +0100 (CET) Subject: Re: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2011 15:47:46 -0000 According to Mark Powell: > etc. for each drive. Then I can hear all the drives making noises. > Sounds like the devices are being tasted, with the spinning char. > This goes on for sometime. Often the machine hangs solid and I have The controller has just been resetted by the driver and is now proceeding to spin the drives up (or just reset each of them) to make sure they are ready. Some controllers do that before loading the kernel, some later would be my guess. > LOADER_ZFS_SUPPORT=no I do not think it is ZFS related at all. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-stable@FreeBSD.ORG Thu Feb 10 16:53: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 1D776106564A; Thu, 10 Feb 2011 16:53:07 +0000 (UTC) (envelope-from gleb.kurtsou@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 4A3E98FC0A; Thu, 10 Feb 2011 16:53:05 +0000 (UTC) Received: by fxm16 with SMTP id 16so1675372fxm.13 for ; Thu, 10 Feb 2011 08:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=/UYza3rj0sq7Qn10VHYSj/uDWGzyA/BiNAJ3IslxEGs=; b=TRF+E7SJFoZdg8ljnAmsqPQY1CRFYxsCFAW/PqNwEvVlk+my5LeUSjxNIA5jTtb5J6 HomJFqopOAOxy7eEEr2wqH0mns3QBRXCG1UWW5vMIo1GJLQAZC2gllxArxqX6meR0cnS 19AkGQ6MriX3c1i8ovxVQjvpm7MtghDVscPUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=u8EwzFIASZ5P65iizY5QSPqaiyNw8pcbp7p+VmYRgp3m0WlhzbRoj5jqlGcZ+NK5YD zefnMXexLCprHZQHzYrgvlfSQM6rcXuqqs/fSTyz8bYgdNrRPs3C3M8AfMLpDAtHUwFe EsqJVyD/nlEvgXrb2xGawD3xA2Ea+0ORcOBrY= Received: by 10.223.101.135 with SMTP id c7mr14121354fao.76.1297356785003; Thu, 10 Feb 2011 08:53:05 -0800 (PST) Received: from localhost ([91.187.7.158]) by mx.google.com with ESMTPS id z1sm128338fau.21.2011.02.10.08.53.01 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 08:53:03 -0800 (PST) Date: Thu, 10 Feb 2011 18:52:38 +0200 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20110210165237.GA15601@tops> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110119150200.GY2518@deviant.kiev.zoral.com.ua> <20110207133748.GA16327@tops.skynet.lt> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2011 16:53:07 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On (07/02/2011 15:35), Ivan Voras wrote: > On 7 February 2011 14:37, Gleb Kurtsou wrote: > > > It's up to user to mount tmpfs filesystems of reasonable size to prevent > > resource exhaustion. Anyway, enormously large tmpfs killing all your > > process is not the way to go. > > Of course not, but as I see it (from admin perspective), tmpfs should > behave as close to regular processes in consuming memory as possible > (where possible; obviously it cannot be subject to the OOM killer :) > ). Could you test the patch. It sets file system size to half of RAM by default and makes tmpfs behave much like regular process for vm subsystem. It no longer depends on inactive/wired memory stats, but checks if swap is nearly full. I've added vfs.tmpfs.swap_reserved sysctl to limit tmpfs growth. In my tests system didn't panic nor invoked OOM killer while consuming all available ram and swap. Unfortunately I wasn't able to test it with ZFS, I'd appreciate if you could run several test to see how ZFS and tmpfs will behave in low memory situation. If it works as expected I'm going to implement resize feature, update man page and change mount option parsing to allow specifying size in human readable form, e.g. size=1g. Thanks, Gleb. --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="tmpfs-memfix.patch.txt" commit 185bc042f0647a38b86aa78c5dda25a4bf0ea3dd Author: Gleb Kurtsou Date: Thu Feb 10 18:38:44 2011 +0200 tmpfs: Change the way available memory is calculated Try to allocate pages until filesystem size limit hit, fail in low memory situation. By default set filesystem size to half of available memory Add vfs.tmpfs.swap_reserved sysctl; set default to 2048 pages (8m or 16m) Check if free pages available before allocating new node Reorganize limits and mount option parsing diff --git a/sys/fs/tmpfs/tmpfs.h b/sys/fs/tmpfs/tmpfs.h index b1c4249..07f521c 100644 --- a/sys/fs/tmpfs/tmpfs.h +++ b/sys/fs/tmpfs/tmpfs.h @@ -487,61 +487,30 @@ int tmpfs_truncate(struct vnode *, off_t); * Memory management stuff. */ -/* Amount of memory pages to reserve for the system (e.g., to not use by - * tmpfs). - * XXX: Should this be tunable through sysctl, for instance? */ -#define TMPFS_PAGES_RESERVED (4 * 1024 * 1024 / PAGE_SIZE) - /* - * Returns information about the number of available memory pages, - * including physical and virtual ones. - * - * Remember to remove TMPFS_PAGES_RESERVED from the returned value to avoid - * excessive memory usage. - * + * Number of reserved swap pages should not be lower than + * swap_pager_almost_full high water mark. */ +#define TMPFS_SWAP_MINRESERVED 1024 + static __inline size_t -tmpfs_mem_info(void) +tmpfs_pages_max(struct tmpfs_mount *tmp) { - size_t size; - - size = swap_pager_avail + cnt.v_free_count + cnt.v_inactive_count; - size -= size > cnt.v_wire_count ? cnt.v_wire_count : size; - return size; + return (tmp->tm_pages_max); } -/* Returns the maximum size allowed for a tmpfs file system. This macro - * must be used instead of directly retrieving the value from tm_pages_max. - * The reason is that the size of a tmpfs file system is dynamic: it lets - * the user store files as long as there is enough free memory (including - * physical memory and swap space). Therefore, the amount of memory to be - * used is either the limit imposed by the user during mount time or the - * amount of available memory, whichever is lower. To avoid consuming all - * the memory for a given mount point, the system will always reserve a - * minimum of TMPFS_PAGES_RESERVED pages, which is also taken into account - * by this macro (see above). */ static __inline size_t -TMPFS_PAGES_MAX(struct tmpfs_mount *tmp) +tmpfs_pages_used(struct tmpfs_mount *tmp) { - size_t freepages; - - freepages = tmpfs_mem_info(); - freepages -= freepages < TMPFS_PAGES_RESERVED ? - freepages : TMPFS_PAGES_RESERVED; + const size_t node_size = sizeof(struct tmpfs_node) + + sizeof(struct tmpfs_dirent); + size_t meta_pages; - return MIN(tmp->tm_pages_max, freepages + tmp->tm_pages_used); + meta_pages = howmany((uintmax_t)tmp->tm_nodes_inuse * node_size, + PAGE_SIZE); + return (meta_pages + tmp->tm_pages_used); } -/* Returns the available space for the given file system. */ -#define TMPFS_META_PAGES(tmp) (howmany((tmp)->tm_nodes_inuse * (sizeof(struct tmpfs_node) \ - + sizeof(struct tmpfs_dirent)), PAGE_SIZE)) -#define TMPFS_FILE_PAGES(tmp) ((tmp)->tm_pages_used) - -#define TMPFS_PAGES_AVAIL(tmp) (TMPFS_PAGES_MAX(tmp) > \ - TMPFS_META_PAGES(tmp)+TMPFS_FILE_PAGES(tmp)? \ - TMPFS_PAGES_MAX(tmp) - TMPFS_META_PAGES(tmp) \ - - TMPFS_FILE_PAGES(tmp):0) - #endif /* --------------------------------------------------------------------- */ diff --git a/sys/fs/tmpfs/tmpfs_subr.c b/sys/fs/tmpfs/tmpfs_subr.c index 84a2038..259e205 100644 --- a/sys/fs/tmpfs/tmpfs_subr.c +++ b/sys/fs/tmpfs/tmpfs_subr.c @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -55,6 +56,60 @@ __FBSDID("$FreeBSD$"); #include #include +static long tmpfs_swap_reserved = TMPFS_SWAP_MINRESERVED * 2; + +SYSCTL_NODE(_vfs, OID_AUTO, tmpfs, CTLFLAG_RW, 0, "tmpfs memory file system"); + +static int +sysctl_swap_reserved(SYSCTL_HANDLER_ARGS) +{ + int error; + long pages, bytes; + + pages = *(long *)arg1; + bytes = pages * PAGE_SIZE; + + error = sysctl_handle_long(oidp, &bytes, 0, req); + if (error || !req->newptr) + return (error); + + pages = bytes / PAGE_SIZE; + if (pages < TMPFS_SWAP_MINRESERVED) + return (EINVAL); + + *(long *)arg1 = pages; + return (0); +} + +SYSCTL_PROC(_vfs_tmpfs, OID_AUTO, swap_reserved, CTLTYPE_LONG|CTLFLAG_RW, + &tmpfs_swap_reserved, 0, sysctl_swap_reserved, "L", "reserved swap space"); + +static __inline size_t +tmpfs_pages_avail(struct tmpfs_mount *tmp, size_t req_pages) +{ + vm_ooffset_t avail; + + if (tmpfs_pages_max(tmp) < tmpfs_pages_used(tmp) + req_pages) + return (0); + + if (!vm_page_count_target()) + return (1); + + /* + * Fail if pagedaemon wasn't able to free desired number of pages and + * we are running out of swap. + */ + avail = swap_pager_avail - vm_paging_target() - req_pages; + if (avail < tmpfs_swap_reserved) { /* avail is signed */ + printf("tmpfs: low memory: available %jd, " + "paging target %d, requested %zd\n", + (intmax_t)swap_pager_avail, vm_paging_target(), req_pages); + return (0); + } + + return (1); +} + /* --------------------------------------------------------------------- */ /* @@ -95,6 +150,8 @@ tmpfs_alloc_node(struct tmpfs_mount *tmp, enum vtype type, if (tmp->tm_nodes_inuse >= tmp->tm_nodes_max) return (ENOSPC); + if (tmpfs_pages_avail(tmp, 1) == 0) + return (ENOSPC); nnode = (struct tmpfs_node *)uma_zalloc_arg( tmp->tm_node_pool, tmp, M_WAITOK); @@ -905,7 +962,7 @@ tmpfs_reg_resize(struct vnode *vp, off_t newsize) newpages = round_page(newsize) / PAGE_SIZE; if (newpages > oldpages && - newpages - oldpages > TMPFS_PAGES_AVAIL(tmp)) { + tmpfs_pages_avail(tmp, newpages - oldpages) == 0) { error = ENOSPC; goto out; } diff --git a/sys/fs/tmpfs/tmpfs_vfsops.c b/sys/fs/tmpfs/tmpfs_vfsops.c index 356be5e..128200f 100644 --- a/sys/fs/tmpfs/tmpfs_vfsops.c +++ b/sys/fs/tmpfs/tmpfs_vfsops.c @@ -129,14 +129,14 @@ tmpfs_node_fini(void *mem, int size) static int tmpfs_mount(struct mount *mp) { + const size_t nodes_per_page = howmany(PAGE_SIZE, + sizeof(struct tmpfs_dirent) + sizeof(struct tmpfs_node)); struct tmpfs_mount *tmp; struct tmpfs_node *root; - size_t pages; - uint32_t nodes; int error; /* Size counters. */ - u_int nodes_max; - u_quad_t size_max, maxfilesize; + u_quad_t pages; + u_quad_t nodes_max, size_max, maxfilesize; /* Root node attributes. */ uid_t root_uid; @@ -173,7 +173,7 @@ tmpfs_mount(struct mount *mp) if (mp->mnt_cred->cr_ruid != 0 || vfs_scanopt(mp->mnt_optnew, "mode", "%ho", &root_mode) != 1) root_mode = va.va_mode; - if (vfs_scanopt(mp->mnt_optnew, "inodes", "%u", &nodes_max) != 1) + if (vfs_scanopt(mp->mnt_optnew, "inodes", "%qu", &nodes_max) != 1) nodes_max = 0; if (vfs_scanopt(mp->mnt_optnew, "size", "%qu", &size_max) != 1) size_max = 0; @@ -181,38 +181,49 @@ tmpfs_mount(struct mount *mp) &maxfilesize) != 1) maxfilesize = 0; - /* Do not allow mounts if we do not have enough memory to preserve - * the minimum reserved pages. */ - if (tmpfs_mem_info() < TMPFS_PAGES_RESERVED) + /* + * XXX Deny mounts if pagedaemon wasn't able to recovery desired + * number of pages. + */ + if (vm_page_count_target()) return ENOSPC; /* Get the maximum number of memory pages this file system is * allowed to use, based on the maximum size the user passed in - * the mount structure. A value of zero is treated as if the - * maximum available space was requested. */ - if (size_max < PAGE_SIZE || size_max > SIZE_MAX - PAGE_SIZE) - pages = SIZE_MAX; + * the mount structure. Use half of RAM by default. */ + if (size_max < PAGE_SIZE*4 || size_max > SIZE_MAX - PAGE_SIZE) + pages = cnt.v_page_count / 2; else pages = howmany(size_max, PAGE_SIZE); MPASS(pages > 0); + MPASS(pages < SIZE_MAX); + + if (pages < SIZE_MAX / PAGE_SIZE) + size_max = pages * PAGE_SIZE; + else + size_max = SIZE_MAX; if (nodes_max <= 3) { - if (pages > UINT32_MAX - 3) - nodes = UINT32_MAX; + if (pages < UINT32_MAX / nodes_per_page) + nodes_max = pages * nodes_per_page; else - nodes = pages + 3; - } else - nodes = nodes_max; - MPASS(nodes >= 3); + nodes_max = UINT32_MAX; + } + if (nodes_max > UINT32_MAX) + nodes_max = UINT32_MAX; + MPASS(nodes_max >= 3); + + if (maxfilesize < PAGE_SIZE || maxfilesize > size_max) + maxfilesize = size_max; /* Allocate the tmpfs mount structure and fill it. */ tmp = (struct tmpfs_mount *)malloc(sizeof(struct tmpfs_mount), M_TMPFSMNT, M_WAITOK | M_ZERO); mtx_init(&tmp->allnode_lock, "tmpfs allnode lock", NULL, MTX_DEF); - tmp->tm_nodes_max = nodes; + tmp->tm_nodes_max = nodes_max; tmp->tm_nodes_inuse = 0; - tmp->tm_maxfilesize = maxfilesize > 0 ? maxfilesize : UINT64_MAX; + tmp->tm_maxfilesize = maxfilesize; LIST_INIT(&tmp->tm_nodes_used); tmp->tm_pages_max = pages; @@ -381,22 +392,23 @@ tmpfs_fhtovp(struct mount *mp, struct fid *fhp, struct vnode **vpp) static int tmpfs_statfs(struct mount *mp, struct statfs *sbp) { - fsfilcnt_t freenodes; struct tmpfs_mount *tmp; + size_t used; tmp = VFS_TO_TMPFS(mp); sbp->f_iosize = PAGE_SIZE; sbp->f_bsize = PAGE_SIZE; - sbp->f_blocks = TMPFS_PAGES_MAX(tmp); - sbp->f_bavail = sbp->f_bfree = TMPFS_PAGES_AVAIL(tmp); - - freenodes = MIN(tmp->tm_nodes_max - tmp->tm_nodes_inuse, - TMPFS_PAGES_AVAIL(tmp) * PAGE_SIZE / sizeof(struct tmpfs_node)); - - sbp->f_files = freenodes + tmp->tm_nodes_inuse; - sbp->f_ffree = freenodes; + sbp->f_blocks = tmpfs_pages_max(tmp); + used = tmpfs_pages_used(tmp); + if (tmpfs_pages_max(tmp) <= used) + sbp->f_bavail = 0; + else + sbp->f_bavail = tmpfs_pages_max(tmp) - used; + sbp->f_bfree = sbp->f_bavail; + sbp->f_files = tmp->tm_nodes_max; + sbp->f_ffree = tmp->tm_nodes_max - tmp->tm_nodes_inuse; /* sbp->f_owner = tmp->tn_uid; */ return 0; --IS0zKkzwUGydFO0o-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 10 16:56: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 2FBFC106566B; Thu, 10 Feb 2011 16:56:51 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 582D98FC14; Thu, 10 Feb 2011 16:56:50 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 4A826E76A8; Thu, 10 Feb 2011 16:56:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=pAvIZN0EdlMD S6SycAio4YvY9DY=; b=Nmgxyjb93vt+qWJ+vmWfjwu8uywxWY6Vs/VjLtREeE3U rLp2EWfCihLxUSJNvPGRWD0BRHD35Xy+QQQwSSj8MaVaEXPPUG1zNk0fSZOHsaKZ Qi4atO2j/s+YwoI6CF+bMHWXysJw9cIObv/hjfJwA3gRZgkPv1KiuKZGi1s2A24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=PGDVpN xkvXMIUP3LAXqq6TFZmwnjxyY5FVC/vGIiR4COGUCNNK7v4e+Fz1TJ9j3lBn4L3T esgIzLIoLgVJdi97PKn35CP6a6ifHMFNPRwjfH5wjSxuBoZvjxnsrRejC6HgMBgT 8WBXCbE1RedW7UkLSEFne7koxE7h2BBzlDDFY= Received: from unknown (client-86-23-69-78.brhm.adsl.virginmedia.com [86.23.69.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 12CCEE7621; Thu, 10 Feb 2011 16:56:44 +0000 (GMT) Date: Thu, 10 Feb 2011 16:56:30 +0000 From: Bruce Cran To: Attila Nagy Message-ID: <20110210165630.00000ee8@unknown> In-Reply-To: <4D36B85B.8070201@fsn.hu> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable , Jeremy Chadwick Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2011 16:56:51 -0000 On Wed, 19 Jan 2011 11:09:31 +0100 Attila Nagy wrote: > On 01/19/11 09:46, Jeremy Chadwick wrote: > > On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: > >> I first noticed this problem on machines with more memory (32GB > >> eg.), but now it happens on 4G machines too: > >> tmpfs 0B 0B 0B > >> 100% /tmp > >> FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan > >> 8 22:11:54 CET 2011 > >> > >> Maybe it's related, that I use zfs on these machines... > >> > >> Sometimes it grows and shrinks, but generally there is no space > >> even for a small file, or a socket to create. > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.html > > > Oh crap. :( > > I hope somebody can find the time to look into this, it's pretty > annoying... It's also listed as a bug on OpenSolaris: http://bugs.opensolaris.org/bugdatabase/view_bug.do;?bug_id=6804661 -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Thu Feb 10 17:27: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 60270106564A; Thu, 10 Feb 2011 17:27:01 +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 B42D08FC14; Thu, 10 Feb 2011 17:26:59 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id C5DF472A8DB; Thu, 10 Feb 2011 18:26:57 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000063, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 13.1730] X-CRM114-CacheID: sfid-20110210_18265_4C20929E X-CRM114-Status: Good ( pR: 13.1730 ) X-Spambayes-Classification: ham; 0.00 Message-ID: <4D541FE0.6090205@fsn.hu> Date: Thu, 10 Feb 2011 18:26: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: Bruce Cran References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110210165630.00000ee8@unknown> In-Reply-To: <20110210165630.00000ee8@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable , Jeremy Chadwick Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2011 17:27:01 -0000 On 02/10/2011 05:56 PM, Bruce Cran wrote: > On Wed, 19 Jan 2011 11:09:31 +0100 > Attila Nagy wrote: > >> On 01/19/11 09:46, Jeremy Chadwick wrote: >>> On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: >>>> I first noticed this problem on machines with more memory (32GB >>>> eg.), but now it happens on 4G machines too: >>>> tmpfs 0B 0B 0B >>>> 100% /tmp >>>> FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan >>>> 8 22:11:54 CET 2011 >>>> >>>> Maybe it's related, that I use zfs on these machines... >>>> >>>> Sometimes it grows and shrinks, but generally there is no space >>>> even for a small file, or a socket to create. >>> http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.html >>> >> Oh crap. :( >> >> I hope somebody can find the time to look into this, it's pretty >> annoying... > It's also listed as a bug on OpenSolaris: > http://bugs.opensolaris.org/bugdatabase/view_bug.do;?bug_id=6804661 > ZFS is a great innovation, which forces sysadmins to learn kernel and VM internals. :-O From owner-freebsd-stable@FreeBSD.ORG Thu Feb 10 22:47: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 3DB6E106564A for ; Thu, 10 Feb 2011 22:47:06 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id E7E7F8FC17 for ; Thu, 10 Feb 2011 22:47:05 +0000 (UTC) Received: from lonrach.keltia.net (unknown [IPv6:2a01:240:fe5c:0:d69a:20ff:fed0:3a83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id C3BA4D997 for ; Thu, 10 Feb 2011 23:47:04 +0100 (CET) Date: Thu, 10 Feb 2011 23:47:03 +0100 From: Ollivier Robert To: freebsd-stable@freebsd.org Message-ID: <20110210224703.GB57818@lonrach.keltia.net> References: <4D4F4544.3010606@csub.edu> <20110207045802.GB15568@icarus.home.lan> <4D4F8E34.7030904@FreeBSD.org> <4D4F927C.7040103@csub.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D4F927C.7040103@csub.edu> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Thu, 10 Feb 2011 23:47:04 +0100 (CET) Subject: Re: bind 9.6.2 dnssec validation bug X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2011 22:47:06 -0000 According to Russell Jackson: > Looks like I should just suck it up and start using the bind97 port. Or switch to unbound. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 11 00:24: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 BB1F1106566B for ; Fri, 11 Feb 2011 00:24:16 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id D1C738FC08 for ; Fri, 11 Feb 2011 00:24:15 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p1ANthIT029355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Feb 2011 10:25:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Fri, 11 Feb 2011 10:25:43 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Powell X-Mailer: Apple Mail (2.1082) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2011 00:24:16 -0000 On 11/02/2011, at 1:43, Mark Powell wrote: > After boot0 starts and the USB boots it displays Drive C: is disk0 = etc. for each drive. Then I can hear all the drives making noises. = Sounds like the devices are being tasted, with the spinning char. This = goes on for sometime. Often the machine hangs solid and I have to reset. = It can take 3 or 4 attempts before the OS boots. I can tell it's hung by = pressing the caps lock key. If the capslock light doesn't work I hit = reset and cross my fingers. This is before the kernel boots, correct? ie the hang occurs before any bold text is printed on the screen. Can you take a picture of where it hangs? (you will have to host it = somewhere though, as the list will reject non text attachments). I suspect it's in the loader and quite possibly it's your BIOS that is = at fault, or at the very least there is a nasty interaction with it. Is there an update for the BIOS? Does this happen on other hardware? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri Feb 11 10:21: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 9226A1065674 for ; Fri, 11 Feb 2011 10:21:49 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 70F8C8FC1A for ; Fri, 11 Feb 2011 10:21:49 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p1BALmnE098355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Feb 2011 02:21:48 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p1BALmcc098354; Fri, 11 Feb 2011 02:21:48 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA21212; Fri, 11 Feb 11 02:06:51 PST Date: Fri, 11 Feb 2011 02:05:10 -0800 From: perryh@pluto.rain.com To: roberto@keltia.freenix.fr Message-Id: <4d5509d6.Um+QX3vryKLZS5fB%perryh@pluto.rain.com> References: <4D4F4544.3010606@csub.edu> <20110207045802.GB15568@icarus.home.lan> <4D4F8E34.7030904@FreeBSD.org> <4D4F927C.7040103@csub.edu> <20110210224703.GB57818@lonrach.keltia.net> In-Reply-To: <20110210224703.GB57818@lonrach.keltia.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: bind 9.6.2 dnssec validation bug X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2011 10:21:49 -0000 Ollivier Robert wrote: > Or switch to unbound. ^^^^^^^ Cute name, but perhaps a tiny bit misleading as to the product's origin -- the first thing I thought of on seeing a name like that was the FSF. Not this time: although its development was commercially sponsored it is BSD-licensed open source. And no, I have nothing at all to do with either the product or its developers/sponsors -- this is from the press release (where I had expected to find mention of GPL). From owner-freebsd-stable@FreeBSD.ORG Fri Feb 11 10:33: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 54DE9106566C for ; Fri, 11 Feb 2011 10:33:27 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from relay0.salford.ac.uk (relay0.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id B495E8FC08 for ; Fri, 11 Feb 2011 10:33:26 +0000 (UTC) Received: (qmail 10954 invoked by uid 98); 11 Feb 2011 10:33:25 -0000 Received: from 146.87.255.121 by relay0.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.96/12665. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.037453 secs); 11 Feb 2011 10:33:25 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by relay0.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Fri, 11 Feb 2011 10:33:25 +0000 Received: (qmail 24860 invoked by uid 1002); 11 Feb 2011 10:33:23 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Feb 2011 10:33:23 -0000 Date: Fri, 11 Feb 2011 10:33:23 +0000 (GMT) From: "Mark Powell" To: Daniel O'Connor In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2011 10:33:27 -0000 On Fri, 11 Feb 2011, Daniel O'Connor wrote: > This is before the kernel boots, correct? Yep. > Can you take a picture of where it hangs? (you will have to host it > somewhere though, as the list will reject non text attachments). Here you go: http://galatea.salford.ac.uk/aix502/11022011448.jpg http://galatea.salford.ac.uk/aix502/11022011449.jpg The spinning char can seemingly be in any position when it crashes. It took 5 attempts that time to get to the beastie menu. > I suspect it's in the loader and quite possibly it's your BIOS that is > at fault, or at the very least there is a nasty interaction with it. > > Is there an update for the BIOS? Does this happen on other hardware? I suspected BIOS, that's why I was going to get a new motherboard. I've always had problems getting gptzfsboot working on this hardware and there are no more BIOS updates now. That's why I have ufs root, as it only worked intermitantly. Then I wondered what the hell was going on in the loader that took >60s and seemingly touched every drive. I assumed it was FBSD that was tasting all the drives. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford IT Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 6624 www.pgp.com for PGP key From owner-freebsd-stable@FreeBSD.ORG Fri Feb 11 11:52: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 03A29106566C for ; Fri, 11 Feb 2011 11:52:15 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 86EE08FC18 for ; Fri, 11 Feb 2011 11:52:14 +0000 (UTC) Received: by eyf6 with SMTP id 6so1289105eyf.13 for ; Fri, 11 Feb 2011 03:52:13 -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=ueZutR0IlG+DfoudZvV2+KB6ixjiy6rY925A0fe8bKs=; b=ev1Edwz5ccLBA9V6wyXdy5LKLH3AftJHkv7YPzPS9d6MQiPmzndWI3T0C0i3MHRLE4 zwd3vh7NuHRQZ27AzLSRLAWBj9E8KMGvY/0G78ty7Scf9t4YsIKBCGn2H18HpDC0eYZ+ IEIypv5u2U9bkhHiYWv0qQ85JRkE5fLKY1G9g= 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=i99HnKsGj6cs1U32ptxjBAtVa+qTUgyFjIrJULAvVdap+MJvVbsUYbYFWi+GvJPDcK v9p5QvwsVeUI7ZUZgsQs++HHboYXLr4v0ukToYhOziP0IVgNLniP17xlSl4syW+2Gds6 wyiCEZL+WwWMYk1PZtmOBDPw1LbivBDrj7S34= MIME-Version: 1.0 Received: by 10.213.16.67 with SMTP id n3mr320835eba.83.1297423763122; Fri, 11 Feb 2011 03:29:23 -0800 (PST) Received: by 10.213.22.14 with HTTP; Fri, 11 Feb 2011 03:29:23 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Feb 2011 12:29:23 +0100 Message-ID: From: Christian Walther To: Mark Powell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2011 11:52:15 -0000 Hi, On 11 February 2011 11:33, Mark Powell wrote: > On Fri, 11 Feb 2011, Daniel O'Connor wrote: [...] > =A0I suspected BIOS, that's why I was going to get a new motherboard. I'v= e > always had problems getting gptzfsboot working on this hardware and there > are no more BIOS updates now. That's why I have ufs root, as it only work= ed > intermitantly. > =A0Then I wondered what the hell was going on in the loader that took >60= s and > seemingly touched every drive. I assumed it was FBSD that was tasting all > the drives. > =A0Cheers. AFAIK if you have gptzfsboot on your drives it will probe the partitions on your drives, which can take a while. So if you suspect ZFS it might really be an option to replace gptzfsboot with gptboot. I recently changed the configuration of my home server from 1x80GiB SATA HDD (booting & /-pool) and 4x400GiB PATA HDD for zraid-Pool on geli to 2x2TiB SATA HDD with gmirrored /boot and the rest for a geli encrypted zmirror (including /). For me it feels as if it takes a few seconds longer for the loader to appear. The latter uses GPT and labels where possible. HTH Christian From owner-freebsd-stable@FreeBSD.ORG Fri Feb 11 12:17: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 CE4E11065673 for ; Fri, 11 Feb 2011 12:17:37 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id 234778FC08 for ; Fri, 11 Feb 2011 12:17:36 +0000 (UTC) Received: (qmail 14018 invoked by uid 98); 11 Feb 2011 12:17:35 +0000 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.96/12665. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.036104 secs); 11 Feb 2011 12:17:35 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Fri, 11 Feb 2011 12:17:35 +0000 Received: (qmail 38262 invoked by uid 1002); 11 Feb 2011 12:17:33 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Feb 2011 12:17:33 -0000 Date: Fri, 11 Feb 2011 12:17:33 +0000 (GMT) From: "Mark Powell" To: Christian Walther In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2011 12:17:37 -0000 On Fri, 11 Feb 2011, Christian Walther wrote: > AFAIK if you have gptzfsboot on your drives it will probe the > partitions on your drives, which can take a while. So if you suspect > ZFS it might really be an option to replace gptzfsboot with gptboot. I have ufs / so isn't /boot/boot (loaded from slice start) in operation during this crash? Thanks. -- Mark Powell - UNIX System Administrator - The University of Salford IT Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 6624 www.pgp.com for PGP key From owner-freebsd-stable@FreeBSD.ORG Fri Feb 11 12:40: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 9B8F71065670 for ; Fri, 11 Feb 2011 12:40:04 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id F25348FC13 for ; Fri, 11 Feb 2011 12:40:03 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-198-229.lns6.adl6.internode.on.net [203.122.198.229]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p1BCe0MX077675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Feb 2011 23:10:01 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Fri, 11 Feb 2011 23:09:59 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Powell X-Mailer: Apple Mail (2.1082) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2011 12:40:04 -0000 On 11/02/2011, at 21:03, Mark Powell wrote: >> Can you take a picture of where it hangs? (you will have to host it = somewhere though, as the list will reject non text attachments). >=20 > Here you go: >=20 > http://galatea.salford.ac.uk/aix502/11022011448.jpg > http://galatea.salford.ac.uk/aix502/11022011449.jpg >=20 > The spinning char can seemingly be in any position when it crashes. = It took 5 attempts that time to get to the beastie menu. OK.. unfortunately not really much help except confirming that it is in = the BIOS/loader somewhere.. >> Is there an update for the BIOS? Does this happen on other hardware? >=20 > I suspected BIOS, that's why I was going to get a new motherboard. = I've always had problems getting gptzfsboot working on this hardware and = there are no more BIOS updates now. That's why I have ufs root, as it = only worked intermitantly. > Then I wondered what the hell was going on in the loader that took = >60s and seemingly touched every drive. I assumed it was FBSD that was = tasting all the drives. I believe the loader does look at the drives the BIOS presents to it, = certainly at the very least it tries to find something to boot off :) However, even if it is looking on every disk for partitions it should = only take a second or so (unless one of the drives is broken I suppose). I have seen BIOSen not boot reliably when external RAID cards are = present.. Generally their quality is quite variable :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri Feb 11 17:48:08 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 57E1F1065672 for ; Fri, 11 Feb 2011 17:48:08 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id EB0538FC13 for ; Fri, 11 Feb 2011 17:48:07 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id 860213985D; Fri, 11 Feb 2011 18:31:45 +0100 (CET) Date: Fri, 11 Feb 2011 18:31:45 +0100 From: Victor Balada Diaz To: stable@freebsd.org Message-ID: <20110211173145.GY1341@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: FreeBSD 8.2-RC3 missing documentation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2011 17:48:08 -0000 Hello, Testing FreeBSD 8.2-RC3 i've seen that documentation with regards to daily_status_zfs_enable in periodic.conf(5) is missing. Something like this could be added: (bool) Set to "YES" if you want to run zpool status -x to check for broken ZFS pools. Regards. Victor. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 11 19:40: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 1D64C106566B for ; Fri, 11 Feb 2011 19:40:25 +0000 (UTC) (envelope-from faber@isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id EFF798FC15 for ; Fri, 11 Feb 2011 19:40:24 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id p1BJCgkv087216 for ; Fri, 11 Feb 2011 11:12:42 -0800 (PST) (envelope-from faber@isi.edu) Date: Fri, 11 Feb 2011 11:12:33 -0800 From: Ted Faber To: freebsd-stable@freebsd.org Message-ID: <20110211191232.GA2073@zod.isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline X-url: http://www.isi.edu/~faber User-Agent: Mutt/1.5.21 (2010-09-15) Subject: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2011 19:40:25 -0000 --NDin8bjvE/0mNLFQ Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable For the last couple weeks (maybe more) I've been having an intermittent problem on my Thinkpad T42 where exiting X causes my screen to lock up and the system seems to stop doing anything. Lately it's happening about every 3rd time. The usual failure mode is that I select shutdown from the gnome menu and it logs out with the console showing (text mode), but non responsive. The disk LED lights intermittently, as can the LAN LED (though sometimes it comes on solid). Sometimes it sort of shakes itself awake after a minute or so, but often the shutdown doesn't complete and I have to force a power cycle and fsck everything. I don't get anything useful in /var/log/messages I run a recent -STABLE=20 $ uname -a FreeBSD praxis.lunabase.org 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #62: Sun = Feb 6 18:02:17 PST 2011 root@praxis.lunabase.org:/usr/obj/usr/src/sys/GENE= RIC i386 I've attached a verbose boot dmesg and my xorg.conf, and the /var/log/Xorg.0.log from a login.=20 Any help would be great. --=20 http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dmesg Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2011 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-PRERELEASE #62: Sun Feb 6 18:02:17 PST 2011 root@praxis.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 Preloaded elf kernel "/boot/kernel/kernel" at 0xc1055000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc10551a8. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc1055254. Preloaded elf module "/boot/kernel/sound.ko" at 0xc1055300. Preloaded elf module "/boot/kernel/acpi_ibm.ko" at 0xc10553ac. Preloaded elf module "/boot/modules/cuse4bsd.ko" at 0xc105545c. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1698565951 Hz CPU: Intel(R) Pentium(R) M processor 1.70GHz (1698.57-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6d6 Family =3D 6 Model =3D d Stepp= ing =3D 6 Features=3D0xafe9f9bf Features2=3D0x180 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size real memory =3D 1610612736 (1536 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001426000 - 0x000000005e412fff, 1560203264 bytes (380909 pages) avail memory =3D 1558847488 (1486 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6d20 bios32: Entry =3D 0xfd750 (c00fd750) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xfd6e0+0x1f6 pnpbios: Found PnP BIOS data at 0xc00f6da0 pnpbios: Entry =3D f0000:b616 Rev =3D 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: x86bios: IVT 0x000000-0x0004ff at 0xc0000000 x86bios: SSEG 0x010000-0x01ffff at 0xe3510000 x86bios: EBDA 0x09f000-0x09ffff at 0xc009f000 x86bios: ROM 0x0a0000-0x0effff at 0xc00a0000 ULE: setup cpu 0 Cuse4BSD v0.1.13 @ /dev/cuse snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [10= 24] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_ra= te_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled VESA: information block 0000 56 45 53 41 00 02 00 01 00 02 01 00 00 00 22 00 0010 00 02 ff 01 00 01 19 01 00 02 2f 01 00 02 34 01 0020 00 02 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 0030 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 0040 b2 01 b3 01 b4 01 b5 01 b6 01 c2 01 c3 01 c4 01 0050 c5 01 c6 01 00 01 83 01 84 01 85 01 86 01 01 01 0060 10 01 11 01 12 01 21 01 03 01 13 01 14 01 15 01 0070 22 01 05 01 16 01 17 01 18 01 23 01 07 01 19 01 0080 1a 01 1b 01 24 01 40 01 41 01 42 01 43 01 44 01 0090 72 01 73 01 74 01 75 01 76 01 ff ff 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 41 54 49 20 4d 4f 42 49 4c 49 54 59 20 52 41 44 0110 45 4f 4e 20 37 35 30 30 00 41 54 49 20 54 65 63 0120 68 6e 6f 6c 6f 67 69 65 73 20 49 6e 63 2e 00 50 0130 37 20 20 00 30 31 2e 30 30 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 60 mode(s) found VESA: v2.0, 32704k memory, flags:0x1, mode table:0xc4ffe022 (2000022) VESA: ATI MOBILITY RADEON 7500 VESA: ATI Technologies Inc. P7 01.00 hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 ACPI: RSDP 0xf6d70 00024 (v02 IBM ) ACPI: XSDT 0x5ff6a672 0004C (v01 IBM TP-1R 00003230 LTP 00000000) ACPI: FACP 0x5ff6a700 000F4 (v03 IBM TP-1R 00003230 IBM 00000001) ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20101013/tbfadt-62= 5) ACPI Warning: Optional field Gpe1Block has zero address or length: 0x000000= 000000102C/0x0 (20101013/tbfadt-655) ACPI: DSDT 0x5ff6a8e7 0C530 (v01 IBM TP-1R 00003230 MSFT 0100000E) ACPI: FACS 0x5ff78000 00040 ACPI: SSDT 0x5ff6a8b4 00033 (v01 IBM TP-1R 00003230 MSFT 0100000E) ACPI: ECDT 0x5ff76e17 00052 (v01 IBM TP-1R 00003230 IBM 00000001) ACPI: TCPA 0x5ff76e69 00032 (v01 IBM TP-1R 00003230 PTL 00000001) ACPI: BOOT 0x5ff76fd8 00028 (v01 IBM TP-1R 00003230 LTP 00000001) acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000f904 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D33408086) pcibios: BIOS version 2.10 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc4cb9000 pa 0x1000 atpic: Programming IRQ9 as level/low acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 5ff00000 (3) failed ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 9 10 11 Validation 0 5 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.29.INTA at func 0: 11 ACPI: Found matching pin for 0.29.INTB at func 1: 11 ACPI: Found matching pin for 0.29.INTC at func 2: 11 ACPI: Found matching pin for 0.29.INTD at func 7: 11 ACPI: Found matching pin for 0.31.INTA at func 1: 255 ACPI: Found matching pin for 0.31.INTB at func 3: 5 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x3340, revid=3D0x03 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, ena= bled found-> vendor=3D0x8086, dev=3D0x3341, revid=3D0x03 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x60 (2880 ns), mingnt=3D0x0c (3000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24c2, revid=3D0x01 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 map[20]: type I/O Port, range 32, base 0x1800, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.LNKA:0) pcib0: slot 29 INTA routed to irq 11 via \\_SB_.LNKA unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1800 found-> vendor=3D0x8086, dev=3D0x24c4, revid=3D0x01 domain=3D0, bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.LNKD:0) pcib0: slot 29 INTB routed to irq 11 via \\_SB_.LNKD unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 found-> vendor=3D0x8086, dev=3D0x24c7, revid=3D0x01 domain=3D0, bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.LNKC:0) pcib0: slot 29 INTC routed to irq 11 via \\_SB_.LNKC unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 found-> vendor=3D0x8086, dev=3D0x24cd, revid=3D0x01 domain=3D0, bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xc0000000, size 10, enabled pcib0: matched entry for 0.29.INTD (src \\_SB_.LNKH:0) pcib0: slot 29 INTD routed to irq 11 via \\_SB_.LNKH unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xc0000000 found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0x81 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x8080, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24cc, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24ca, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 map[20]: type I/O Port, range 32, base 0x1860, size 4, enabled map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=3D0x8086, dev=3D0x24c3, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D3 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0001, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D5 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 5 via \\_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x24c5, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D5 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D5 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x1c00, size 8, enabled map[14]: type I/O Port, range 32, base 0x18c0, size 6, enabled map[18]: type Memory, range 32, base 0xc0000c00, size 9, enabled map[1c]: type Memory, range 32, base 0xc0000800, size 8, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 5 via \\_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x24c6, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D6 class=3D07-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D5 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x2400, size 8, enabled map[14]: type I/O Port, range 32, base 0x2000, size 7, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 5 via \\_SB_.LNKB agp0: on hostb0 hostb0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xd0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xc0100000-0xc01fffff pcib1: prefetched decode 0xe0000000-0xe7ffffff ACPI: Found matching pin for 1.0.INTA at func 0: 11 pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x1002, dev=3D0x4c57, revid=3D0x00 domain=3D0, bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0387, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x42 (1980 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 27, ena= bled pcib1: requested memory range 0xe0000000-0xe7ffffff: good map[14]: type I/O Port, range 32, base 0x3000, size 8, enabled pcib1: requested I/O range 0x3000-0x30ff: in range map[18]: type Memory, range 32, base 0xc0100000, size 16, enabled pcib1: requested memory range 0xc0100000-0xc010ffff: good pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \\_SB_.LNKA vgapci0: port 0x3000-0x30ff mem 0xe0000000-0xe7fff= fff,0xc0100000-0xc010ffff irq 11 at device 0.0 on pci1 uhci0: port 0x1800-0x181f irq 1= 1 at device 29.0 on pci0 uhci0: [MPSAFE] uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1820-0x183f irq 1= 1 at device 29.1 on pci0 uhci1: [MPSAFE] uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1840-0x185f irq 1= 1 at device 29.2 on pci0 uhci2: [MPSAFE] uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xc0000000-0xc0000= 3ff irq 11 at device 29.7 on pci0 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib2: at device 30.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 8 pcib2: I/O decode 0x4000-0x8fff pcib2: memory decode 0xc0200000-0xcfffffff pcib2: prefetched decode 0xe8000000-0xefffffff pcib2: Subtractively decoded bridge. ACPI: Found matching pin for 2.0.INTA at func 0: 11 ACPI: Found matching pin for 2.0.INTB at func 1: 5 ACPI: Found matching pin for 2.1.INTA at func 0: 11 ACPI: Found matching pin for 2.2.INTA at func 0: 11 pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 found-> vendor=3D0x104c, dev=3D0xac46, revid=3D0x01 domain=3D0, bus=3D2, slot=3D0, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xb0000000, size 12, enabled pcib2: requested memory range 0xb0000000-0xb0000fff: good pcib2: matched entry for 2.0.INTA (src \\_SB_.LNKA:0) pcib2: slot 0 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=3D0x104c, dev=3D0xac46, revid=3D0x01 domain=3D0, bus=3D2, slot=3D0, func=3D1 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Db, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xb1000000, size 12, enabled pcib2: requested memory range 0xb1000000-0xb1000fff: good pcib2: matched entry for 2.0.INTB (src \\_SB_.LNKB:0) pcib2: slot 0 INTB routed to irq 5 via \\_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x101e, revid=3D0x03 domain=3D0, bus=3D2, slot=3D1, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xc0240000, size 17, enabled pcib2: requested memory range 0xc0240000-0xc025ffff: good map[14]: type Memory, range 32, base 0xc0200000, size 16, enabled pcib2: requested memory range 0xc0200000-0xc020ffff: good map[18]: type I/O Port, range 32, base 0x8000, size 6, enabled pcib2: requested I/O range 0x8000-0x803f: in range pcib2: matched entry for 2.1.INTA (src \\_SB_.LNKA:0) pcib2: slot 1 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=3D0x168c, dev=3D0x1014, revid=3D0x01 domain=3D0, bus=3D2, slot=3D2, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0116, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0x50 (2400 ns), mingnt=3D0x0a (2500 ns), maxlat=3D0x1c (7000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xc0210000, size 16, enabled pcib2: requested memory range 0xc0210000-0xc021ffff: good pcib2: matched entry for 2.2.INTA (src \\_SB_.LNKC:0) pcib2: slot 2 INTA routed to irq 11 via \\_SB_.LNKC cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 o= n pci2 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xb0000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xac46104c 0x02100107 0x06070001 0x00824008=20 0x10: 0xb0000000 0x020000a0 0xb0050302 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc=20 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b=20 0x40: 0x05521014 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x0840d071 0x040a0000 0x000f0000 0x01d21b22=20 0x90: 0x416402c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 cbb1: mem 0xb1000000-0xb1000fff irq 5 at device 0.1 on= pci2 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xb1000000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: [FILTER] cbb1: PCI Configuration space: 0x00: 0xac46104c 0x02100107 0x06070001 0x00824008=20 0x10: 0xb1000000 0x020000a0 0xb0080602 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc=20 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400205=20 0x40: 0x05521014 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x0840d071 0x040a0000 0x000f0000 0x01d21b22=20 0x90: 0x416402c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 em0: port 0x8000-0x803f= mem 0xc0240000-0xc025ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pc= i2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xc0240000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0x8000 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:11:25:af:f8:9b ath0: mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xc0210000 ath0: [MPSAFE] ath0: [ITHREAD] ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp= s 36Mbps 48Mbps 54Mbps ath0: AR5212 mac 5.6 RF5111 phy 4.1 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x1860-0x186f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1860 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x10000 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xc0000c0= 0-0xc0000dff,0xc0000800-0xc00008ff irq 5 at device 31.5 on pci0 pcm0: Reserved 0x200 bytes for rid 0x18 type 3 at 0xc0000c00 pcm0: Reserved 0x100 bytes for rid 0x1c type 3 at 0xc0000800 pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: pcm0: Codec features headphone, 20 bit DAC, 5 bit master volume, no 3D Ster= eo Enhancement pcm0: Primary codec extended features variable rate PCM, AMAP, reserved 4 pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: clone manager: deadline=3D750ms flags=3D0x8000001e pcm0: sndbuf_setmap 2140000, 4000; 0xe553f000 -> 2140000 pcm0: sndbuf_setmap 2144000, 4000; 0xe5543000 -> 2144000 pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ppc0: using extended I/O port range battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 1: ioport 0x1c00 alloc failed ex_isa_identify() pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0x= d1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices est0: on cpu0 p4tcc0: on cpu0 Device configuration finished. procfs registered Timecounter "TSC" frequency 1698565951 Hz quality 800 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. ata0: Identifying devices: 00000001 ata0: New devices: 00000001 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 ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D80 wire batterad0: setting UDMA100 y0: battery initialization startad0: 30560MB at ata0= -master UDMA100=20 ad0: 62586880 sectors [62090C/16H/63S] 1 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: Intel check1 failed acpi_acad0: acline initialization startad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1: Identifying devices: 00010000 ata1: New devices: 00010000 ata1-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA33 cable=3D40 wire 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 acd0: setting UDMA33 battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times GEOM: ad0s1: geometry does not match label (255h,63s !=3D 16h,63s). acd0: CDRW drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UD= MA33=20 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: measured ac97 link rate at 48006 Hz, will use 48000 Hz ATA PseudoRAID loaded Root mount waiting for: usbus3 usbus2 usbus1 usbus0 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 Trying to mount root from ufs:/dev/label/root start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: 00:05:4e:48:a4:d3 acd0: FAILURE - ATA_IDENTIFY status=3D51 error=3D4 LBA=3D0 fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 splash: image decoder found: green_saver drm0: on vgapci0 vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xc0100000 info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: Setting AGP v2 mode 4 info: [drm] Setting GART location based on new memory map info: [drm] Loading R100 Microcode info: [drm] writeback test succeeded in 2 usecs drm0: [MPSAFE] drm0: [ITHREAD] wlan0: link state changed to UP ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwar= ding disabled, default to deny, logging disabled ipfw0: bpf attached wlan0: link state changed to DOWN wlan0: link state changed to UP --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xorg.conf" Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 # InputDevice "Mouse0" "CorePointer" # InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "ServerFlags" # Option "AutoAddDevices" "Off" # Option "AutoEnableDevices" "Off" # Option "AllowEmptyInput" "Off" EndSection Section "Files" #RgbPath "/usr/local/share/X11/rgb" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "extmod" Load "record" Load "dbe" Load "glx" Load "GLcore" Load "xtrap" Load "dri" Load "freetype" Load "type1" EndSection #Section "InputDevice" # Identifier "Keyboard0" # Driver "kbd" #EndSection #Section "InputDevice" # Identifier "Mouse0" # Driver "mouse" # Option "Protocol" "auto" # Option "Device" "/dev/sysmouse" # Option "ZAxisMapping" "4 5 6 7" #EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "Dac6Bit" # [] #Option "Dac8Bit" # [] #Option "BusType" # [] #Option "CPPIOMode" # [] #Option "CPusecTimeout" # #Option "AGPMode" # #Option "AGPFastWrite" # [] #Option "AGPSize" # #Option "GARTSize" # #Option "RingSize" # #Option "BufferSize" # #Option "EnableDepthMoves" # [] #Option "EnablePageFlip" # [] #Option "NoBackBuffer" # [] #Option "DMAForXv" # [] #Option "FBTexPercent" # #Option "DepthBits" # #Option "PCIAPERSize" # #Option "AccelDFS" # [] #Option "DDCMode" # [] #Option "IgnoreEDID" # [] #Option "DisplayPriority" # [] #Option "PanelSize" # [] #Option "ForceMinDotClock" # #Option "ColorTiling" # [] #Option "VideoKey" # #Option "RageTheatreCrystal" # #Option "RageTheatreTunerPort" # #Option "RageTheatreCompositePort" # #Option "RageTheatreSVideoPort" # #Option "TunerType" # #Option "RageTheatreMicrocPath" # #Option "RageTheatreMicrocType" # #Option "ScalerWidth" # #Option "RenderAccel" # [] #Option "SubPixelOrder" # [] #Option "ShowCache" # [] #Option "DynamicClocks" # [] #Option "VGAAccess" # [] #Option "ReverseDDC" # [] #Option "LVDSProbePLL" # [] #Option "AccelMethod" # #Option "DRI" # [] #Option "ConnectorTable" # #Option "DefaultConnectorTable" # [] #Option "DefaultTMDSPLL" # [] #Option "TVDACLoadDetect" # [] #Option "ForceTVOut" # [] #Option "TVStandard" # #Option "IgnoreLidStatus" # [] #Option "DefaultTVDACAdj" # [] #Option "Int10" # [] Identifier "Card0" Driver "radeon" VendorName "ATI Technologies Inc" BoardName "Radeon Mobility M7 LW [Radeon Mobility 7500]" BusID "PCI:1:0:0" # Option "AccelMethod" "EXA" Option "AccelMethod" "XAA" #Option "EXANoComposite" "false" #Option "FBTexPercent" "50" #Option "MigrationHeuristic" "greedy" Option "DRI" "true" Option "GARTSize" "32" Option "AGPMode" "4" Option "Colortiling" "On" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "Extensions" Option "Composite" "Enable" EndSection Section "DRI" Mode 0666 EndSection --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Xorg.0.log" Content-Transfer-Encoding: quoted-printable X.Org X Server 1.7.5 Release Date: 2010-02-16 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.2-PRERELEASE i386=20 Current Operating System: FreeBSD praxis.lunabase.org 8.2-PRERELEASE FreeBS= D 8.2-PRERELEASE #62: Sun Feb 6 18:02:17 PST 2011 root@praxis.lunabase= =2Eorg:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 16 December 2010 09:56:25AM =20 Current version of pixman: 0.18.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (=3D=3D) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 11 10:58:56 2011 (=3D=3D) Using config file: "/etc/X11/xorg.conf" (=3D=3D) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (=3D=3D) Automatically adding devices (=3D=3D) Automatically enabling devices (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) ModulePath set to "/usr/local/lib/xorg/modules" (**) Extension "Composite" is enabled (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AutoAddDevices. (II) Loader magic: 0x81def20 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0:1:0:0) 1002:4c57:1014:0530 ATI Technologies Inc Radeon Mobilit= y M7 LW [Radeon Mobility 7500] rev 0, Mem @ 0xe0000000/134217728, 0xc010000= 0/65536, I/O @ 0x00003000/256, BIOS @ 0x????????/65536 (II) "extmod" will be loaded. This was enabled by default and also specifie= d in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified i= n the config file. (II) "glx" will be loaded. This was enabled by default and also specified i= n the config file. (II) "record" will be loaded. This was enabled by default and also specifie= d in the config file. (II) "dri" will be loaded. This was enabled by default and also specified i= n the config file. (II) "dri2" will be loaded by default. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.0.0 ABI class: X.Org Server Extension, version 2.0 (=3D=3D) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "xtrap" (WW) Warning, couldn't open module xtrap (II) UnloadModule: "xtrap" (EE) Failed to load module "xtrap" (module does not exist, 0) (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so (II) Module radeon: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 6.13.2 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI FireMV 2400 3155 (PCI), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X800 VE (R420) JT (AGP), ATI Radeon X850 (R480) (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT, ATI FireGL V5200, ATI Mobility Radeon X1700, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, ATI Radeon 4800 Series, ATI Radeon HD 4850 x2, ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98, ATI Mobility RADEON HD 4870, ATI Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, ATI Mobility Radeon HD 4650, ATI Radeon RV730 (AGP), ATI Mobility Radeon HD 4670, ATI FirePro M5750, ATI Mobility Radeon HD 4670, ATI Radeon RV730 (AGP), ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830, ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740, ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI Radeon HD 4770, ATI FirePro M5750, ATI RV610, ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, ATI Mobility Radeon HD 3850, ATI Radeon HD3850, ATI Mobility Radeon HD 3850 X2, ATI RV670, ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series, ATI FirePro RG220, ATI Mobility Radeon 4330, ATI RV630, ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, ATI FireGL V3600, ATI Radeon HD 2600 LE, ATI Mobility FireGL Graphics Processor, ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200, ATI Mobility Radeon 4100, ATI Radeon HD 4290, ATI Radeon HD 4290, CYPRESS, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, AMD Firestream 9370, AMD Firestream 9350, ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series, ATI Radeon HD 5900 Series, ATI Radeon HD 5900 Series, ATI Mobility Radeon HD 5800 Series, ATI Mobility Radeon HD 5800 Series, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI Mobility Radeon HD 5800 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 5700 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5570, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI Radeon HD 5670, ATI Radeon HD 5570, ATI Radeon HD 5500 Series, REDWOOD, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon Graphics, ATI Mobility Radeon Graphics, CEDAR, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro 2270, CEDAR, ATI Radeon HD 5450, CEDAR (II) Primary Device is: PCI 01@00:00:0 (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support (II) RADEON(0): TOTO SAYS 00000000c0100000 (II) RADEON(0): MMIO registers at 0x00000000c0100000: size 64KB (II) RADEON(0): PCI bus 1 card 0 func 0 (=3D=3D) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth =3D 24 bits stored in 4 bytes (32 bpp pixmaps) (=3D=3D) RADEON(0): Default visual is TrueColor (**) RADEON(0): Option "AGPMode" "4" (**) RADEON(0): Option "GARTSize" "32" (**) RADEON(0): Option "ColorTiling" "On" (**) RADEON(0): Option "AccelMethod" "XAA" (**) RADEON(0): Option "DRI" "true" (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/local/lib/xorg/modules/libvgahw.so (II) Module vgahw: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 0.1.0 ABI class: X.Org Video Driver, version 6.0 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x= 0000 (=3D=3D) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (--) RADEON(0): Chipset: "ATI Radeon Mobility M7 LW (AGP)" (ChipID =3D 0x4c= 57) (--) RADEON(0): Linear framebuffer at 0x00000000e0000000 (II) RADEON(0): AGP card detected (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules/libint10.so (II) Module int10: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.0.0 ABI class: X.Org Video Driver, version 6.0 (II) RADEON(0): initializing int10 (=3D=3D) RADEON(0): Write-combining range (0xa0000,0x20000) was already cle= ar (=3D=3D) RADEON(0): Write-combining range (0xc0000,0x40000) was already cle= ar (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (=3D=3D) RADEON(0): Write-combining range (0x0,0x1000) was already clear (II) RADEON(0): Legacy BIOS detected drmOpenDevice: node name is /dev/dri/card0 Failed to change owner or group for file /dev/dri! 2: No such file or direc= tory Failed to change owner or group for file /dev/dri/card0! 2: No such file or= directory drmOpenDevice: open result is -1, (No such file or directory) Failed to change owner or group for file /dev/dri/card0! 2: No such file or= directory drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module ver= sion 1.31.0 (=3D=3D) RADEON(0): Page Flipping disabled (II) RADEON(0): Will try to use DMA for Xv image transfers (II) RADEON(0): Detected total video RAM=3D32768K, accessible=3D65536K (PCI= BAR=3D131072K) (--) RADEON(0): Mapped VideoRAM: 32768 kByte (64 bit DDR SDRAM) (II) RADEON(0): Color tiling enabled by default (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) RADEON(0): ref_freq: 2700, min_out_pll: 12000, max_out_pll: 35000, min= _in_pll: 40, max_in_pll: 3000, xclk: 18300, sclk: 260.000000, mclk: 183.000= 000 (II) RADEON(0): PLL parameters: rf=3D2700 rd=3D12 min=3D12000 max=3D35000; = xclk=3D18300 (II) RADEON(0): DFP table revision: 2 (II) RADEON(0): Panel ID string: 1024x768 =20 (II) RADEON(0): Panel Size from BIOS: 1024x768 (II) RADEON(0): BIOS provided dividers will be used. (WW) RADEON(0): LVDS Info: XRes: 1024, YRes: 768, DotClock: 65000 HBlank: 320, HOverPlus: 16, HSyncWidth: 136 VBlank: 38, VOverPlus: 2, VSyncWidth: 6 (II) RADEON(0): Output VGA-0 using monitor section Monitor0 (II) RADEON(0): I2C bus "VGA-0" initialized. (II) RADEON(0): Output DVI-0 has no monitor section (II) RADEON(0): I2C bus "DVI-0" initialized. (II) RADEON(0): Output LVDS has no monitor section (II) RADEON(0): Output S-video has no monitor section (II) RADEON(0): Default TV standard: NTSC (II) RADEON(0): TV standards supported by chip: NTSC PAL NTSC-J=20 (II) RADEON(0): Port0: XRANDR name: VGA-0 Connector: VGA CRT1: INTERNAL_DAC1 DDC reg: 0x60 (II) RADEON(0): Port1: XRANDR name: DVI-0 Connector: DVI-D DFP1: INTERNAL_TMDS1 DDC reg: 0x64 (II) RADEON(0): Port2: XRANDR name: LVDS Connector: LVDS LCD1: INTERNAL_LVDS DDC reg: 0x0 (II) RADEON(0): Port3: XRANDR name: S-video Connector: S-video TV1: INTERNAL_DAC2 DDC reg: 0x0 (II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 finished output detect: 0 (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 finished output detect: 1 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 finished output detect: 2 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 finished output detect: 3 finished all detect (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output VGA-0 disconnected (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): Output LVDS connected (II) RADEON(0): Output S-video disconnected (II) RADEON(0): Using exact sizes for initial modes (II) RADEON(0): Output LVDS using initial mode 1024x768 (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise sta= ted. (=3D=3D) RADEON(0): DPI set to (96, 96) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules/libfb.so (II) Module fb: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (**) RADEON(0): Using XAA acceleration architecture (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/local/lib/xorg/modules/libxaa.so (II) Module xaa: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.2.1 ABI class: X.Org Video Driver, version 6.0 (=3D=3D) RADEON(0): Assuming overlay scaler buffer width is 1536 (II) RADEON(0): No MM_TABLE found - assuming CARD is not TV-in capable. (=3D=3D) RADEON(0): Write-combining range (0x0,0x1000) was already clear (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr = 1.2 support (--) Depth 24 pixmap format is 32 bpp (II) RADEON(0): RADEONScreenInit e0000000 0 0 (=3D=3D) RADEON(0): Write-combining range (0xa0000,0x10000) was already cle= ar Entering TV Save Save TV timing tables saveTimingTables: reading timing tables TV Save done (II) RADEON(0): Dynamic Power Management Disabled (=3D=3D) RADEON(0): Using 24 bit depth buffer (II) RADEON(0): RADEONInitMemoryMap() :=20 (II) RADEON(0): mem_size : 0x04000000 (II) RADEON(0): MC_FB_LOCATION : 0xe3ffe000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (II) RADEON(0): Depth moves disabled by default (II) RADEON(0): Using 32 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 29 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1024,8191) (II) RADEON(0): Reserved area from (0,1024) to (1024,1026) (II) RADEON(0): Largest offscreen area available: 1024 x 7165 (II) RADEON(0): Will use front buffer at offset 0x0 (II) RADEON(0): Will use back buffer at offset 0x800000 (II) RADEON(0): Will use depth buffer at offset 0xc00000 (II) RADEON(0): Will use 16384 kb for textures at offset 0x1000000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEON(0): [drm] framebuffer handle =3D 0xe0000000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle =3D 0x1 (II) RADEON(0): [drm] installed DRM signal handler (**) RADEON(0): Using AGP 4x (II) RADEON(0): [agp] Mode 0x1f000207 [AGP 0x0000/0x0000; Card 0x1002/0x4c5= 7 0x1014/0x0530] (II) RADEON(0): [agp] 32768 kB allocated with handle 0xc5e155c0 (II) RADEON(0): [agp] ring handle =3D 0xd0000000 (II) RADEON(0): [agp] Ring mapped at 0x28ab0000 (II) RADEON(0): [agp] ring read ptr handle =3D 0xd0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x286ff000 (II) RADEON(0): [agp] vertex/indirect buffers handle =3D 0xd0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x2ac00000 (II) RADEON(0): [agp] GART texture map handle =3D 0xd0302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x2af02000 (II) RADEON(0): [drm] register handle =3D 0xc0100000 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): RADEONRestoreMemMapRegisters() :=20 (II) RADEON(0): MC_FB_LOCATION : 0xe3ffe000 0x1fff0000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (=3D=3D) RADEON(0): Backing store disabled (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 11 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 (WW) RADEON(0): DRI init changed memory map, adjusting ... (WW) RADEON(0): MC_FB_LOCATION was: 0xe3ffe000 is: 0xe3ffe000 (WW) RADEON(0): MC_AGP_LOCATION was: 0xffffffc0 is: 0xd1ffd000 (II) RADEON(0): RADEONRestoreMemMapRegisters() :=20 (II) RADEON(0): MC_FB_LOCATION : 0xe3ffe000 0xe3ffe000 (II) RADEON(0): MC_AGP_LOCATION : 0xd1ffd000 (II) RADEON(0): Direct rendering enabled (II) RADEON(0): Render acceleration disabled (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (=3D=3D) RADEON(0): DPMS enabled (=3D=3D) RADEON(0): Silken mouse enabled (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00402000 (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x00406000 (II) RADEON(0): Largest offscreen area available: 1024 x 7157 (II) RADEON(0): Detected Radeon Mobility M7, disabling multimedia i2c (II) Loading sub module "theatre_detect" (II) LoadModule: "theatre_detect" (II) Loading /usr/local/lib/xorg/modules/multimedia/theatre_detect_drv.so (II) Module theatre_detect: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.0.0 ABI class: X.Org Video Driver, version 6.0 (II) RADEON(0): no multimedia table present, disabling Rage Theatre. (II) RADEON(0): Set up overlay video (II) RADEON(0): Set up textured video disable primary dac disable FP1 disable TV init memmap init common init crtc1 init pll1 restore memmap (II) RADEON(0): RADEONRestoreMemMapRegisters() :=20 (II) RADEON(0): MC_FB_LOCATION : 0xe3ffe000 0xe3ffe000 (II) RADEON(0): MC_AGP_LOCATION : 0xd1ffd000 restore common restore crtc1 restore pll1 set RMX set LVDS enable LVDS disable primary dac disable FP1 disable TV (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled mess= age. (--) RandR disabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE record: RECORD extension enabled at configure time. record: This extension is known to be broken, disabling extension now.. record: http://bugs.freedesktop.org/show_bug.cgi?id=3D20500 (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) RADEON(0): Setting screen physical size to 270 x 203 (II) config/hal: Adding input device AT Keyboard (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so (II) Module kbd: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 7.0 (**) AT Keyboard: always reports core events (**) Option "Protocol" "standard" (**) AT Keyboard: Protocol: standard (**) Option "XkbRules" "base" (**) AT Keyboard: XkbRules: "base" (**) Option "XkbModel" "pc105" (**) AT Keyboard: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) AT Keyboard: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) AT Keyboard: CustomKeycodes disabled (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD) (II) config/hal: Adding input device PS/2 Mouse (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so (II) Module mouse: vendor=3D"X.Org Foundation" compiled for 1.7.5, module version =3D 1.5.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 7.0 (**) PS/2 Mouse: Device: "/dev/sysmouse" (=3D=3D) PS/2 Mouse: Protocol: "Auto" (**) PS/2 Mouse: always reports core events (**) Option "Device" "/dev/sysmouse" (=3D=3D) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 (**) PS/2 Mouse: Buttons: 9 (**) PS/2 Mouse: Sensitivity: 1 (II) XINPUT: Adding extended input device "PS/2 Mouse" (type: MOUSE) (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 (**) PS/2 Mouse: (accel) acceleration profile 0 (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is 0 (II) PS/2 Mouse: SetupAuto: protocol is SysMouse (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: LVDS, Detected Monitor Type: 2 (II) RADEON(0): Added native panel mode: 1024x768 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) 3rd Button detected: disabling emulate3Button --4Ckj6UjgE2iN1+kY-- --NDin8bjvE/0mNLFQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFNVYogaUz3f+Zf+XsRAiKEAJ9gl+jzyQef+rItT5c+kVRce60KzACg0u+1 +/I99kjwD87triG1WbWQgj4= =QTx9 -----END PGP SIGNATURE----- --NDin8bjvE/0mNLFQ-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 12 01:20: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 CDFA0106564A; Sat, 12 Feb 2011 01:20:07 +0000 (UTC) (envelope-from gleb.kurtsou@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 324A28FC0C; Sat, 12 Feb 2011 01:20:06 +0000 (UTC) Received: by fxm16 with SMTP id 16so3600751fxm.13 for ; Fri, 11 Feb 2011 17:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Fb8bH16kHkNThhn/Pr61q+0DAtrvIRJcx4eVF4dKyV8=; b=miVZIngBdZHSCNzlYoOmTIu+a6vU3K4Gh/2dL0lPK6lFvGbLyyecFdt20HQLXEo8km DgpOpWv8BJlI4qplEbojzKUk5yglNd6qIWktpwVFH/vhJi77fqi89LWejM+XWQggPVn9 rPH8WGDJRG8ZizgR/2ZZXBv6IBu9DGkYFVyH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=tMskGD0IkDWShS5DD6axoN4DFPD9EKoqUkCSaiPjlT0hVQF3l4dwMoADAqG6TFx0yP 1GydLfGknmN3IF1oK/zHmKPr4i/a9mgDjM0fqST+N5hkdlOfDSKw9qVt5BZhoQ1gAB8h iR9yf6Sg6NV5up27zTTcR2c4dPnTzKq7hn+s8= Received: by 10.223.98.200 with SMTP id r8mr514485fan.30.1297432640381; Fri, 11 Feb 2011 05:57:20 -0800 (PST) Received: from localhost ([91.187.13.237]) by mx.google.com with ESMTPS id n15sm370428fam.12.2011.02.11.05.57.18 (version=SSLv3 cipher=OTHER); Fri, 11 Feb 2011 05:57:19 -0800 (PST) Date: Fri, 11 Feb 2011 15:56:53 +0200 From: Gleb Kurtsou To: Bruce Cran Message-ID: <20110211135652.GA22733@tops> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110210165630.00000ee8@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110210165630.00000ee8@unknown> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Feb 2011 01:20:07 -0000 On (10/02/2011 16:56), Bruce Cran wrote: > On Wed, 19 Jan 2011 11:09:31 +0100 > Attila Nagy wrote: > > I hope somebody can find the time to look into this, it's pretty > > annoying... > > It's also listed as a bug on OpenSolaris: > http://bugs.opensolaris.org/bugdatabase/view_bug.do;?bug_id=6804661 Could you try my patch I've mentioned above in the thread: http://marc.info/?l=freebsd-fs&m=129735686129438&w=2 I've reproduce test scenario in OpenSolaris bug report and it worked as expected for me. System: amd64, 4GB RAM, ~5GB swap /boot/loader.conf: vm.kmem_size="6G" vfs.zfs.prefetch_disable="1" vfs.zfs.txg.timeout="5" # mount -t tmpfs -o size=$((5*1024*1024*1024)) none /mnt # dd if=/dev/zero of=test bs=1m count=$((3*1024)) # dd if=test of=/dev/zero bs=1m # dd if=test of=/dev/zero bs=1m # dd if=test of=/dev/zero bs=1m top statistics: Mem: 429M Active, 272M Inact, 2889M Wired, 96K Cache, 1328K Buf, 196M Free Swap: 5120M Total, 5120M Free ZFS seems to consume most of RAM # cp test /mnt top statistics: Mem: 2808M Active, 247M Inact, 623M Wired, 104M Cache, 1328K Buf, 5052K Free Swap: 5120M Total, 619M Used, 4501M Free, 12% Inuse ZFS cache has shrinked, swap increased, most of tmpfs remains in memory # df -h /mnt Filesystem Size Used Avail Capacity Mounted on tmpfs 5.0G 3.0G 2.0G 60% /mnt Thanks, Gleb. > > -- > Bruce Cran > _______________________________________________ > 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 Sat Feb 12 03:24: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 3CA0A106564A for ; Sat, 12 Feb 2011 03:24:30 +0000 (UTC) (envelope-from greg@bonett.org) Received: from bonett.org (bonett.org [66.249.7.150]) by mx1.freebsd.org (Postfix) with ESMTP id EA7A18FC08 for ; Sat, 12 Feb 2011 03:24:29 +0000 (UTC) Received: from [192.168.1.216] (unknown [76.91.19.169]) by bonett.org (Postfix) with ESMTPSA id 6D26C1243E1; Sat, 12 Feb 2011 03:24:28 +0000 (UTC) From: Greg Bonett To: Jeremy Chadwick In-Reply-To: <20110209092858.GA35033@icarus.home.lan> References: <1297026074.23922.8.camel@ubuntu> <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <1297143276.9417.400.camel@ubuntu> <20110208055239.GA2557@icarus.home.lan> <1297145806.9417.413.camel@ubuntu> <20110208064633.GA3367@icarus.home.lan> <1297235241.4729.35.camel@ubuntu> <20110209092858.GA35033@icarus.home.lan> Content-Type: text/plain; charset="UTF-8" Date: Fri, 11 Feb 2011 19:24:27 -0800 Message-ID: <1297481067.16594.39.camel@ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 03:24:30 -0000 Thanks for all the help. I've learned some new things, but haven't fixed the problem yet. > 1) Re-enable both CPU cores; I can't see this being responsible for the > problem. I do understand the concern over added power draw, but see > recommendation (4a) below. I re-enabled all cores but experienced a lockup while running zpool scrub. I was able to run scrub twice with 4 of 6 cores enabled without lockup. Also, when lockup occurs I'm not able to access the debugger with ctrl-alt-esc. Just to keep things straight, since I'm running geli, more cores means more io throughput during a scrub. If I'm not able to use the kernel debugger to diagnose this problem, should I disable it? Could it be a security risk? > 1) Disable the JMicron SATA controller entirely. > > 2) Disable the ATI IXP700/800 SATA controller entirely. > > 3a) Purchase a Silicon Image controller (one of the models I referenced > in my previous mail). Many places sell them, but lots of online vendors > hide or do not disclose what ASIC they're using for the controller. You > might have to look at their Driver Downloads section to find out what > actual chip is used. This is on my todo list, but as of now I'm still running the controllers on the motherboard. I should have the controller replaced by next week. > 3b) You've stated you're using one of your drives on an eSATA cable. If > you are using a SATA-to-eSATA adapter bracket[1][2], please stop > immediately and use a native eSATA port instead. > > Adapter brackets are known to cause all sorts of problems that appear as > bizarre/strange failures (xxx_DMAxx errors are quite common in this > situation), not to mention with all the internal cabling and external > cabling, a lot of the time people exceed the maximum SATA cable length > without even realising it -- it's the entire length from the SATA port > on your motherboard, to and through the adapter (good luck figuring out > how much wire is used there, to the end of the eSATA cable. Native > eSATA removes use of the shoddy adapters and also extends the maximum > cable length (from 1 metre to 2 metres), plus provides the proper amount > of power for eSATA devices (yes this matters!). Wikipedia has > details[3]. > > Silicon Image and others do make chips that offer both internal SATA and > an eSATA port on the same controller. Given your number of disks, you > might have to invest in multiple controllers. My motherboard has an eSATA port and that's what I'm using (not an extension bracket) Do you still recommend against it? I figured one fewer drive in the case would reduce the load on my PSU. > 4a) Purchase a Kill-a-Watt meter and measure exactly how much power your > entire PC draws, including on power-on (it will be a lot higher during > power-on than during idle/use, as drives spinning up draw lots of amps). > I strongly recommend the Kill-a-Watt P4600 model[4] over the P4400 model. > Based on the wattage and amperage results, you should be able to > determine if you're nearing the maximum draw of your PSU. Kill-a-Watt meter arrived today. It looks like during boot it's not exceeding 200 watts. During a zpool scrub it gets up to ~255 watts (with all cores enabled). So I don't think the problem is gross power consumption. > 4b) However, even if you're way under-draw (say, 400W), the draw may not > be the problem but instead the maximum amount of power/amperage/whatever > a single physical power cable can provide. I imagine to some degree it > depends on the gauge of wire being used; excessive use of Y-splitters to > provide more power connectors than the physical cable provides means > that you might be drawing too much across the existing gauge of cable > that runs to the PSU. I have seen setups where people have 6 hard disks > coming off of a single power cable (with Y-splitters and molex-to-SATA > power adapters) and have their drives randomly drop off the bus. Please > don't do this. Yes this seems like it could be a problem. I'll shutdown and figure out which drives are connected to which cables. Maybe with some rearranging I can even out the load. Even if I have a bunch of drives on a single cable, would a voltage drop on one cable filled with drives be enough to lockup the machine? It seems like the motherboard power would be unaffected. > A better solution might be to invest in a server-grade chassis, such as > one from Supermicro, that offers a hot-swap SATA backplane. The > backplane provides all the correct amounts of power to the maximum > number of disks that can be connected to it. Here are some cases you > can look at that[5][6][7]. Also be aware that if you're already using a > hot-swap backplane, most consumer-grade ones are complete junk and have > been known to cause strange anomalies; it's always best in those > situations to go straight from motherboard-to-drive or card-to-drive. This would be nice, but it's not in my budget right now. I'll keep it in mind for my next major upgrade. > After reviewing your SMART stats on the drive, I agree -- it looks > perfectly healthy (for a Seagate disk). Nothing wrong there. > > > > > calcru: runtime went backwards from 82 usec to 70 usec for pid 20 (flowcleaner) > > > > calcru: runtime went backwards from 363 usec to 317 usec for pid 8 (pagedaemon) > > > > calcru: runtime went backwards from 111 usec to 95 usec for pid 7 (xpt_thrd) > > > > calcru: runtime went backwards from 1892 usec to 1629 usec for pid 1 (init) > > > > calcru: runtime went backwards from 6786 usec to 6591 usec for pid 0 (kernel) > > > > > > This is a problem that has plagued FreeBSD for some time. It's usually > > > caused by EIST (est) being used, but that's on Intel platforms. AMD has > > > something similar called Cool'n'Quiet (see cpufreq(4) man page). Are > > > you running powerd(8) on this system? If so, try disabling that and see > > > if these go away. > > > > sadly, I don't know if I'm running powerd. > > ps aux | grep power gives nothing, so no I guess... > > as far as I can tell, this error is the least of my problems right now, > > but i would like to fix it. > > Yes that's an accurate ps/grep to use; powerd_enable="yes" in > /etc/rc.conf is how you make use of it. Is this recommended for desktop machines? > Could you provide output from "sysctl -a | grep freq"? That might help > shed some light on the above errors as well, but as I said, I'm not > familiar with AMD systems. > $ sysctl -a | grep freq kern.acct_chkfreq: 15 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.TSC.frequency: 3491654411 net.inet.sctp.sack_freq: 2 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 machdep.acpi_timer_freq: 3579545 machdep.tsc_freq: 3491654411 machdep.i8254_freq: 1193182 dev.cpu.0.freq: 3000 dev.cpu.0.freq_levels: 3000/19507 2625/17068 2300/14500 2012/12687 1725/10875 1600/10535 1400/9218 1200/7901 1000/6584 800/6345 700/5551 600/4758 500/3965 400/3172 300/2379 200/1586 100/793 dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.hwpstate.0.freq_settings: 3000/19507 2300/14500 1600/10535 800/6345 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 12 04:18: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 BF6CB106566C for ; Sat, 12 Feb 2011 04:18:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8E58FC0C for ; Sat, 12 Feb 2011 04:18:18 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id 6sFf1g0011c6gX85DsJJJ9; Sat, 12 Feb 2011 04:18:18 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta23.westchester.pa.mail.comcast.net with comcast id 6sJG1g00J0PUQVN3jsJHDp; Sat, 12 Feb 2011 04:18:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 213D99B422; Fri, 11 Feb 2011 20:18:15 -0800 (PST) Date: Fri, 11 Feb 2011 20:18:15 -0800 From: Jeremy Chadwick To: Greg Bonett Message-ID: <20110212041815.GA19226@icarus.home.lan> References: <20110207045501.GA15568@icarus.home.lan> <1297065041.754.12.camel@ubuntu> <20110207085537.GA20545@icarus.home.lan> <1297143276.9417.400.camel@ubuntu> <20110208055239.GA2557@icarus.home.lan> <1297145806.9417.413.camel@ubuntu> <20110208064633.GA3367@icarus.home.lan> <1297235241.4729.35.camel@ubuntu> <20110209092858.GA35033@icarus.home.lan> <1297481067.16594.39.camel@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1297481067.16594.39.camel@ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 amd64 lockup (maybe zfs or disk related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 04:18:18 -0000 On Fri, Feb 11, 2011 at 07:24:27PM -0800, Greg Bonett wrote: > Thanks for all the help. I've learned some new things, but haven't fixed > the problem yet. > > > 1) Re-enable both CPU cores; I can't see this being responsible for the > > problem. I do understand the concern over added power draw, but see > > recommendation (4a) below. > > I re-enabled all cores but experienced a lockup while running zpool > scrub. I was able to run scrub twice with 4 of 6 cores enabled without > lockup. Also, when lockup occurs I'm not able to access the debugger > with ctrl-alt-esc. Just to keep things straight, since I'm running > geli, more cores means more io throughput during a scrub. Okay, and what happens if you disable two cores and re-install the disks you removed? Does the system lock up during "zpool scrub" then? Basically I'm trying to figure out if the problem is related to having 6 cores enabled, or if it's related to having too many disks in use. If it happens in both cases (4 of 6 cores w/ all disks attached, and 6 of 6 cores w/ only some disks attached), then it's probably a motherboard or PSU issue like suspected. > If I'm not able to use the kernel debugger to diagnose this problem, > should I disable it? Could it be a security risk? Let me explain why I advocated adding the debugger to your kernel. Basically if the machine "locks up" you are supposed to try and press Ctrl-Alt-Esc to see if you drop to a db> prompt. If so, the kernel is still alive/working, and the machine actually isn't "hard locked". The debugger is not a security risk. There are only 3 ways (sans serial console, which isn't in use on your system so it doesn't apply) I know of to induce the debugger: 1) execute "sysctl debug.kdb.enter=1" as root, 2) physically press Ctrl-Alt-Esc on the VGA console, 3) crash the machine. > > 3b) You've stated you're using one of your drives on an eSATA cable. If > > you are using a SATA-to-eSATA adapter bracket[1][2], please stop > > immediately and use a native eSATA port instead. > > > > Adapter brackets are known to cause all sorts of problems that appear as > > bizarre/strange failures (xxx_DMAxx errors are quite common in this > > situation), not to mention with all the internal cabling and external > > cabling, a lot of the time people exceed the maximum SATA cable length > > without even realising it -- it's the entire length from the SATA port > > on your motherboard, to and through the adapter (good luck figuring out > > how much wire is used there, to the end of the eSATA cable. Native > > eSATA removes use of the shoddy adapters and also extends the maximum > > cable length (from 1 metre to 2 metres), plus provides the proper amount > > of power for eSATA devices (yes this matters!). Wikipedia has > > details[3]. > > > > Silicon Image and others do make chips that offer both internal SATA and > > an eSATA port on the same controller. Given your number of disks, you > > might have to invest in multiple controllers. > > My motherboard has an eSATA port and that's what I'm using (not an > extension bracket) Do you still recommend against it? I figured one > fewer drive in the case would reduce the load on my PSU. If the eSATA port is on the motherboard backplane (e.g. a port that's soldered to the motherboard), then you're fine. Be aware that the eSATA port may be connected to the JMicron controller, however, which I've already said is of questionable quality to begin with. :-) Is your eSATA enclosure/hard disk powered off of the eSATA cable, or are you using an AC adapter with it? That will determine use of additional load on the PSU. > > 4a) Purchase a Kill-a-Watt meter and measure exactly how much power your > > entire PC draws, including on power-on (it will be a lot higher during > > power-on than during idle/use, as drives spinning up draw lots of amps). > > I strongly recommend the Kill-a-Watt P4600 model[4] over the P4400 model. > > Based on the wattage and amperage results, you should be able to > > determine if you're nearing the maximum draw of your PSU. > > Kill-a-Watt meter arrived today. It looks like during boot it's not > exceeding 200 watts. During a zpool scrub it gets up to ~255 watts > (with all cores enabled). So I don't think the problem is gross power > consumption. And this is with all 6 cores enabled, AND all disks attached, during a "zpool scrub"? If so, I agree the PSU load is not a problem. Voltages and so on could be a problem, but FreeBSD's hardware monitoring support is sub-par when it comes to any system made after ~2002, so you won't get very far monitoring such in the OS. I speak the truth given that I maintain the Supermicro-specific hardware monitoring software (ports/sysutils/bsdhwmon). :-) System BIOSes provide hardware monitoring indicators (voltages, etc.), but voltages will slightly change/shift when running under an OS vs. looking at them in the BIOS. Viewing the BIOS attributes would be worthwhile to verify if, say, your 12V line is running at 10V or something absurd. Please be aware there will always be some variance on the voltages (e.g. don't expect a -5V line to return -5.000V exactly. Deviation should be expected) > > 4b) However, even if you're way under-draw (say, 400W), the draw may not > > be the problem but instead the maximum amount of power/amperage/whatever > > a single physical power cable can provide. I imagine to some degree it > > depends on the gauge of wire being used; excessive use of Y-splitters to > > provide more power connectors than the physical cable provides means > > that you might be drawing too much across the existing gauge of cable > > that runs to the PSU. I have seen setups where people have 6 hard disks > > coming off of a single power cable (with Y-splitters and molex-to-SATA > > power adapters) and have their drives randomly drop off the bus. Please > > don't do this. > > Yes this seems like it could be a problem. I'll shutdown and figure out > which drives are connected to which cables. Maybe with some rearranging > I can even out the load. Even if I have a bunch of drives on a single > cable, would a voltage drop on one cable filled with drives be enough to > lockup the machine? It seems like the motherboard power would be > unaffected. I cannot comment on this -- EE-related things (including power, voltages, amperage, etc.) are outside of my skill set, aside from "don't draw too many amps or the rack will blow". :-) As a SA, my opinion is that "weird electrical issues" can cause completely random things to happen when it comes to hardware. As stated (I think) elsewhere in my mails, the problem with issues like this is that you have to replace one piece at a time, wasting time + money in the process, until you figure out what's broken. I can't keep spending time trying to diagnose this issue for you though, I think at this point I've given you all the tips needed to investigate the root cause yourself, but it will take time/effort on your part. If at the end of the adventure you've replaced all the parts and it still happens, then something *very* weird is going on (could be a motherboard defect, or even a CPU defect). I forget if I mentioned this or not, but story time: I had a box that kept "randomly" locking up. Turns out there was a small shard of metal that had been shaved off the inside of the chassis somehow, and was blowing around inside, shorting stuff out. A different story involves a workstation I had which was behaving oddly (randomly). Once I unmounted the motherboard, I found I had accidentally left a loose motherboard mounting screw in there (!), which was probably pressed up against the motherboard and the case, likely shorting something out. Why it wasn't a consistent failure I don't know, I imagine it greatly depends on what the screw was pushed up against, and the circuitry used near/around that area. Low-level EE/hardware is seriously "black box magic voodoo" to me, while electrical engineers laugh and argue that *software* is black magic. But I disagree -- there's no "magic smoke" in software, but there *are* hardware gremlins. ;-) > > After reviewing your SMART stats on the drive, I agree -- it looks > > perfectly healthy (for a Seagate disk). Nothing wrong there. > > > > > > > calcru: runtime went backwards from 82 usec to 70 usec for pid 20 (flowcleaner) > > > > > calcru: runtime went backwards from 363 usec to 317 usec for pid 8 (pagedaemon) > > > > > calcru: runtime went backwards from 111 usec to 95 usec for pid 7 (xpt_thrd) > > > > > calcru: runtime went backwards from 1892 usec to 1629 usec for pid 1 (init) > > > > > calcru: runtime went backwards from 6786 usec to 6591 usec for pid 0 (kernel) > > > > > > > > This is a problem that has plagued FreeBSD for some time. It's usually > > > > caused by EIST (est) being used, but that's on Intel platforms. AMD has > > > > something similar called Cool'n'Quiet (see cpufreq(4) man page). Are > > > > you running powerd(8) on this system? If so, try disabling that and see > > > > if these go away. > > > > > > sadly, I don't know if I'm running powerd. > > > ps aux | grep power gives nothing, so no I guess... > > > as far as I can tell, this error is the least of my problems right now, > > > but i would like to fix it. > > > > Yes that's an accurate ps/grep to use; powerd_enable="yes" in > > /etc/rc.conf is how you make use of it. > > Is this recommended for desktop machines? Because you're trying to diagnose hardware problems or similar oddities, please do not enable powerd at this moment. Otherwise, if your system is rock solid, yes, use of powerd on machines is recommended, assuming you'd like the CPU to throttle down in frequency/speed during idle. Please keep reading for what powerd does/how it works (on a general level). The below sysctl output will help shed some light. Again, just keep in mind the below is *informative only* -- you should not go messing with this given your system instability issues. Don't add more complexity to the mix. :-) > > Could you provide output from "sysctl -a | grep freq"? That might help > > shed some light on the above errors as well, but as I said, I'm not > > familiar with AMD systems. > > > > $ sysctl -a | grep freq > kern.acct_chkfreq: 15 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.TSC.frequency: 3491654411 > net.inet.sctp.sack_freq: 2 > debug.cpufreq.verbose: 0 > debug.cpufreq.lowest: 0 > machdep.acpi_timer_freq: 3579545 > machdep.tsc_freq: 3491654411 > machdep.i8254_freq: 1193182 > dev.cpu.0.freq: 3000 > dev.cpu.0.freq_levels: 3000/19507 2625/17068 2300/14500 2012/12687 > 1725/10875 1600/10535 1400/9218 1200/7901 1000/6584 800/6345 700/5551 > 600/4758 500/3965 400/3172 300/2379 200/1586 100/793 > dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 > 5000/-1 3750/-1 2500/-1 1250/-1 > dev.cpufreq.0.%driver: cpufreq > dev.cpufreq.0.%parent: cpu0 > dev.hwpstate.0.freq_settings: 3000/19507 2300/14500 1600/10535 800/6345 The simple version of what powerd does is that it adjusts the CPU clock frequency (speed) when the machine is idle, using less power, and increases it when the machine needs more processing power. The polling interval defaults to 250ms by default, and the software works in "steps". The current clock speed of the CPU (all cores) is shown by dev.cpu.0.freq. In your case above, that's 3000MHz (3GHz). The processor supports lots of clock frequencies -- which are shown in dev.cpu.0.freq_levels. Ignore the value after the "/". If powerd was in use, your system would run at 3GHz until powerd started. Then, assuming the system wasn't under load, it would gradually decrease the clock speed: 3000MHz -> 2625MHz -> 2300MHz -> 2012MHz -> etc... (see sysctl above). When the system needed to do more CPU processing, the clock speed would increase in those increments, then settle back down again when idling. You get the idea. powerd supports setting what the minimum and maximum frequencies are, so that you don't "throttle down" or "throttle up" too much, depending on what you want. The -m and -M flags control this. E.g. "-m 1600" would result in 3000 -> 2625 -> 2300 -> 2012 -> 1725 -> 1600, where it would then stay when idle. On load, it would ramp back up gradually. However, there are multiple types of throttling (as you can see from reading the cpufreq(4) man page, labelled SUPPORTED DRIVERS). You would basically want to ensure you use the AMD-specific throttling method and not ACPI throttling. Because I'm not familiar with AMD systems, I can't comment on how to do this, but for Intel systems it's as simple as setting these in /boot/loader.conf: # Enable use of P-state CPU frequency throttling. # http://wiki.freebsd.org/TuningPowerConsumption hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" I imagine on an AMD system you'd need the last tunable, in addition to some other tunable (probably not p4tcc; not sure what AMD has). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Feb 12 06:32: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 DDD13106564A for ; Sat, 12 Feb 2011 06:32:39 +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 A37E28FC08 for ; Sat, 12 Feb 2011 06:32:39 +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 p1C6WUV0058958 for ; Fri, 11 Feb 2011 22:32:37 -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, 11 Feb 2011 22:32:37 -0800 (PST) Message-ID: <44cfde0a1632dfe8d5684c35929c3252.HRCIM@webmail.1command.com> In-Reply-To: <20110210224703.GB57818@lonrach.keltia.net> References: <4D4F4544.3010606@csub.edu> <20110207045802.GB15568@icarus.home.lan> <4D4F8E34.7030904@FreeBSD.org> <4D4F927C.7040103@csub.edu> <20110210224703.GB57818@lonrach.keltia.net> Date: Fri, 11 Feb 2011 22:32: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 Subject: Re: bind 9.6.2 dnssec validation bug X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Feb 2011 06:32:39 -0000 On Thu, February 10, 2011 2:47 pm, Ollivier Robert wrote: > According to Russell Jackson: > >> Looks like I should just suck it up and start using the bind97 port. >> > > Or switch to unbound. Unless you need/allow recursion for your internal || stealth || seconds/slaves In fact, that's the _only_ reason I haven't already switched to unbound. --Chris > > > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr > In memoriam to Ondine : http://ondine.keltia.net/ > _______________________________________________ > 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 Sat Feb 12 06:52:46 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 7D8B31065670 for ; Sat, 12 Feb 2011 06:52:46 +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 271928FC14 for ; Sat, 12 Feb 2011 06:52:45 +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 p1C6qbTQ059040 for ; Fri, 11 Feb 2011 22:52:43 -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, 11 Feb 2011 22:52:43 -0800 (PST) Message-ID: <86ce5acff788efe61ceabdffe9b194fd.HRCIM@webmail.1command.com> In-Reply-To: <20110211191232.GA2073@zod.isi.edu> References: <20110211191232.GA2073@zod.isi.edu> Date: Fri, 11 Feb 2011 22:52:43 -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 Subject: Re: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Feb 2011 06:52:46 -0000 On Fri, February 11, 2011 11:12 am, Ted Faber wrote: > For the last couple weeks (maybe more) I've been having an intermittent > problem on my Thinkpad T42 where exiting X causes my screen to lock up and the > system seems to stop doing anything. Lately it's happening about every 3rd > time. > > The usual failure mode is that I select shutdown from the gnome menu and > it logs out with the console showing (text mode), but non responsive. The disk > LED lights intermittently, as can the LAN LED (though sometimes > it comes on solid). Sometimes it sort of shakes itself awake after a minute or > so, but often the shutdown doesn't complete and I have to force a power cycle > and fsck everything. > > I don't get anything useful in /var/log/messages > > > I run a recent -STABLE > $ uname -a > FreeBSD praxis.lunabase.org 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #62: Sun Feb > 6 18:02:17 PST 2011 root@praxis.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 > > > I've attached a verbose boot dmesg and my xorg.conf, and the > /var/log/Xorg.0.log from a login. > > > Any help would be great. I noticed a potential issue in the output of your attached Xorg.conf. But as I don't have an immediate solution for that, I /will/ offer you some advice based on my experiences with recent versions of Xorg(1) on nVidia based cards. All the docs will advise the following two entries in your rc.cconf(5): hald_enable="YES" dbus_enable="YES" However, _unless_ I use the following, I will _always_ run into some sort of problem; hald_enable="NO" dbus_enable="YES" I have no idea what's going on with hald(8), but frankly, it appears nothing. Research on forums related to issues on nVidia & ATI video cards have many threads that ultimately point at issues using hald(8). Bottom line (for me anyway) has been that if I disable hald(8), I have nearly no (video related) issues. This is both on x86 && amd64 systems. HTH --Chris > > > > -- > http://www.lunabase.org/~faber > Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG > > -- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 12 09:33: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 427F11065672 for ; Sat, 12 Feb 2011 09:33:18 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id A5A1B8FC15 for ; Sat, 12 Feb 2011 09:33:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id p1C9EB7Y060116; Sat, 12 Feb 2011 12:14:11 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sat, 12 Feb 2011 12:14:11 +0300 (MSK) From: Dmitry Morozovsky To: Mark Powell In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (woozle.rinet.ru [0.0.0.0]); Sat, 12 Feb 2011 12:14:12 +0300 (MSK) Cc: freebsd-stable@freebsd.org Subject: Re: Removing all ZFS support from boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Feb 2011 09:33:18 -0000 On Fri, 11 Feb 2011, Mark Powell wrote: MP> > This is before the kernel boots, correct? MP> MP> Yep. MP> MP> > Can you take a picture of where it hangs? (you will have to host it MP> > somewhere though, as the list will reject non text attachments). MP> MP> Here you go: MP> MP> http://galatea.salford.ac.uk/aix502/11022011448.jpg MP> http://galatea.salford.ac.uk/aix502/11022011449.jpg MP> MP> The spinning char can seemingly be in any position when it crashes. It MP> took 5 attempts that time to get to the beastie menu. A friend of mine stepped into similar trouble a week or two ago. His problem disappears after updating IPMI (sic!) BIOS. Maybe it's somehow relevant to you too... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sat Feb 12 22:20: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 4BBA11065674 for ; Sat, 12 Feb 2011 22:20:56 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 00FC68FC0A for ; Sat, 12 Feb 2011 22:20:55 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id p1CMKt4Q003938; Sat, 12 Feb 2011 15:20:55 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id p1CMKseJ003935; Sat, 12 Feb 2011 15:20:55 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 12 Feb 2011 15:20:54 -0700 (MST) From: Warren Block To: Ted Faber In-Reply-To: <20110211191232.GA2073@zod.isi.edu> Message-ID: References: <20110211191232.GA2073@zod.isi.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Content-Disposition: INLINE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (wonkity.com [127.0.0.1]); Sat, 12 Feb 2011 15:20:55 -0700 (MST) Cc: freebsd-stable@freebsd.org Subject: Re: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Feb 2011 22:20:56 -0000 On Fri, 11 Feb 2011, Ted Faber wrote: > For the last couple weeks (maybe more) I've been having an intermittent > problem on my Thinkpad T42 where exiting X causes my screen to lock up > and the system seems to stop doing anything. Lately it's happening > about every 3rd time. My T42 is months out of date and needs updating, but I haven't seen that issue before. Have you made any changes to xorg-related stuff lately? There are some things in your xorg.conf Device section that might be questionable, but if it was working before...