From owner-freebsd-stable@FreeBSD.ORG Sun May 31 02:59:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 825E2106564A for ; Sun, 31 May 2009 02:59:45 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id E2CCC8FC15 for ; Sun, 31 May 2009 02:59:44 +0000 (UTC) (envelope-from louie@transsys.com) Received: from PM-G5.transsys.com (c-69-141-150-106.hsd1.nj.comcast.net [69.141.150.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 10B5D5C4B; Sat, 30 May 2009 22:59:44 -0400 (EDT) Message-Id: <17FA5EE8-40DB-46F8-AC4F-1F26E7732974@transsys.com> From: Louis Mamakos To: Dan Naumov In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 30 May 2009 22:59:42 -0400 References: <8C45E753-16F0-43AF-BD3F-D3F6A8F73B60@transsys.com> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 02:59:45 -0000 The system that I built had 5 x 72GB SCA SCSI drives. Just to keep my own sanity, I decided that I'd configure the fdisk partitioning identically across all of the drives. So that they all have a 1GB slice and and a 71GB slice. The drives all have identical capacity, so the second 71GB slice ends up the same on all of the drives. I actually end up using glabel to create a named unit of storage, so that I don't have to worry about getting the drives inserted into the right holes.. I figured that 1GB wasn't too far off for both swap partitions (3 of 'em) plus a pair mirrored to boot from. I haven't really addressed directly swapping another drive of a slightly different size, though I've spares and I could always put a larger drive in and create a slice at the right size. It looks like this, with all of the slices explicitly named with glabel: root@droid[41] # glabel status Name Status Components label/boot0 N/A da0s1 label/zpool0 N/A da0s2 label/boot1 N/A da1s1 label/zpool1 N/A da1s2 label/swap2 N/A da2s1 label/zpool2 N/A da2s2 label/swap3 N/A da3s1 label/zpool3 N/A da3s2 label/swap4 N/A da4s1 label/zpool4 N/A da4s2 And the ZFS pool references the labeled slices: root@droid[42] # zpool status pool: z state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM z ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/zpool0 ONLINE 0 0 0 label/zpool1 ONLINE 0 0 0 label/zpool2 ONLINE 0 0 0 label/zpool3 ONLINE 0 0 0 label/zpool4 ONLINE 0 0 0 errors: No known data errors And swap on the other ones: root@droid[43] # swapinfo Device 1024-blocks Used Avail Capacity /dev/label/swap4 1044192 0 1044192 0% /dev/label/swap3 1044192 0 1044192 0% /dev/label/swap2 1044192 0 1044192 0% Total 3132576 0 3132576 0% This is the mirrored partition that the system actually boots from. This maps physically to da0s1 and da1s1. The normal boot0 and boot1/boot2 and loader operate typically on da0s1a which is really /dev/mirror/boota: root@droid[45] # gmirror status Name Status Components mirror/boot COMPLETE label/boot0 label/boot1 root@droid[47] # df -t ufs Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/mirror/boota 1008582 680708 247188 73% /bootdir The UFS partition eventually ends up getting mounted on /bootdir: root@droid[51] # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# zfs:z/root / zfs rw 0 0 /dev/mirror/boota /bootdir ufs rw,noatime 1 1 /dev/label/swap2 none swap sw 0 0 /dev/label/swap3 none swap sw 0 0 /dev/label/swap4 none swap sw 0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 But when /boot/loader on the UFS partition reads what it thinks is / etc/fstab, which eventually ends up in /bootdir/etc/fstab, the root file system that's mounted is the ZFS filesystem at z/root: root@droid[52] # head /bootdir/etc/fstab # Device Mountpoint FStype Options Dump Pass# z/root / zfs rw 0 0 And /boot on the ZFS root is symlinked into the UFS filesystem, so it gets updated when a make installworld happens: root@droid[53] # ls -l /boot lrwxr-xr-x 1 root wheel 12 May 3 23:00 /boot@ -> bootdir/boot louie On May 30, 2009, at 3:15 PM, Dan Naumov wrote: > Is the idea behind leaving 1GB unused on each disk to work around the > problem of potentially being unable to replace a failed device in a > ZFS pool because a 1TB replacement you bought actually has a lower > sector count than your previous 1TB drive (since the replacement > device has to be either of exact same size or bigger than the old > device)? > > - Dan Naumov > > > On Sat, May 30, 2009 at 10:06 PM, Louis Mamakos > wrote: >> I built a system recently with 5 drives and ZFS. I'm not booting >> off a ZFS >> root, though it does mount a ZFS file system once the system has >> booted from >> a UFS file system. Rather than dedicate drives, I simply >> partitioned each >> of the drives into a 1G partition > From owner-freebsd-stable@FreeBSD.ORG Sun May 31 07:13:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEEA71065670; Sun, 31 May 2009 07:13:00 +0000 (UTC) (envelope-from david@usermode.org) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6378FC0A; Sun, 31 May 2009 07:13:00 +0000 (UTC) (envelope-from david@usermode.org) Received: from radagast.usermode.org (netblock-66-245-217-250.dslextreme.com [66.245.217.250]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n4V7Cxmu070702; Sun, 31 May 2009 00:12:59 -0700 (PDT) (envelope-from david@usermode.org) From: David Johnson To: freebsd-stable@freebsd.org Date: Sun, 31 May 2009 00:12:59 -0700 User-Agent: KMail/1.11.3 (FreeBSD/7.2-RELEASE; KDE/4.2.3; i386; ; ) References: <200905042015.29394.david@usermode.org> <200905091841.26274.david@usermode.org> <1242141471.1755.11.camel@balrog.2hip.net> In-Reply-To: <1242141471.1755.11.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905310012.59472.david@usermode.org> Cc: Robert Noland Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 07:13:01 -0000 I haven't heard anything on this in three weeks. I filed a bug report, but no acceptance yet. Does this imply that there is no intention to fix this problem? What is happening with this? Am I even posting to the right list? I'm completely in the dark here. -- David Johnson From owner-freebsd-stable@FreeBSD.ORG Sun May 31 07:18:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EF0D106566B for ; Sun, 31 May 2009 07:18:02 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id C5E558FC1E for ; Sun, 31 May 2009 07:18:01 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 1C76B71F35C; Sun, 31 May 2009 03:18:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vE0bVY9adHR; Sun, 31 May 2009 03:18:00 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id AA25271F34E; Sun, 31 May 2009 03:18:00 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id A79B488B; Sun, 31 May 2009 03:18:00 -0400 (EDT) Date: Sun, 31 May 2009 03:18:00 -0400 From: Adam McDougall To: Lorenzo Perone Message-ID: <20090531071759.GA35763@egr.msu.edu> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <63548432-B73D-4A08-BA99-FEF5BCC1028A@yellowspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63548432-B73D-4A08-BA99-FEF5BCC1028A@yellowspace.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Mickael MAILLOT , FreeBSD Stable Mailing List Subject: Re: ZFS booting without partitions (was: ZFS boot on zfs mirror) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 07:18:02 -0000 I encountered the same symptoms today on both a 32bit and 64bit brand new install using gptzfsboot. It works for me when I use a copy of loader from an 8-current box with zfs support compiled in. I haven't looked into it much yet but it might help you. If you want, you can try the loader I am using from: http://www.egr.msu.edu/~mcdouga9/loader On Thu, May 28, 2009 at 10:41:42PM +0200, Lorenzo Perone wrote: On 28.05.2009, at 21:46, Mickael MAILLOT wrote: > hi, > > did you erase gmirror meta ? (on the last sector) > with: gmirror clear ad6 ohps I had forgotten that. just did it (in single user mode), but it didn't help :( Shall I repeat any of the other steps after clearing gmirror meta? thanx a lot for your help... Lorenzo > 2009/5/28 Lorenzo Perone : >> Hi, >> >> I tried hard... but without success ;( >> >> the result is, when choosing the disk with the zfs boot >> sectors in it (in my case F5, which goes to ad6), the kernel >> is not found. the console shows: >> >> forth not found >> definitions not found >> only not found >> (the above repeated several times) >> >> can't load 'kernel' >> >> and I get thrown to the loader prompt. >> lsdev does not show any ZFS devices. >> >> Strange thing: if I boot from the other disk, F1, which is my >> ad4 containing the normal ufs system I used to make up the other >> one, and escape to the loader prompt, lsdev actually sees the >> zpool which is on the other disk, and shows: >> zfs0: tank >> >> I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, >> but there I get the panic: free: guard1 fail message. >> (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) >> >> Sure I'm doing something wrong, but what...? Is it a problem that >> the pool is made out of the second disk only (ad6)? >> >> Here are my details (note: latest stable and biosdisk.c merged >> with changes shown in r185095. no problems in buildworld/kernel): >> (....) _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun May 31 08:55:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F181106564A for ; Sun, 31 May 2009 08:55:20 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id E648A8FC16 for ; Sun, 31 May 2009 08:55:19 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.3] (port=61387) by fish.ish.com.au with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MAhaZ-0007ru-1c; Sun, 31 May 2009 19:44:23 +1000 Message-Id: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> From: Aristedes Maniatis To: Dan Naumov In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 31 May 2009 18:43:39 +1000 References: X-Mailer: Apple Mail (2.935.3) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 08:55:20 -0000 On 31/05/2009, at 4:41 AM, Dan Naumov wrote: > To top that > off, even when/if you do it right, not your entire disk goes to ZFS > anyway, because you still do need a swap and a /boot to be non-ZFS, so > you will have to install ZFS onto a slice and not the entire disk and > even SUN discourages to do that. ZFS on root is still pretty new to FreeBSD, and until it gets ironed out and all the sysinstall tools support it nicely, it isn't hard to use a small UFS slice to get things going during boot. And there is nothing wrong with putting ZFS onto a slice rather than the entire disk: that is a very common approach. http://www.ish.com.au/solutions/articles/freebsdzfs Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Sun May 31 09:52:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 964611065673; Sun, 31 May 2009 09:52:27 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 237658FC16; Sun, 31 May 2009 09:52:27 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 390314CE6; Sun, 31 May 2009 11:52:26 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n4V9qN3M096809; Sun, 31 May 2009 11:52:23 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243763545; bh=/HfEzG1wK7m7It4v9V4lfuSt+KVwrTb6I0fyKh+kAiI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gfdtUV1I22IHaRdEjXQkhf72E8zMcVbOYLtv9sz6mFTpKHJl4/i7Vl3wmSpvjqJZq xMXdi7HpLcXgSnv404Fmw== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=hXjPfm2ChNQs8Q8LMygKfkdh9sqluW3o4nwLKStzZ9udjY+l55iQsvvPAKdFCavUA NupnKQu3DQ5qsCXGyxEyw== Message-ID: <4A225357.40804@restart.be> Date: Sun, 31 May 2009 11:52:23 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Kip Macy References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A20F833.5040609@restart.be> <3c1674c90905301227u1c5dab90j9bdaa769520b138b@mail.gmail.com> In-Reply-To: <3c1674c90905301227u1c5dab90j9bdaa769520b138b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-stable@freebsd.org Subject: Re: ZFS MFC heads down X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 09:52:27 -0000 Kip Macy wrote: > Please try applying this change to your tree and let me know. > I patch, I reboot 2 times without problem. I keep you posted is I encounter a new crash. Thanks Henri > Thanks, > Kip > > http://svn.freebsd.org/viewvc/base?view=revision&revision=193110 > > > On Sat, May 30, 2009 at 2:11 AM, Henri Hennebert wrote: >> Kip Macy wrote: >>> On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: >>>> I will be MFC'ing the newer ZFS support some time this afternoon. Both >>>> world and kernel will need to be re-built. Existing pools will >>>> continue to work without upgrade. >>>> >>>> >>>> If you choose to upgrade a pool to take advantage of new features you >>>> will no longer be able to use it with sources prior to today. 'zfs >>>> send/recv' is not expected to inter-operate between different pool >>>> versions. >>> >>> The MFC went in r192498. Please let me know if you have any problems. >>> >> I get a Fatal trap 12: page fault while in kernel mode >> at shutdown. the core.txt is http://verbier.restart.be/xfer/core.txt.61 >> >> Thanks for you work >> >> Henri >> >> >>> Thanks, >>> Kip >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > > From owner-freebsd-stable@FreeBSD.ORG Sun May 31 13:11:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DE2D1065672 for ; Sun, 31 May 2009 13:11:30 +0000 (UTC) (envelope-from enricom@teppisti.it) Received: from smtp-out112.alice.it (smtp-out112.alice.it [85.37.17.112]) by mx1.freebsd.org (Postfix) with ESMTP id DA8E48FC18 for ; Sun, 31 May 2009 13:11:29 +0000 (UTC) (envelope-from enricom@teppisti.it) Received: from FBCMMO03.fbc.local ([192.168.68.197]) by smtp-out112.alice.it with Microsoft SMTPSVC(6.0.3790.3959); Sun, 31 May 2009 15:01:22 +0200 Received: from FBCMCL01B01.fbc.local ([192.168.69.82]) by FBCMMO03.fbc.local with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 May 2009 15:01:22 +0200 Received: from hal.homeunix.net ([79.3.233.253]) by FBCMCL01B01.fbc.local with Microsoft SMTPSVC(6.0.3790.3959); Sun, 31 May 2009 15:01:21 +0200 From: "Enrico M." To: freebsd-stable@freebsd.org Date: Sun, 31 May 2009 15:01:20 +0200 User-Agent: KMail/1.11.3 (FreeBSD/7.2-RELEASE; KDE/4.2.3; i386; ; ) References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <18972.7173.216763.407615@already.dhcp.gene.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905311501.21029.enricom@teppisti.it> X-OriginalArrivalTime: 31 May 2009 13:01:22.0212 (UTC) FILETIME=[E5979640:01C9E1EF] Subject: Re: ZFS booting without partitions (was: ZFS boot on zfs mirror) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 13:11:30 -0000 On Thursday 28 May 2009 15:58:04 Lorenzo Perone wrote: > Hi, > > I tried hard... but without success ;( > > the result is, when choosing the disk with the zfs boot > sectors in it (in my case F5, which goes to ad6), the kernel > is not found. the console shows: > > forth not found > definitions not found > only not found > (the above repeated several times) > > can't load 'kernel' > > and I get thrown to the loader prompt. > lsdev does not show any ZFS devices. > > Strange thing: if I boot from the other disk, F1, which is my > ad4 containing the normal ufs system I used to make up the other > one, and escape to the loader prompt, lsdev actually sees the > zpool which is on the other disk, and shows: > zfs0: tank > > I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, > but there I get the panic: free: guard1 fail message. > (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) > > Sure I'm doing something wrong, but what...? Is it a problem that > the pool is made out of the second disk only (ad6)? > > Here are my details (note: latest stable and biosdisk.c merged > with changes shown in r185095. no problems in buildworld/kernel): > > > > Machine: p4 4GHz 4 GB RAM (i386) > > Note: the pool has actually a different name (heidi > instead of tank, if this can be of any relevance...), > just using tank here as it's one of the conventions... > > mount (just to show my starting situation) > > /dev/mirror/gm0s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) > /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) > /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) > > gmirror status > Name Status Components > mirror/gm0 DEGRADED ad4 > (ad6 used to be the second disk...) > > echo 'LOADER_ZFS_SUPPORT=yes' >> /etc/make.conf > > cd /usr/src > make buildworld && make buildkernel KERNCONF=HEIDI > make installkernel KERNCONF=HEIDI > mergemaster > make installworld > shutdown -r now > > dd if=/dev/zero of=/dev/ad6 bs=512 count=32 > > zpool create tank ad6 > zfs create tank/usr > zfs create tank/var > zfs create -V 4gb tank/swap > zfs set org.freebsd:swap=on tank/swap > zpool set bootfs=tank tank > > rsync -avx / /tank > rsync -avx /usr/ /tank/usr > rsync -avx /var/ /tank/var > cd /usr/src > make installkernel KERNCONF=HEIDI DESTDIR=/tank > > zpool export tank > > dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 > dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 > > zpool import tank > > zfs set mountpoint=legacy tank > zfs set mountpoint=/usr tank/usr > zfs set mountpoint=/var tank/var > > shutdown -r now ... > > at the 'mbr prompt' I pressed F5 (the second disk, ad6) > .. as written above, loader gets loaded (at this stage > I suppose it's the stuff dd't after block 1024?), > but kernel not found. > > /usr/src/sys/i386/conf/HEIDI: > (among other things...): > options KVA_PAGES=512 > > (/tank)/boot/loader.conf: > vm.kmem_size="1024M" > vm.kmem_size_max="1024M" > vfs.zfs.arc_max="128M" > vfs.zfs.vdev.cache.size="8M" > vfs.root.mountfrom="zfs:tank" > > (/tank)/etc/fstab: > # Device Mountpoint FStype Options Dump Pass# > tank / zfs rw 0 0 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > > > > any help is welcome... don't know where to go from here right now. > > BTW: I can't stop thanking the team for the incredible > pace at which bugs are fixed these days! > > > Regards, > > Lorenzo > > On 26.05.2009, at 18:42, George Hartzell wrote: > > Andriy Gapon writes: > >> on 26/05/2009 19:21 George Hartzell said the following: > >>> Dmitry Morozovsky writes: > >>>> On Tue, 26 May 2009, Mickael MAILLOT wrote: > >>>> > >>>> MM> Hi, > >>>> MM> > >>>> MM> i prefere use zfsboot boot sector, an example is better than > >>>> a long talk: > >>>> MM> > >>>> MM> $ zpool create tank mirror ad4 ad6 > >>>> MM> $ zpool export tank > >>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 > >>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 > >>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 > >>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 > >>>> > >>>> s/skeep/skip/ ? ;-) > >>> > >>> What is the reason for copying zfsboot one bit at a time, as opposed > >>> to > >>> > >>> dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 > >> > >> seek=1024 for the second part? and no 'count=1' for it? :-) > >> > >> [Just guessing] Apparently the first block of zfsboot is some form > >> of MBR and the > >> rest is zfs-specific code that goes to magical sector 1024. > > > > Ok, I managed to read the argument to seek as "one block", apparently > > my coffee hasn't hit yet. > > > > I'm still confused about the two parts of zfsboot and what's magical > > about seeking to 1024. > > > > g. I obtained the same result with FreeBSD 7 stable. I installed first a new system in a scsi disk with ufs I put LOADER_ZFS_SUPPORT=yes in /etc/make.conf, updated src and made buildworld without trouble. I built a new kernel, installed it and installed new world. Until here, that's all right Then, I tried with a PATA hard drive, ad2 I resetted the mbr and the partition table with dd if=/dev/zero of=/dev/ad2 bs=512 count=63 I created a new pool and filesystems: zpool create test ad2 zfs create test/usr zfs create test/var zfs create test/tmp zfs create test/home zfs create test/root zfs create -V 1gb test/swap zfs set org.freebsd:swap=on test/swap zpool set bootfs=test test So, I copied the system in the pool: find -x / | cpio -pmd /test ... and put "vfs.root.mountfrom=zfs:test" in /test/boot/loader.conf I set the mountpoints: zfs set mountpoint=/usr test/usr ....... and installed the zfsboot: zpool export test dd if=/boot/zfsboot of=/dev/ad2 bs=512 count=1 dd if=/boot/zfsboot of=/dev/ad2 bs=512 skip=1 seek=1024 zpool import test Help me, please Enrico From owner-freebsd-stable@FreeBSD.ORG Sun May 31 13:52:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69E2E1065670 for ; Sun, 31 May 2009 13:52:47 +0000 (UTC) (envelope-from rafaelhfaria@cenadigital.com.br) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5B08FC1B for ; Sun, 31 May 2009 13:52:46 +0000 (UTC) (envelope-from rafaelhfaria@cenadigital.com.br) Received: by an-out-0708.google.com with SMTP id c3so3742017ana.13 for ; Sun, 31 May 2009 06:52:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.14 with SMTP id r14mr5702293and.120.1243776630137; Sun, 31 May 2009 06:30:30 -0700 (PDT) From: Rafael Henrique Faria Date: Sun, 31 May 2009 10:30:10 -0300 Message-ID: <10bf7ef00905310630k3179ba9bi58482f2794a857a7@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Problem with graid3 and gjournal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 13:52:47 -0000 I'm using a GJournal on top of GRAID3 on top of GPart. What happens: If I go to my gjournal mount point e put: dd if=/dev/zero of=file bs=1k count=10 The system freeze. No more response in the corrent ssh session, the system don't respond to new ssh connection, and the console got freezed too. So, I tried with: dd if=/dev/random of=file bs=1k count=10 The same thing. I went to an other machine, created the file with: dd if=/dev/zero bs=1k count=10 | bzip2 | dd of=file.bz2 The file is created OK. I send the file to my machine using gjournal, and: bzcat file.bz2 | dd of=file The system got freezed again. In the same server, I have an other partition with gmirror, and gjournal on top of it. The file was created OK. Then I tried to copy the file from the gmirror+gjournal partition to the graid3+gjournal partition, and the system got freezed again. Then I belieave that there is a problem with graid3+gjournal. If I create filed in the graid3+gjournal with the VI, or send any other file (ie. /etc/rc.conf) to this partition, is OK. No freeze. Only when I try to create a file with dd. Where is the problem, with GRAID3, or with GJournal ? I'll try to remove the GJournal from this partition. But anyone knows somethig about it? My configuration: FreeBSD papillon.cenadigital.com.br 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed May 6 21:36:59 UTC 2009 paramount@papillon.cenadigital.com.br:/usr/obj/usr/src/sys/PAPILLON i386 CPU: Intel Pentium III (598.63-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 real memory = 201326592 (192 MB) avail memory = 182697984 (174 MB) paramount@papillon paramount # gpart show => 34 78242909 ad0 GPT (37G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-ufs (1.0G) 2097314 786432 3 freebsd-swap (384M) 2883746 2097152 4 freebsd-ufs (1.0G) 4980898 6291456 5 freebsd-ufs (3.0G) 11272354 27105264 6 freebsd-ufs (13G) 38377618 39865325 7 freebsd-ufs (19G) => 34 39865325 ad1 GPT (19G) 34 39865325 1 freebsd-ufs (19G) => 34 80293181 ad2 GPT (38G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-ufs (1.0G) 2097314 786432 3 freebsd-swap (384M) 2883746 2097152 4 freebsd-ufs (1.0G) 4980898 6291456 5 freebsd-ufs (3.0G) 11272354 27105264 6 freebsd-ufs (13G) 38377618 39865325 7 freebsd-ufs (19G) 78242943 2050272 8 freebsd-swap (1.0G) paramount@papillon paramount # graid3 status Name Status Components raid3/gr0inet COMPLETE ad0p7 ad1p1 ad2p7 paramount@papillon paramount # gmirror status Name Status Components mirror/gm0root COMPLETE ad0p2 ad2p2 mirror/gm0tmp COMPLETE ad0p4 ad2p4 mirror/gm0var COMPLETE ad0p5 ad2p5 mirror/gm0usr COMPLETE ad0p6 ad2p6 kernel: GEOM_JOURNAL: Journal raid3/gr0inet clean. kernel: GEOM_JOURNAL: BIO_FLUSH not supported by raid3/gr0inet. GEOM_JOURNAL: Flush cache of raid3/gr0inet: error=19. GEOM_JOURNAL: Flush cache of raid3/gr0inet: error=19. GEOM_JOURNAL: Flush cache of raid3/gr0inet: error=19. GEOM_JOURNAL: Flush cache of raid3/gr0inet: error=19. GEOM_JOURNAL: Flush cache of raid3/gr0inet: error=19. I think that GJournal can't be on top of a GRaid3. But GJournal on top of GMirror is working very good. Thank's for any help. -- Rafael Henrique da Silva Faria # Grupo Cena Digital # (16) 9229-8928 # www.cenadigital.com.br From owner-freebsd-stable@FreeBSD.ORG Sun May 31 14:20:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 669AA1065676 for ; Sun, 31 May 2009 14:20:18 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 26CFD8FC1A for ; Sun, 31 May 2009 14:20:15 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-241-168-38.bna.bellsouth.net [74.241.168.38]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n4VEK9TA069513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 May 2009 10:20:09 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: David Johnson In-Reply-To: <200905310012.59472.david@usermode.org> References: <200905042015.29394.david@usermode.org> <200905091841.26274.david@usermode.org> <1242141471.1755.11.camel@balrog.2hip.net> <200905310012.59472.david@usermode.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-llAyeMBC7LhQFOr1sQ+j" Organization: FreeBSD Date: Sun, 31 May 2009 09:20:03 -0500 Message-Id: <1243779603.1713.3916.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 14:20:18 -0000 --=-llAyeMBC7LhQFOr1sQ+j Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2009-05-31 at 00:12 -0700, David Johnson wrote: > I haven't heard anything on this in three weeks. I filed a bug report, bu= t no=20 > acceptance yet. Does this imply that there is no intention to fix this=20 > problem? What is happening with this? Am I even posting to the right list= ? I'm=20 > completely in the dark here. Yes, your in the right place... I just can't reproduce it still and so it's problematic to track down. I reviewed the commit that you pointed out, but that is the r6/7xx import commit and involves a lot of code. robert. --=20 Robert Noland FreeBSD --=-llAyeMBC7LhQFOr1sQ+j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoikhMACgkQM4TrQ4qfROOGngCfakpwyF5DeSszBQ7oBFuG5QOt FscAni7b2yViOAGZjdGJ83EZFlobBzA/ =ObWn -----END PGP SIGNATURE----- --=-llAyeMBC7LhQFOr1sQ+j-- From owner-freebsd-stable@FreeBSD.ORG Sun May 31 14:46:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35E6410656A3 for ; Sun, 31 May 2009 14:46:01 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from viefep24-int.chello.at (viefep24-int.chello.at [62.179.121.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE078FC16 for ; Sun, 31 May 2009 14:46:00 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from edge02.upc.biz ([192.168.13.237]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090531143007.EXUJ21513.viefep11-int.chello.at@edge02.upc.biz>; Sun, 31 May 2009 16:30:07 +0200 Received: from joanne.klop.ws ([62.163.38.246]) by edge02.upc.biz with edge id yEW01b03l5Jf6UE02EW1fn; Sun, 31 May 2009 16:30:07 +0200 X-SourceIP: 62.163.38.246 Received: from 82-170-177-25.ip.telfort.nl (localhost [127.0.0.1]) by joanne.klop.ws (Postfix) with ESMTP id 48D351CC13; Sun, 31 May 2009 16:30:00 +0200 (CEST) Date: Sun, 31 May 2009 16:29:59 +0200 To: "Dan Naumov" , =?utf-8?Q?Morgan_Wesstr=C3=B6m?= From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <4A1FAB45.4040904@h3q.com> <4A1FBD4A.5080204@pp.dyndns.biz> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.64 (FreeBSD) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 14:46:01 -0000 On Fri, 29 May 2009 13:34:57 +0200, Dan Naumov wrote: > Now that I have evaluated the numbers and my needs a bit, I am really > confused about what appropriate course of action for me would be. > > 1) Use ZFS without GELI and hope that zfs-crypto get implemented in > Solaris and ported to FreeBSD "soon" and that when it does, it won't > come with such a dramatic performance decrease as GELI/ZFS seems to > result in. > 2) Go ahead with the original plan of using GELI/ZFS and grind my > teeth at the 24 MB/s read speed off a single disk. 3) Add extra disks. It will speed up reading. One disk extra will about double the read speed. Ronald. From owner-freebsd-stable@FreeBSD.ORG Sun May 31 14:47:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F71B1065689 for ; Sun, 31 May 2009 14:47:34 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2390B8FC1C for ; Sun, 31 May 2009 14:47:33 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so3761516ywe.13 for ; Sun, 31 May 2009 07:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iYlsEl4Y2atJnAvQIodWM7oVr/FgN0fUhFHhGNY7o9c=; b=KrNk4XAPilxd6xql/IUZGtEUmeB13W3ZmyViY7HJgV7mxV5TLZ/Ps+ZxNZ6nSKu0mJ 8+JLjm2cqgIHaPpcbV6n99elJ58O/H/FmuKuvPqayt1tzkQg1OjKYNrtrsHNSOMgneU2 dGZJFHuBugkJ02cyHO108WEGHEw7B8PExvaY4= 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=IjI3cs2Yw9A9TXc2GctMqWTZtDhbJky4Jxk1L47SetCkqDk+7UY5bVmBpb+6Itrv3v UElcttGf5f5v21AXSGbo0gse4PliaX717jbdUCYG9QVDD7stRbDYwCqIqhgqQRaW2uxQ ShLQKo4GNaEmzOl3dkO7++gA6AGguRm+J5+Eg= MIME-Version: 1.0 Received: by 10.100.126.19 with SMTP id y19mr5794894anc.100.1243781253322; Sun, 31 May 2009 07:47:33 -0700 (PDT) In-Reply-To: References: <4A1FAB45.4040904@h3q.com> <4A1FBD4A.5080204@pp.dyndns.biz> Date: Sun, 31 May 2009 17:47:33 +0300 Message-ID: From: Dan Naumov To: Ronald Klop Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= , freebsd-stable@freebsd.org Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 14:47:35 -0000 I am pretty sure that adding more disks wouldn't solve anything in this case, only either using a faster CPU or a faster crypto system. When you are capable of 70 MB/s reads on a single unecrypted disk, but only 24 MB/s reads off the same disk while encrypted, your disk speed isn't the problem. - Dan Naumov On Sun, May 31, 2009 at 5:29 PM, Ronald Klop wrote: > On Fri, 29 May 2009 13:34:57 +0200, Dan Naumov wrote: > >> Now that I have evaluated the numbers and my needs a bit, I am really >> confused about what appropriate course of action for me would be. >> >> 1) Use ZFS without GELI and hope that zfs-crypto get implemented in >> Solaris and ported to FreeBSD "soon" and that when it does, it won't >> come with such a dramatic performance decrease as GELI/ZFS seems to >> result in. >> 2) Go ahead with the original plan of using GELI/ZFS and grind my >> teeth at the 24 MB/s read speed off a single disk. > > 3) Add extra disks. It will speed up reading. One disk extra will about > double the read speed. From owner-freebsd-stable@FreeBSD.ORG Sun May 31 15:39:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C66106570D for ; Sun, 31 May 2009 15:39:56 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id D9AF78FC14 for ; Sun, 31 May 2009 15:39:55 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n4VFdsBU099972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 May 2009 17:39:54 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n4VFdsH5099971; Sun, 31 May 2009 17:39:54 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Sun, 31 May 2009 17:39:53 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Morgan =?utf-8?B?V2Vzc3Ryw7Zt?= Message-ID: <20090531153953.GE18676@acme.spoerlein.net> Mail-Followup-To: Morgan =?utf-8?B?V2Vzc3Ryw7Zt?= , freebsd-stable@freebsd.org References: <4A1FAB45.4040904@h3q.com> <4A1FBD4A.5080204@pp.dyndns.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A1FBD4A.5080204@pp.dyndns.biz> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 15:39:56 -0000 On Fri, 29.05.2009 at 12:47:38 +0200, Morgan Wesström wrote: > You can benchmark the encryption subsytem only, like this: > > # kldload geom_zero > # geli onetime -s 4096 -l 256 gzero > # sysctl kern.geom.zero.clear=0 > # dd if=/dev/gzero.eli of=/dev/null bs=1M count=512 > > 512+0 records in > 512+0 records out > 536870912 bytes transferred in 11.861871 secs (45260222 bytes/sec) > > The benchmark will use 256-bit AES and the numbers are from my Core2 Duo > Celeron E1200 1,6GHz. My old trusty Pentium III 933MHz performs at > 13MB/s on that test. Both machines are recompiled with CPUTYPE=core2 and > CPUTYPE=pentium3 respectively but unfortunately I have no benchmarks on > how they perform without the CPU optimizations. Hi Morgan, thanks for the nice benchmarking trick. I tried this on two ~7.2 systems: CPU: Intel Pentium III (996.77-MHz 686-class CPU) -> 14.3MB/s CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU) -> 47.5MB/s Reading a big file from the pool of this P4 results in 27.6MB/s netto transfer rate (single 7200 rpm SATA disk). I would be *very* interested in numbers from the dual core Atom, both with 2 CPUs and with 1 active core only. I think that having dual core is a must for this setup, so you can use 2 GELI threads and have the ZFS threads on top of that to spread the load. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-stable@FreeBSD.ORG Sun May 31 16:00:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EFFE1065672 for ; Sun, 31 May 2009 16:00:27 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id 0426A8FC12 for ; Sun, 31 May 2009 16:00:26 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from ironport2.bredband.com (195.54.101.122) by proxy2.bredband.net (7.3.140.3) id 49F59CBD00D802A3 for freebsd-stable@freebsd.org; Sun, 31 May 2009 18:00:25 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFAF5GIkpV4juSPGdsb2JhbACBT5Y8AQEBAbUlhAwF X-IronPort-AV: E=Sophos;i="4.41,279,1241388000"; d="scan'208";a="495239726" Received: from c-923be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.146]) by ironport2.bredband.com with ESMTP; 31 May 2009 18:00:25 +0200 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.3/8.14.3) with ESMTP id n4VG0No8057626 for ; Sun, 31 May 2009 18:00:24 +0200 (CEST) (envelope-from freebsd-stable@pp.dyndns.biz) Message-ID: <4A22A997.7080507@pp.dyndns.biz> Date: Sun, 31 May 2009 18:00:23 +0200 From: =?UTF-8?B?TW9yZ2FuIFdlc3N0csO2bQ==?= User-Agent: Thunderbird 2.0.0.21 (X11/20090430) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4A1FAB45.4040904@h3q.com> <4A1FBD4A.5080204@pp.dyndns.biz> <20090531153953.GE18676@acme.spoerlein.net> In-Reply-To: <20090531153953.GE18676@acme.spoerlein.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 16:00:27 -0000 > Hi Morgan, > > thanks for the nice benchmarking trick. I tried this on two ~7.2 > systems: > > CPU: Intel Pentium III (996.77-MHz 686-class CPU) > -> 14.3MB/s > > CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU) > -> 47.5MB/s > > Reading a big file from the pool of this P4 results in 27.6MB/s netto > transfer rate (single 7200 rpm SATA disk). > > I would be *very* interested in numbers from the dual core Atom, both > with 2 CPUs and with 1 active core only. I think that having dual core > is a must for this setup, so you can use 2 GELI threads and have the ZFS > threads on top of that to spread the load. > > Cheers, > Ulrich Spörlein Credit to pjd@ actually. Picked up the trick myself from freebsd-geom some time ago :-) http://lists.freebsd.org/pipermail/freebsd-geom/2007-July/002498.html My Eee PC with a single core N270 is being repaired atm, it suffered a bad BIOS flash so I can't help you with benchmarks until it's back. I don't have access to another Atom CPU unfortunately. /Morgan From owner-freebsd-stable@FreeBSD.ORG Sun May 31 16:05:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DF2D106564A for ; Sun, 31 May 2009 16:05:35 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id A9E238FC26 for ; Sun, 31 May 2009 16:05:34 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n4VG5XZQ000623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 May 2009 18:05:33 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n4VG5Xi4000622; Sun, 31 May 2009 18:05:33 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Sun, 31 May 2009 18:05:33 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Dan Naumov Message-ID: <20090531160533.GF18676@acme.spoerlein.net> Mail-Followup-To: Dan Naumov , freebsd-stable@freebsd.org References: 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.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 16:05:35 -0000 On Fri, 29.05.2009 at 11:19:44 +0300, Dan Naumov wrote: > Also, free free to criticize my planned filesystem layout for the > first disk of this system, the idea behind /mnt/sysbackup is to take a > snapshot of the FreeBSD installation and it's settings before doing > potentially hazardous things like upgrading to a new -RELEASE: > > ad1s1 (freebsd system slice) > ad1s1a => 128bit Blowfish ad1s1a.eli 4GB swap > ad1s1b 128GB ufs2+s / > ad1s1c 128GB ufs2+s noauto /mnt/sysbackup > > ad1s2 => 128bit Blowfish ad1s2.eli > zpool > /home > /mnt/data1 Hi Dan, everybody has different needs, but what exactly are you doing with 128GB of / ? What I did is the following: 2GB CF card + CF to ATA adapter (today, I would use 2x8GB USB sticks, CF2ATA adapters suck, but then again, which Mobo has internal USB ports?) Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ad0a 507630 139740 327280 30% / /dev/ad0d 1453102 1292296 44558 97% /usr /dev/md0 253678 16 233368 0% /tmp /usr is quite crowded, but I just need to clean up some ports again. /var, /usr/src, /home, /usr/obj, /usr/ports are all on the GELI+ZFS pool. If /usr turns out to be to small, I can also move /usr/local there. That way booting and single user involves trusty old UFS only. I also do regular dumps from the UFS filesystems to the ZFS tank, but there's really no sacred data under / or /usr that I would miss if the system crashed (all configuration changes are tracked using mercurial). Anyway, my point is to use the full disks for GELI+ZFS whenever possible. This makes it more easy to replace faulty disks or grow ZFS pools. The FreeBSD base system, I would put somewhere else. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-stable@FreeBSD.ORG Sun May 31 16:28:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB03A1065670 for ; Sun, 31 May 2009 16:28:52 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 64D588FC08 for ; Sun, 31 May 2009 16:28:52 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so3767447ana.13 for ; Sun, 31 May 2009 09:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ms9r2b+Wvz8XFpnH6iBoic4wVmssUSJsgkFWRf7umh4=; b=t1UsyN2CY847tLJ9fjWBFg7AMgXRMBD4zfvXZwE1kGBt0dxbsULhlSVde4PZnA5bn3 BSL4UX4lePFT+2iwsTRbXwfy0kFxDMNr7jccOXQlO0WTYJMiDjdgF4yvQ48/CvAtcUw0 0qQAtsrUZmLmRak5n2dkUWbChQe1dODf/4q3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Rcb0lQ2bGwcjzk4hXCjxVTgFZgxlF/IGVVrRnGMn+kTJLc3XWUjSYzI2bNrr9Ycd9i 7oso90+bSLHEypkbqBrXKcBwR2KWblc6AxiUYvJYCsX1P0n5kAFow3hZmhvG09qdtzqT i9mc2hQJUyaZDqzFKwUfJlNJPnqRe0qphNZN0= MIME-Version: 1.0 Received: by 10.100.202.17 with SMTP id z17mr6047654anf.80.1243787331636; Sun, 31 May 2009 09:28:51 -0700 (PDT) In-Reply-To: <20090531160533.GF18676@acme.spoerlein.net> References: <20090531160533.GF18676@acme.spoerlein.net> Date: Sun, 31 May 2009 19:28:51 +0300 Message-ID: From: Dan Naumov To: uqs@spoerlein.net, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 16:28:53 -0000 Hi Since you are suggesting 2 x 8GB USB for a root partition, what is your experience with read/write speed and lifetime expectation of modern USB sticks under FreeBSD and why 2 of them, GEOM mirror? - Dan Naumov > Hi Dan, > > everybody has different needs, but what exactly are you doing with 128GB > of / ? What I did is the following: > > 2GB CF card + CF to ATA adapter (today, I would use 2x8GB USB sticks, > CF2ATA adapters suck, but then again, which Mobo has internal USB ports?) > > Filesystem =A0 =A0 =A0 =A0 =A0 =A0 1024-blocks =A0 =A0 =A0Used =A0 =A0Ava= il Capacity =A0Mounted on > /dev/ad0a =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 507630 =A0 =A0139740 =A0 32= 7280 =A0 =A030% =A0 =A0/ > /dev/ad0d =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01453102 =A0 1292296 =A0 =A04= 4558 =A0 =A097% =A0 =A0/usr > /dev/md0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0253678 =A0 =A0 =A0 =A016 = =A0 233368 =A0 =A0 0% =A0 =A0/tmp > > /usr is quite crowded, but I just need to clean up some ports again. > /var, /usr/src, /home, /usr/obj, /usr/ports are all on the GELI+ZFS > pool. If /usr turns out to be to small, I can also move /usr/local > there. That way booting and single user involves trusty old UFS only. > > I also do regular dumps from the UFS filesystems to the ZFS tank, but > there's really no sacred data under / or /usr that I would miss if the > system crashed (all configuration changes are tracked using mercurial). > > Anyway, my point is to use the full disks for GELI+ZFS whenever > possible. This makes it more easy to replace faulty disks or grow ZFS > pools. The FreeBSD base system, I would put somewhere else. From owner-freebsd-stable@FreeBSD.ORG Sun May 31 17:08:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 598C91065676 for ; Sun, 31 May 2009 17:08:19 +0000 (UTC) (envelope-from pertti.kosunen@pp.nic.fi) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by mx1.freebsd.org (Postfix) with ESMTP id E85CF8FC1B for ; Sun, 31 May 2009 17:08:18 +0000 (UTC) (envelope-from pertti.kosunen@pp.nic.fi) Received: from [10.0.0.15] (88.195.49.215) by jenni2.inet.fi (8.5.014) id 49F5CB64014AEDF8 for freebsd-stable@freebsd.org; Sun, 31 May 2009 20:08:17 +0300 Message-ID: <4A22B976.7010407@pp.nic.fi> Date: Sun, 31 May 2009 20:08:06 +0300 From: Pertti Kosunen User-Agent: Thunderbird 2.0.0.16 (X11/20080804) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20090531160533.GF18676@acme.spoerlein.net> In-Reply-To: <20090531160533.GF18676@acme.spoerlein.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 17:08:19 -0000 Ulrich Spörlein wrote: > 2GB CF card + CF to ATA adapter (today, I would use 2x8GB USB sticks, > CF2ATA adapters suck, but then again, which Mobo has internal USB ports?) Many has internal USB header. http://www.logicsupply.com/products/afap_082usb From owner-freebsd-stable@FreeBSD.ORG Sun May 31 17:43:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99721106566B for ; Sun, 31 May 2009 17:43:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC3A8FC0A for ; Sun, 31 May 2009 17:43:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by gxk18 with SMTP id 18so2949074gxk.19 for ; Sun, 31 May 2009 10:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=B1EtrxqnzL392b6OafwOqX7vXoUNWKtdSuKGU+CUQNY=; b=lBNS4TxXIZZchF0fxWZLxA/cUboZp+bOeijISRtOqB02TUADQqjP+icoXVp179fg6p atLLX4fsMktIXxGtutRXX6o2G77RyBWuZqQ6NQviDxZA33LzyR2lEPZwMQ7bgj8yWfHs +v02wC6elgh87igBP56WIgd8EBZ3yPUVJcQlU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=yBLBUylRvCs1OneIxbi5+6j6ngMlHrthTKScfGna/Vj1jczv6KxZKf5gbh7pXOg/YY syTV7dbdDOSOrDsBDDXhBunEpdQLAgh2pT9f5WzV0kBnI6xlABNpuresSWWdN7l4D7tb XnUiO4c0zxMXb+dJm+HULUliWnHRgJkfi/Nas= MIME-Version: 1.0 Received: by 10.150.182.5 with SMTP id e5mr9671995ybf.328.1243791835756; Sun, 31 May 2009 10:43:55 -0700 (PDT) In-Reply-To: <20090531160533.GF18676@acme.spoerlein.net> References: <20090531160533.GF18676@acme.spoerlein.net> Date: Sun, 31 May 2009 10:43:55 -0700 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 17:43:56 -0000 On Sun, May 31, 2009 at 9:05 AM, Ulrich Sp=C3=B6rlein w= rote: > everybody has different needs, but what exactly are you doing with 128GB > of / ? What I did is the following: > > 2GB CF card + CF to ATA adapter (today, I would use 2x8GB USB sticks, > CF2ATA adapters suck, but then again, which Mobo has internal USB ports?) You can get CF-to-SATA adapters. We've used CF-to-IDE quite successfully in a pair of storage server. We have a couple of the SATA adapters on order to test with as our new motherboards only have 1 IDE controller, and doing mirroring across master/slave of the same channel sucks. > /usr is quite crowded, but I just need to clean up some ports again. > /var, /usr/src, /home, /usr/obj, /usr/ports are all on the GELI+ZFS > pool. If /usr turns out to be to small, I can also move /usr/local > there. That way booting and single user involves trusty old UFS only. That's what we do as well, but with /usr/local on ZFS, leaving just / and /usr on UFS. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun May 31 20:00:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8677D1065672 for ; Sun, 31 May 2009 20:00:10 +0000 (UTC) (envelope-from sir_dog@onet.com.ua) Received: from onet.com.ua (mail.onet.com.ua [195.69.244.5]) by mx1.freebsd.org (Postfix) with ESMTP id ED8A68FC08 for ; Sun, 31 May 2009 20:00:09 +0000 (UTC) (envelope-from sir_dog@onet.com.ua) Received: from onet.com.ua (localhost [127.0.0.1]) by onet.com.ua (8.14.2/8.14.2) with ESMTP id n4VJQRiN025796 for ; Sun, 31 May 2009 22:26:27 +0300 (EEST) (envelope-from sir_dog@onet.com.ua) From: "Pavel Greenberg" To: freebsd-stable@freebsd.org Date: Sun, 31 May 2009 22:26:27 +0300 Message-Id: <20090531191456.M33035@onet.com.ua> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 79.171.121.214 (sir_dog) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-u Subject: buildworld fails with "WITHOUT_CDDL=yes" in src.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 31 May 2009 20:00:10 -0000 Hello everybody! After today's source update I have a problem when doing make buildworld: cc -O2 -fno-strict-aliasing -pipe -march=pentium4 -DLOADER_NFS_SUPPORT - DBOOT_FORTH -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/ i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/usr/ src/sys/boot/i386/loader/../../common -I. -Wall -I/usr/src/sys/boot/i386/ loader/.. -I/usr/src/sys/boot/i386/loader/../btx/lib -ffreestanding - mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno- sse3 -c /usr/src/sys/boot/i386/loader/../../common/interp_forth.c make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libzfs.a. Stop *** Error code 2 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. In my src.conf I have options WITHOUT_CDDL= true WITHOUT_ZFS= true because I don't use ZFS, my desktop haven't enought resources for it and I want not to build it. When I updated my OS some weeks ago with the same src.conf process ended OK. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 00:10:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C5C106566B for ; Mon, 1 Jun 2009 00:10:38 +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 4EA1C8FC18 for ; Mon, 1 Jun 2009 00:10:36 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-217-173.lns11.adl2.internode.on.net [121.45.217.173]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n510AWgf072710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Jun 2009 09:40:33 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Mon, 1 Jun 2009 09:40:13 +0930 User-Agent: KMail/1.9.10 References: <20090531191456.M33035@onet.com.ua> In-Reply-To: <20090531191456.M33035@onet.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1369073.FL41RibI9u"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906010940.26300.doconnor@gsoft.com.au> X-Spam-Score: -1.344 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Pavel Greenberg Subject: Re: buildworld fails with "WITHOUT_CDDL=yes" in src.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 00:10:38 -0000 --nextPart1369073.FL41RibI9u Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 1 Jun 2009, Pavel Greenberg wrote: > Hello everybody! > After today's source update I have a problem when doing make > buildworld: > > cc -O2 -fno-strict-aliasing -pipe -march=3Dpentium4 > -DLOADER_NFS_SUPPORT - DBOOT_FORTH > -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/ > i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT > -DLOADER_GPT_SUPPORT -I/usr/ src/sys/boot/i386/loader/../../common > -I. -Wall -I/usr/src/sys/boot/i386/ loader/.. > -I/usr/src/sys/boot/i386/loader/../btx/lib -ffreestanding - > mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno- sse3 -c > /usr/src/sys/boot/i386/loader/../../common/interp_forth.c make: don't > know how to make /usr/obj/usr/src/tmp/usr/lib/libzfs.a. Stop *** > Error code 2 > > Stop in /usr/src/sys/boot/i386. > *** Error code 1 > > Stop in /usr/src/sys/boot. > *** Error code 1 > > Stop in /usr/src/sys. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > In my src.conf I have options > WITHOUT_CDDL=3D true > WITHOUT_ZFS=3D true > because I don't use ZFS, my desktop haven't enought resources for it > and I want not to build it. When I updated my OS some weeks ago with > the same src.conf process ended OK. While the above IS a bug it should be pointed out that unless you=20 actually load the ZFS kld it won't use any memory on your system. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1369073.FL41RibI9u Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKIxxy5ZPcIHs/zowRAjBOAKChrMOSv8RaA7A1rxquVWzDyX7StgCePCPX WO7QOyISBqBCxZqUatHPWdo= =tNzN -----END PGP SIGNATURE----- --nextPart1369073.FL41RibI9u-- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 05:45:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A0EF1065673 for ; Mon, 1 Jun 2009 05:45:12 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id CFDD38FC34 for ; Mon, 1 Jun 2009 05:45:11 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n515jAwe015171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jun 2009 07:45:10 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n515jAeg015170; Mon, 1 Jun 2009 07:45:10 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 1 Jun 2009 07:45:10 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Dan Naumov Message-ID: <20090601054510.GH18676@acme.spoerlein.net> Mail-Followup-To: Dan Naumov , freebsd-stable@freebsd.org References: <20090531160533.GF18676@acme.spoerlein.net> 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.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS on top of GELI / Intel Atom 330 system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 05:45:12 -0000 On Sun, 31.05.2009 at 19:28:51 +0300, Dan Naumov wrote: > Hi > > Since you are suggesting 2 x 8GB USB for a root partition, what is > your experience with read/write speed and lifetime expectation of > modern USB sticks under FreeBSD and why 2 of them, GEOM mirror? Well, my current setup is using an old 2GB CF card, so read/write speeds suck (14 and 7 MB/s, respectively, IIRC), but then again, there are not many actual read/writes on / or /usr for my setup anyway. The 2x 8GB USB sticks I would of course use to gmirror the setup, although I have been told that this is rather excessive. Modern flash media should cope with enough write cycles to get you through a decade. With /var being on GELI+ZFS this point is mood even more, IMHO. A recent 8GB Sandisk U3 stick of mine manages to read/write ~25MB/s (working from memory here), so this is pretty much the maximum USB 2.0 is giving you. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 09:57:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0914106564A for ; Mon, 1 Jun 2009 09:57:48 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1C68FC14 for ; Mon, 1 Jun 2009 09:57:48 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: by ewy8 with SMTP id 8so4227086ewy.43 for ; Mon, 01 Jun 2009 02:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1G4scGNqSUSl2yuHeG6MQ2pjaReBNOmBplQGiKhLpA8=; b=ffVTzaHQSRTvIGKnUsmX9pD+MnRiOX9cGcRzNj3OjCJT7QPZM1EwEGKRD4205Ckfue aKesBJSYNMJCj8KnveKdonWpd4PRynsyrblkJPSQe/4xkpBxBfTf7gbpGuesBcBhpOgJ cT38UuM+5kJhxWXtQLFEpxjZueZJxM9XQv+2Q= 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=VY78xmJllw1FTngpfHzW0SjZXmS9LqyPZS4JFB9TOuG+42mJ0n2R5AFFBramZfIpuN 50gTHcdewQiYKkO6kKANiaQZnSExAli9dNKA6kEyaPjJIMj0H0lY7dIzhKzGswIM+TW1 3GJPJcOpY+CEJpiHsNXF1/mBHSaXT82BV3sMg= MIME-Version: 1.0 Received: by 10.210.30.10 with SMTP id d10mr1425602ebd.5.1243850267454; Mon, 01 Jun 2009 02:57:47 -0700 (PDT) In-Reply-To: References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> Date: Mon, 1 Jun 2009 11:57:47 +0200 Message-ID: From: Alberto Villa To: Lorenzo Perone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mickael MAILLOT , FreeBSD Stable Mailing List Subject: Re: ZFS booting without partitions (was: ZFS boot on zfs mirror) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 09:57:49 -0000 On Thu, May 28, 2009 at 3:58 PM, Lorenzo Perone wrote: > the result is, when choosing the disk with the zfs boot > sectors in it (in my case F5, which goes to ad6), the kernel > is not found. the console shows: > > forth not found > definitions not found > only not found > (the above repeated several times) > > can't load 'kernel' > > and I get thrown to the loader prompt. > lsdev does not show any ZFS devices. same here on 7-stable (csupped yesterday) i've followed the same steps, but i've used gpt as explained in the first mail. the same exact steps worked perfectly on 8-current in virtualbox -- Alberto Villa From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 10:06:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBC74106566B for ; Mon, 1 Jun 2009 10:06:23 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 431CD8FC21 for ; Mon, 1 Jun 2009 10:06:23 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 056AE4D04; Mon, 1 Jun 2009 12:06:21 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n51A6IK2029434; Mon, 1 Jun 2009 12:06:19 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243850781; bh=pQrCpj9bU6u7zNmwuKTamGh3+Y4WeuI2hq6ie64fPkk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LiDZM0mw5uk2+eETslkj5M0VXrSkNosXd26HDS85o1Z5JtAa9wQ+YK36lX3aMD6Gk mLAIMd+ayfJVrUr9fJ6Kw== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=YLuJWQRK9eu89VYbf0HbRDF/kyP+d9PWZZpItUA+qNvtcH1weOeXI+s83FcfZvGgV B8sY5riCrzqDRUgoBNJjA== Message-ID: <4A23A81A.5050600@restart.be> Date: Mon, 01 Jun 2009 12:06:18 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Lorenzo Perone References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Mickael MAILLOT , FreeBSD Stable Mailing List Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 10:06:24 -0000 Lorenzo Perone wrote: > Hi, > > I tried hard... but without success ;( > > the result is, when choosing the disk with the zfs boot > sectors in it (in my case F5, which goes to ad6), the kernel > is not found. the console shows: > > forth not found > definitions not found > only not found > (the above repeated several times) This is the file /boot/loader from 7.2-STABLE which is wrong. You can find a copy from 8.0-CURRENT and a script that I tested on a USB key) and is running for me: http://verbier.restart.be/xfer/boot-zfs/ Put this directory somewhere, eg /tmp/boot-zfs and run the script eg: `cd /tmp/boot-zfs && sh -x make_usb_key.sh da6 kingston` good luck Henri > > can't load 'kernel' > > and I get thrown to the loader prompt. > lsdev does not show any ZFS devices. > > Strange thing: if I boot from the other disk, F1, which is my > ad4 containing the normal ufs system I used to make up the other > one, and escape to the loader prompt, lsdev actually sees the > zpool which is on the other disk, and shows: > zfs0: tank > > I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, > but there I get the panic: free: guard1 fail message. > (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) > > Sure I'm doing something wrong, but what...? Is it a problem that > the pool is made out of the second disk only (ad6)? > > Here are my details (note: latest stable and biosdisk.c merged > with changes shown in r185095. no problems in buildworld/kernel): > > > > Machine: p4 4GHz 4 GB RAM (i386) > > Note: the pool has actually a different name (heidi > instead of tank, if this can be of any relevance...), > just using tank here as it's one of the conventions... > > mount (just to show my starting situation) > > /dev/mirror/gm0s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) > /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) > /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) > > gmirror status > Name Status Components > mirror/gm0 DEGRADED ad4 > (ad6 used to be the second disk...) > > echo 'LOADER_ZFS_SUPPORT=yes' >> /etc/make.conf > > cd /usr/src > make buildworld && make buildkernel KERNCONF=HEIDI > make installkernel KERNCONF=HEIDI > mergemaster > make installworld > shutdown -r now > > dd if=/dev/zero of=/dev/ad6 bs=512 count=32 > > zpool create tank ad6 > zfs create tank/usr > zfs create tank/var > zfs create -V 4gb tank/swap > zfs set org.freebsd:swap=on tank/swap > zpool set bootfs=tank tank > > rsync -avx / /tank > rsync -avx /usr/ /tank/usr > rsync -avx /var/ /tank/var > cd /usr/src > make installkernel KERNCONF=HEIDI DESTDIR=/tank > > zpool export tank > > dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 > dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 > > zpool import tank > > zfs set mountpoint=legacy tank > zfs set mountpoint=/usr tank/usr > zfs set mountpoint=/var tank/var > > shutdown -r now ... > > at the 'mbr prompt' I pressed F5 (the second disk, ad6) > .. as written above, loader gets loaded (at this stage > I suppose it's the stuff dd't after block 1024?), > but kernel not found. > > /usr/src/sys/i386/conf/HEIDI: > (among other things...): > options KVA_PAGES=512 > > (/tank)/boot/loader.conf: > vm.kmem_size="1024M" > vm.kmem_size_max="1024M" > vfs.zfs.arc_max="128M" > vfs.zfs.vdev.cache.size="8M" > vfs.root.mountfrom="zfs:tank" > > (/tank)/etc/fstab: > # Device Mountpoint FStype Options Dump Pass# > tank / zfs rw 0 0 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > > > > any help is welcome... don't know where to go from here right now. > > BTW: I can't stop thanking the team for the incredible > pace at which bugs are fixed these days! > > > Regards, > > Lorenzo > > > > On 26.05.2009, at 18:42, George Hartzell wrote: > >> Andriy Gapon writes: >>> on 26/05/2009 19:21 George Hartzell said the following: >>>> Dmitry Morozovsky writes: >>>>> On Tue, 26 May 2009, Mickael MAILLOT wrote: >>>>> >>>>> MM> Hi, >>>>> MM> >>>>> MM> i prefere use zfsboot boot sector, an example is better than a >>>>> long talk: >>>>> MM> >>>>> MM> $ zpool create tank mirror ad4 ad6 >>>>> MM> $ zpool export tank >>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 >>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 >>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 >>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 >>>>> >>>>> s/skeep/skip/ ? ;-) >>>> >>>> What is the reason for copying zfsboot one bit at a time, as opposed >>>> to >>>> >>>> dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 >>> >>> seek=1024 for the second part? and no 'count=1' for it? :-) >>> >>> [Just guessing] Apparently the first block of zfsboot is some form of >>> MBR and the >>> rest is zfs-specific code that goes to magical sector 1024. >> >> Ok, I managed to read the argument to seek as "one block", apparently >> my coffee hasn't hit yet. >> >> I'm still confused about the two parts of zfsboot and what's magical >> about seeking to 1024. >> >> g. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 10:22:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D65A1065672; Mon, 1 Jun 2009 10:22:46 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id C31798FC08; Mon, 1 Jun 2009 10:22:45 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 2355C4DA4; Mon, 1 Jun 2009 12:22:45 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n51AMgf2029775; Mon, 1 Jun 2009 12:22:42 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243851764; bh=kzmCRWvfb94/zkyASaqtfGaTWbfeEAiTahWg8tdp7M8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=wPp2VxMR/9U7xio2htR/GVS5TiBVykuVFmqc5nsyZ/XiWc4OmwA4MKSAYOOIfM8NH bnnl9sChq5nFbRJDEy5+A== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=V0JcCjvLq+VuWUZa2Xs3c1Wo1XzUkmAqmLlSk9h7uydETElWkl8m42MCb3EwMTPam WwyiJhTfRxw0oKn0eg4LA== Message-ID: <4A23ABF2.3070601@restart.be> Date: Mon, 01 Jun 2009 12:22:42 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Subject: /boot/loader can't load kernel if too many pool/devices X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 10:22:46 -0000 Hello, During my tests (succesful) to directly boot from ZFS (with zfsboot and gptzfsboot) I encounter the error "can't boot 'kernel'" if too many devices/pools are connected to the machine. In my case: 2 SAS disks with 2 pools 2 SATA disks with 2 pools 1 USB key with one pool `heap` command: Active Allocations: 171/173 536576 bytes reserved 527800 bytes allocated `ls` command: open '/' failed: too many open files If I reboot without the USB key all is OK. If I reboot from the USB key after disconnecting 2 disks all is OK. By the way, the /boot/loader in 7.2-STABLE don't work, complains about forth not found. The previous tests were made with 7.2-STABLE (May 31) with /boot/loader from 8.0-CURRENT. Henri From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 10:27:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBADD106566B for ; Mon, 1 Jun 2009 10:27:13 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 42AD68FC12 for ; Mon, 1 Jun 2009 10:27:13 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 7680E4DBB; Mon, 1 Jun 2009 12:27:12 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n51AR95E029790; Mon, 1 Jun 2009 12:27:09 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243852032; bh=CJXYr9Mdjn7jucow2iQ0dtM+w69tN4wvzckns47hbS8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YQPrvbrHcM3vGy67OtTKq1nDmaVrlREtvYOfsiWFG2NA432Xjlg1aJTldbBjB2n58 LyYiF6p3yvE/ylU7pvB0w== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=Mq2InzISSALLyu3uaFxr1ptqbVXgfUHTThnGaqpXqNS07PJrSRIO/3wAlgFtrJvYA 54ycpl+iOrAVbE59KCZcw== Message-ID: <4A23ACFD.102@restart.be> Date: Mon, 01 Jun 2009 12:27:09 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Lorenzo Perone References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> In-Reply-To: <4A23A81A.5050600@restart.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Mickael MAILLOT , FreeBSD Stable Mailing List Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 10:27:14 -0000 Henri Hennebert wrote: > Lorenzo Perone wrote: >> Hi, >> >> I tried hard... but without success ;( >> >> the result is, when choosing the disk with the zfs boot >> sectors in it (in my case F5, which goes to ad6), the kernel >> is not found. the console shows: >> >> forth not found >> definitions not found >> only not found >> (the above repeated several times) > > This is the file /boot/loader from 7.2-STABLE which is wrong. > > You can find a copy from 8.0-CURRENT and a script that I tested on a USB > key) and is running for me: > > http://verbier.restart.be/xfer/boot-zfs/ > > Put this directory somewhere, eg /tmp/boot-zfs > > and run the script eg: > `cd /tmp/boot-zfs && sh -x make_usb_key.sh da6 kingston` > > good luck CAVEAT: The script put tuning in '/boot/loader.conf' wich imply "options KVA_PAGES=384" in my i386 kernel. Henri > > Henri >> >> can't load 'kernel' >> >> and I get thrown to the loader prompt. >> lsdev does not show any ZFS devices. >> >> Strange thing: if I boot from the other disk, F1, which is my >> ad4 containing the normal ufs system I used to make up the other >> one, and escape to the loader prompt, lsdev actually sees the >> zpool which is on the other disk, and shows: >> zfs0: tank >> >> I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, >> but there I get the panic: free: guard1 fail message. >> (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) >> >> Sure I'm doing something wrong, but what...? Is it a problem that >> the pool is made out of the second disk only (ad6)? >> >> Here are my details (note: latest stable and biosdisk.c merged >> with changes shown in r185095. no problems in buildworld/kernel): >> >> >> >> Machine: p4 4GHz 4 GB RAM (i386) >> >> Note: the pool has actually a different name (heidi >> instead of tank, if this can be of any relevance...), >> just using tank here as it's one of the conventions... >> >> mount (just to show my starting situation) >> >> /dev/mirror/gm0s1a on / (ufs, local) >> devfs on /dev (devfs, local) >> /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) >> /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) >> /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) >> >> gmirror status >> Name Status Components >> mirror/gm0 DEGRADED ad4 >> (ad6 used to be the second disk...) >> >> echo 'LOADER_ZFS_SUPPORT=yes' >> /etc/make.conf >> >> cd /usr/src >> make buildworld && make buildkernel KERNCONF=HEIDI >> make installkernel KERNCONF=HEIDI >> mergemaster >> make installworld >> shutdown -r now >> >> dd if=/dev/zero of=/dev/ad6 bs=512 count=32 >> >> zpool create tank ad6 >> zfs create tank/usr >> zfs create tank/var >> zfs create -V 4gb tank/swap >> zfs set org.freebsd:swap=on tank/swap >> zpool set bootfs=tank tank >> >> rsync -avx / /tank >> rsync -avx /usr/ /tank/usr >> rsync -avx /var/ /tank/var >> cd /usr/src >> make installkernel KERNCONF=HEIDI DESTDIR=/tank >> >> zpool export tank >> >> dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 >> dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 >> >> zpool import tank >> >> zfs set mountpoint=legacy tank >> zfs set mountpoint=/usr tank/usr >> zfs set mountpoint=/var tank/var >> >> shutdown -r now ... >> >> at the 'mbr prompt' I pressed F5 (the second disk, ad6) >> .. as written above, loader gets loaded (at this stage >> I suppose it's the stuff dd't after block 1024?), >> but kernel not found. >> >> /usr/src/sys/i386/conf/HEIDI: >> (among other things...): >> options KVA_PAGES=512 >> >> (/tank)/boot/loader.conf: >> vm.kmem_size="1024M" >> vm.kmem_size_max="1024M" >> vfs.zfs.arc_max="128M" >> vfs.zfs.vdev.cache.size="8M" >> vfs.root.mountfrom="zfs:tank" >> >> (/tank)/etc/fstab: >> # Device Mountpoint FStype Options Dump Pass# >> tank / zfs rw 0 0 >> /dev/acd0 /cdrom cd9660 ro,noauto 0 0 >> >> >> >> any help is welcome... don't know where to go from here right now. >> >> BTW: I can't stop thanking the team for the incredible >> pace at which bugs are fixed these days! >> >> >> Regards, >> >> Lorenzo >> >> >> >> On 26.05.2009, at 18:42, George Hartzell wrote: >> >>> Andriy Gapon writes: >>>> on 26/05/2009 19:21 George Hartzell said the following: >>>>> Dmitry Morozovsky writes: >>>>>> On Tue, 26 May 2009, Mickael MAILLOT wrote: >>>>>> >>>>>> MM> Hi, >>>>>> MM> >>>>>> MM> i prefere use zfsboot boot sector, an example is better than a >>>>>> long talk: >>>>>> MM> >>>>>> MM> $ zpool create tank mirror ad4 ad6 >>>>>> MM> $ zpool export tank >>>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 >>>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 >>>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 >>>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 >>>>>> >>>>>> s/skeep/skip/ ? ;-) >>>>> >>>>> What is the reason for copying zfsboot one bit at a time, as opposed >>>>> to >>>>> >>>>> dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 >>>> >>>> seek=1024 for the second part? and no 'count=1' for it? :-) >>>> >>>> [Just guessing] Apparently the first block of zfsboot is some form >>>> of MBR and the >>>> rest is zfs-specific code that goes to magical sector 1024. >>> >>> Ok, I managed to read the argument to seek as "one block", apparently >>> my coffee hasn't hit yet. >>> >>> I'm still confused about the two parts of zfsboot and what's magical >>> about seeking to 1024. >>> >>> g. >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 10:55:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04CEE1065674 for ; Mon, 1 Jun 2009 10:55:26 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 802DB8FC13 for ; Mon, 1 Jun 2009 10:55:25 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: by ey-out-2122.google.com with SMTP id 22so352329eye.7 for ; Mon, 01 Jun 2009 03:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EyGOTt15oNXgZnFIz3Gy/fZwOiDI+oy3dnwjAtUpr4I=; b=Trj640KU3hStB5JoI11seYavmq2qErLpEmvYqZnkHuCaF2IPd/2eWbXpyfNjc07/Gr sGhnY0TP0BIVIw2WLlFsl0d/19RT1l2NjwZDCaZcCZgbJG4O+a++fZRHR9WhcWTwRIVy pY13C7JAnBHoEZ0Y7A9Lri1/8NDuP8YOcYUzU= 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=hMpxZa0fWMnpFOvx+fvsDzLIKwESLUUtLslSS4GVmkJpu1a1BBzdW/VuXFzx9fKaEF JX/rLOZn207gAI4gDOJ4Roe6+o3v/aCUlf8x4xdlFVfNdkVLcnEEyp8v5TKEGs5cqPCx dajiyFU2YHOxdiNg66yhseAxyV671KRsAME4Q= MIME-Version: 1.0 Received: by 10.210.39.2 with SMTP id m2mr967078ebm.82.1243853724594; Mon, 01 Jun 2009 03:55:24 -0700 (PDT) In-Reply-To: <4A23A81A.5050600@restart.be> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> Date: Mon, 1 Jun 2009 12:55:24 +0200 Message-ID: From: Alberto Villa To: Henri Hennebert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lorenzo Perone , Mickael MAILLOT , FreeBSD Stable Mailing List Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 10:55:26 -0000 On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert wrote: > This is the file /boot/loader from 7.2-STABLE which is wrong. > > You can find a copy from 8.0-CURRENT and a script that I tested on a USB > key) and is running for me: replacing /boot/loader with yours did the job thanks! -- Alberto Villa From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 13:08:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3111065670 for ; Mon, 1 Jun 2009 13:08:36 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3858FC1A for ; Mon, 1 Jun 2009 13:08:33 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so3989604ana.13 for ; Mon, 01 Jun 2009 06:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3NRXWI5bi0M+ZTN8Yik7GEGfuHHCeJcQKq5vFcV95Qw=; b=q5d9i56lSEDyhI5+LOxv15VGHvgTFy6IaJpTLQBeU6Qnx5Q1wEvPBxQ1i2O/fEm4yr Z3VzbLCgcIKYC5tgNbJdL2EnUe5ntRLxoVHaLiH/LdAgrBkU9U5mtnhZixNFi2CJuWKi HD2QZfqW7BIk2yy/KjBaqaTOAnZXy0W3Ft5Bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=e7kLUGpUZSu+tKTAGmtKG9O2EM44gxHYjrNpg2rQdYOEhVfHSpNUoX799cyYWtimHX KrUYv1QLnlkm01tLnIl+pV/mdVVIEWwoKNHPCAjp6oQrskjr65/9o6YgXjDPBhOcVO5y DhVg63omKyv9h0CekFEYTcApMRluiddVNEho0= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.105.15 with SMTP id d15mr6999808anc.140.1243861713365; Mon, 01 Jun 2009 06:08:33 -0700 (PDT) In-Reply-To: References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> Date: Mon, 1 Jun 2009 06:08:33 -0700 X-Google-Sender-Auth: 5057e1398319c1ae Message-ID: <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> From: Kip Macy To: Alberto Villa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Henri Hennebert , Lorenzo Perone , Mickael MAILLOT , FreeBSD Stable Mailing List Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 13:08:36 -0000 Odds are that there are more changes that were made in HEAD to the loader that need to be MFC'd. -Kip On Mon, Jun 1, 2009 at 3:55 AM, Alberto Villa wrote: > On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert wrote: >> This is the file /boot/loader from 7.2-STABLE which is wrong. >> >> You can find a copy from 8.0-CURRENT and a script that I tested on a USB >> key) and is running for me: > > replacing /boot/loader with yours did the job > thanks! > -- > Alberto Villa > _______________________________________________ > 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" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 15:07:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 241DB106566B; Mon, 1 Jun 2009 15:07:56 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D48528FC15; Mon, 1 Jun 2009 15:07:54 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA06754; Mon, 01 Jun 2009 18:07:52 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A23EEC8.2040208@freebsd.org> Date: Mon, 01 Jun 2009 18:07:52 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, Henri Hennebert References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> In-Reply-To: <4A1FD687.5070502@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kip Macy , John Baldwin Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 15:07:56 -0000 on 29/05/2009 15:35 Andriy Gapon said the following: > So anyone else feels that this is a bug? > > on 28/05/2009 16:55 Andriy Gapon said the following: >> on 28/05/2009 16:26 Henri Hennebert said the following: >>> (gdb) bt >>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >> I find the above part interesting. >> Could this be because of the following discrepancy: >> >> 1) >> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >> extern void __assert(const char *, const char *, int); >> 2) >> lib/libc/gen/assert.c: >> void >> __assert(func, file, line, failedexpr) >> const char *func, *file; >> int line; >> const char *failedexpr; >> >>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1 I propose the following patch for this issue. It fixes mismatch between __assert extern declaration in zfs code and actual signature in libc code. I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that those checks are not needed with compilers that can be used to compile FreeBSD. Besides, both branches of __STDC_VERSION__ check were exactly the same. Henri, if you still experience that crash of zpool command, could you please try the patch and see if you have a nicer assert message and stacktrace now? Sorry, that this is still not a fix for the real issue. diff --git a/cddl/contrib/opensolaris/head/assert.h b/cddl/contrib/opensolaris/head/assert.h index 394820a..c2a4936 100644 --- a/cddl/contrib/opensolaris/head/assert.h +++ b/cddl/contrib/opensolaris/head/assert.h @@ -37,15 +37,7 @@ extern "C" { #endif -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -extern void __assert(const char *, const char *, int); -#else -extern void __assert(const char *, const char *, int); -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -extern void _assert(); -#endif +extern void __assert(const char *, const char *, int, const char *); #ifdef __cplusplus } @@ -68,14 +60,6 @@ extern void _assert(); #else -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #endif /* NDEBUG */ diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h index 7ae7f9d..631e302 100644 --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); #define fm_panic panic /* This definition is copied from assert.h. */ -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ - +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #define VERIFY verify #define ASSERT assert -extern void __assert(const char *, const char *, int); +extern void __assert(const char *, const char *, int, const char *); #ifdef lint #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ #LEFT, #OP, #RIGHT, \ (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ - __assert(__buf, __FILE__, __LINE__); \ + __assert(__func__, __FILE__, __LINE__, __buf); \ } \ _NOTE(CONSTCOND) } while (0) /* END CSTYLED */ -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 15:34:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 453DC1065676 for ; Mon, 1 Jun 2009 15:34:04 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id CF2808FC16 for ; Mon, 1 Jun 2009 15:34:03 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by bwz9 with SMTP id 9so7724710bwz.43 for ; Mon, 01 Jun 2009 08:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.112.204 with SMTP id x12mr3263188fap.70.1243870442714; Mon, 01 Jun 2009 08:34:02 -0700 (PDT) From: Vlad Galu Date: Mon, 1 Jun 2009 18:33:42 +0300 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Unnamed POSIX shared semaphores X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 15:34:04 -0000 Hello, According to sem_init(3), we can't have shared unnamed semaphores. However, the following code snippet seems to work just fine: -- cut here -- sem_t semaphore; if (sem_init(&semaphore, 1, 10) < 0) std::cout << "Couldn't init semaphore: " << strerror(errno) << std::endl; if (sem_wait(&semaphore) < 0) std::cout << "Couldn't decrement semaphore: " << strerror(errno) << std::endl; int val; sem_getvalue(&semaphore, &val); std::cout << "Value is " << val << std::endl; -- and here -- Is this a case where sem_init() silently reports success, or should be the man page get an update? Thanks, Vlad From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 15:58:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C1B01065675 for ; Mon, 1 Jun 2009 15:58:17 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id B39D68FC13 for ; Mon, 1 Jun 2009 15:58:11 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 9554634D84; Mon, 1 Jun 2009 17:48:08 +0200 (CEST) Date: Mon, 1 Jun 2009 17:48:07 +0200 From: cpghost To: Vlad Galu Message-ID: <20090601154807.GB6065@phenom.cordula.ws> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: Unnamed POSIX shared semaphores X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 15:58:18 -0000 On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote: > Hello, > > According to sem_init(3), we can't have shared unnamed semaphores. > However, the following code snippet seems to work just fine: > > -- cut here -- > sem_t semaphore; > if (sem_init(&semaphore, 1, 10) < 0) > std::cout << "Couldn't init semaphore: " << > strerror(errno) << std::endl; > if (sem_wait(&semaphore) < 0) > std::cout << "Couldn't decrement semaphore: " << > strerror(errno) << std::endl; > int val; > sem_getvalue(&semaphore, &val); > std::cout << "Value is " << val << std::endl; > -- and here -- > > Is this a case where sem_init() silently reports success, or should be > the man page get an update? You may want to read the comments in /usr/src/lib/libc/gen/sem.c regarding sem_init(). But yes, the man page is somewhat unclear and I'm not sure the last paragraph is still totally accurate. > Thanks, > Vlad -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 16:12:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A10106566C; Mon, 1 Jun 2009 16:12:30 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id BD82F8FC12; Mon, 1 Jun 2009 16:12:29 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id D85754646; Mon, 1 Jun 2009 18:12:28 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n51GCL6G004077; Mon, 1 Jun 2009 18:12:22 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243872748; bh=nJ53m1JzHDZ21Cow2qHSjdl9aZsUVcLmIJ0dd9512L0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Yge48f3PMKBpD6g39Jr7VeCS/veYGRyE0O5FhR2k4SdNnLDRC0AzKq8aMLuwRW8km H2WhQNO+I3x/mwqqTqdwQ== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=jRJRY/SPh3zmqbx3KUxMWeyyj0XIdpLrVLJmOUYK72fWZNZDEGQauBDfHktrK3OB4 VKNxAgR1iMJ5rsxjMTpIw== Message-ID: <4A23FDE5.1040101@restart.be> Date: Mon, 01 Jun 2009 18:12:21 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Andriy Gapon References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> In-Reply-To: <4A23EEC8.2040208@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Kip Macy , John Baldwin Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 16:12:30 -0000 Andriy Gapon wrote: > on 29/05/2009 15:35 Andriy Gapon said the following: >> So anyone else feels that this is a bug? >> >> on 28/05/2009 16:55 Andriy Gapon said the following: >>> on 28/05/2009 16:26 Henri Hennebert said the following: >>>> (gdb) bt >>>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >>> I find the above part interesting. >>> Could this be because of the following discrepancy: >>> >>> 1) >>> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >>> extern void __assert(const char *, const char *, int); >>> 2) >>> lib/libc/gen/assert.c: >>> void >>> __assert(func, file, line, failedexpr) >>> const char *func, *file; >>> int line; >>> const char *failedexpr; >>> >>>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1 > > I propose the following patch for this issue. > It fixes mismatch between __assert extern declaration in zfs code and actual > signature in libc code. > I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that > those checks are not needed with compilers that can be used to compile FreeBSD. > Besides, both branches of __STDC_VERSION__ check were exactly the same. > > Henri, > > if you still experience that crash of zpool command, could you please try the > patch and see if you have a nicer assert message and stacktrace now? > Sorry, that this is still not a fix for the real issue. > > diff --git a/cddl/contrib/opensolaris/head/assert.h > b/cddl/contrib/opensolaris/head/assert.h > index 394820a..c2a4936 100644 > --- a/cddl/contrib/opensolaris/head/assert.h > +++ b/cddl/contrib/opensolaris/head/assert.h > @@ -37,15 +37,7 @@ > extern "C" { > #endif > > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -extern void __assert(const char *, const char *, int); > -#else > -extern void __assert(const char *, const char *, int); > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -extern void _assert(); > -#endif > +extern void __assert(const char *, const char *, int, const char *); > > #ifdef __cplusplus > } > @@ -68,14 +60,6 @@ extern void _assert(); > > #else > > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#else > -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) > -#endif /* __STDC__ */ > +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) > > #endif /* NDEBUG */ > diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > index 7ae7f9d..631e302 100644 > --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); > #define fm_panic panic > > /* This definition is copied from assert.h. */ > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#else > -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) > -#endif /* __STDC__ */ > - > +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) > > #define VERIFY verify > #define ASSERT assert > > -extern void __assert(const char *, const char *, int); > +extern void __assert(const char *, const char *, int, const char *); > > #ifdef lint > #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) > @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); > (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ > #LEFT, #OP, #RIGHT, \ > (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ > - __assert(__buf, __FILE__, __LINE__); \ > + __assert(__func__, __FILE__, __LINE__, __buf); \ > } \ > _NOTE(CONSTCOND) } while (0) > /* END CSTYLED */ > > Here is the new bt after the patch [root@avoriaz libzpool]# gdb zdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) r pool1 Starting program: /usr/sbin/zdb pool1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100178] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100178)] [New Thread 0x801802240 (LWP 100345)] version=13 name='pool1' state=0 txg=4 pool_guid=9156958376606789 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=9156958376606789 children[0] type='raidz' id=0 guid=8214939615613279020 nparity=1 metaslab_array=23 metaslab_shift=32 ashift=9 asize=500108886016 is_log=0 children[0] type='disk' id=0 guid=7001907692988243779 path='/dev/ad8p2' whole_disk=0 children[1] type='disk' id=1 guid=1909032920962573263 path='/dev/ad10p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100346)] [New Thread 0x801802560 (LWP 100347)] [New Thread 0x8018026f0 (LWP 100348)] [New Thread 0x801802880 (LWP 100349)] [New Thread 0x801802a10 (LWP 100350)] [New Thread 0x801802ba0 (LWP 100351)] [New Thread 0x801802d30 (LWP 100352)] [New Thread 0x801802ec0 (LWP 100353)] [New Thread 0x801803050 (LWP 100354)] [New Thread 0x8018031e0 (LWP 100355)] [New Thread 0x801803370 (LWP 100356)] [New Thread 0x801803500 (LWP 100357)] [New Thread 0x801803690 (LWP 100358)] [New Thread 0x801803820 (LWP 100359)] [New Thread 0x8018039b0 (LWP 100360)] [New Thread 0x801803b40 (LWP 100361)] [New Thread 0x801803cd0 (LWP 100362)] [New Thread 0x801803e60 (LWP 100363)] [New Thread 0x801803ff0 (LWP 100364)] [New Thread 0x801804180 (LWP 100365)] [New Thread 0x801804310 (LWP 100366)] [New Thread 0x8018044a0 (LWP 100367)] [New Thread 0x801804630 (LWP 100368)] [New Thread 0x8018047c0 (LWP 100369)] [New Thread 0x801804950 (LWP 100370)] [New Thread 0x801804ae0 (LWP 100371)] Assertion failed: (mp->m_owner == NULL), function zmutex_destroy, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Program received signal SIGABRT, Aborted. [Switching to Thread 0x8018020b0 (LWP 100178)] 0x000000080121fadc in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000000080121fadc in thr_kill () from /lib/libc.so.7 #1 0x00000008012af06b in abort () from /lib/libc.so.7 #2 0x0000000801296fe5 in __assert () from /lib/libc.so.7 #3 0x0000000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c:112 #4 0x0000000801030287 in dsl_dataset_evict (db=Variable "db" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:266 #5 0x0000000801048b61 in dbuf_evict_user (db=0x8018ca960) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:215 #6 0x000000080104a8c3 in dbuf_rele (db=0x8018ca960, tag=Variable "tag" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1739 #7 0x0000000801029276 in dsl_pool_open (spa=0x8018a2000, txg=Variable "txg" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:139 #8 0x000000080101d503 in spa_load (spa=0x8018a2000, config=Variable "config" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1134 #9 0x000000080101e060 in spa_open_common (pool=0x7fffffffed6e "pool1", spapp=0x7fffffffeb08, tag=0x40b790, config=0x0) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1474 #10 0x0000000000408b41 in ?? () #11 0x00000000004036de in ?? () #12 0x0000000800534000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000002 in ?? () #15 0x00007fffffffed60 in ?? () #16 0x00007fffffffed6e in ?? () #17 0x0000000000000000 in ?? () #18 0x00007fffffffed74 in ?? () #19 0x00007fffffffed8a in ?? () #20 0x00007fffffffed95 in ?? () #21 0x00007fffffffedaf in ?? () #22 0x00007fffffffedda in ?? () #23 0x00007fffffffedf7 in ?? () #24 0x00007fffffffee0a in ?? () #25 0x00007fffffffee14 in ?? () #26 0x00007fffffffee1f in ?? () #27 0x00007fffffffee2b in ?? () #28 0x00007fffffffee40 in ?? () #29 0x00007fffffffee54 in ?? () #30 0x00007fffffffeeae in ?? () #31 0x00007fffffffeebd in ?? () #32 0x00007fffffffeec9 in ?? () #33 0x00007fffffffeee8 in ?? () #34 0x00007fffffffeef5 in ?? () #35 0x00007fffffffef0a in ?? () #36 0x00007fffffffef1c in ?? () #37 0x00007fffffffef25 in ?? () #38 0x00007fffffffef35 in ?? () #39 0x00007fffffffef3d in ?? () #40 0x00007fffffffef66 in ?? () #41 0x00007fffffffef73 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000003 in ?? () #44 0x0000000000400040 in ?? () #45 0x0000000000000004 in ?? () #46 0x0000000000000038 in ?? () #47 0x0000000000000005 in ?? () #48 0x0000000000000007 in ?? () #49 0x0000000000000006 in ?? () #50 0x0000000000001000 in ?? () #51 0x0000000000000008 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000009 in ?? () #54 0x0000000000403650 in ?? () #55 0x0000000000000007 in ?? () #56 0x000000080050c000 in ?? () #57 0x0000000000000000 in ?? () ---Type to continue, or q to quit---q Quit (gdb) q The program is running. Exit anyway? (y or n) yes [root@avoriaz libzpool]# Henri From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 16:19:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5841010657AD for ; Mon, 1 Jun 2009 16:19:19 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 13C358FC1F for ; Mon, 1 Jun 2009 16:19:19 +0000 (UTC) (envelope-from jilles@stack.nl) Received: by mx1.stack.nl (Postfix, from userid 65534) id 66BC635994D; Mon, 1 Jun 2009 18:19:18 +0200 (CEST) X-Spam-DCC: z.dcc-servers: scanner01.stack.nl 1049; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on scanner01.stack.nl X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Relay-Country: _RELAYCOUNTRY_ Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 162B135993C; Mon, 1 Jun 2009 18:19:16 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 66B17228BC; Mon, 1 Jun 2009 18:19:03 +0200 (CEST) Date: Mon, 1 Jun 2009 18:19:03 +0200 From: Jilles Tjoelker To: Vlad Galu Message-ID: <20090601161903.GA40377@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Unnamed POSIX shared semaphores X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 16:19:20 -0000 On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote: > According to sem_init(3), we can't have shared unnamed semaphores. > However, the following code snippet seems to work just fine: > -- cut here -- > sem_t semaphore; > if (sem_init(&semaphore, 1, 10) < 0) > std::cout << "Couldn't init semaphore: " << > strerror(errno) << std::endl; > if (sem_wait(&semaphore) < 0) > std::cout << "Couldn't decrement semaphore: " << > strerror(errno) << std::endl; > int val; > sem_getvalue(&semaphore, &val); > std::cout << "Value is " << val << std::endl; > -- and here -- > Is this a case where sem_init() silently reports success, or should be > the man page get an update? Reading the code, it seems like this should work, but only between related processes where the parent process creates the semaphore before forking and no exec is done. This is because a sem_t is a pointer to a structure containing the kernel level semid_t (and a mutex, condvar and the like for process-private semaphores). sem_init() will allocate this structure using malloc(3). Changing sem_t to be a structure would be the obvious way to fix this, but I think this cannot be versioned properly. For example, if someone puts in the public header file of their .so: struct my_struct { int foo; sem_t bar; int quux; }; Changing the size of sem_t will break this. Also, assuming symbol versioning were to be used, if you compile the .so for FreeBSD 7 and the app for FreeBSD 8, the FreeBSD 8 sem_* functions will get FreeBSD 7 style sem_t's. If process-shared semaphores really work, then the above structure is not a pathological case. Effectively, sem_t is carved in stone. So process-private semaphores should continue to have most of their stuff in a separately allocated structure, to preserve flexibility. Perhaps a better method is to set bit 0 of the sem_t to 1 and use the other bits to store the semid_t. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 16:23:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89DA110656DA; Mon, 1 Jun 2009 16:23:03 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 355518FC1C; Mon, 1 Jun 2009 16:23:01 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08334; Mon, 01 Jun 2009 19:22:59 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A240063.207@freebsd.org> Date: Mon, 01 Jun 2009 19:22:59 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Henri Hennebert References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> In-Reply-To: <4A23FDE5.1040101@restart.be> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Kip Macy , John Baldwin Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 16:23:04 -0000 on 01/06/2009 19:12 Henri Hennebert said the following: > Andriy Gapon wrote: >> I propose the following patch for this issue. >> It fixes mismatch between __assert extern declaration in zfs code and >> actual >> signature in libc code. >> I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. >> I think that >> those checks are not needed with compilers that can be used to compile >> FreeBSD. >> Besides, both branches of __STDC_VERSION__ check were exactly the same. >> >> Henri, >> >> if you still experience that crash of zpool command, could you please >> try the >> patch and see if you have a nicer assert message and stacktrace now? >> Sorry, that this is still not a fix for the real issue. >> > Here is the new bt after the patch Henri, thank you very much for testing! It look like the patch did its job. P.S. hopefully someone is looking into the cause of the assertion. > Assertion failed: (mp->m_owner == NULL), function zmutex_destroy, file > /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, > line 112. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x8018020b0 (LWP 100178)] > 0x000000080121fadc in thr_kill () from /lib/libc.so.7 > (gdb) bt > #0 0x000000080121fadc in thr_kill () from /lib/libc.so.7 > #1 0x00000008012af06b in abort () from /lib/libc.so.7 > #2 0x0000000801296fe5 in __assert () from /lib/libc.so.7 > #3 0x0000000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 17:10:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 116E71065672 for ; Mon, 1 Jun 2009 17:10:01 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id 9234F8FC15 for ; Mon, 1 Jun 2009 17:10:00 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from [192.168.178.21] ([85.181.128.36]) (AUTH: CRAM-MD5 lopez.on.the.lists@yellowspace.net, TLS: TLSv1/SSLv3, 128bits, AES128-SHA) by mail.yellowspace.net with esmtp; Mon, 01 Jun 2009 19:09:56 +0200 id 00495B26.000000004A240B64.00010E5C Message-Id: From: Lorenzo Perone To: Adam McDougall In-Reply-To: <20090531071759.GA35763@egr.msu.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 1 Jun 2009 19:09:55 +0200 References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <63548432-B73D-4A08-BA99-FEF5BCC1028A@yellowspace.net> <20090531071759.GA35763@egr.msu.edu> X-Mailer: Apple Mail (2.930.3) Cc: Mickael MAILLOT , FreeBSD Stable Mailing List Subject: Re: ZFS booting without partitions (was: ZFS boot on zfs mirror) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 17:10:01 -0000 On 31.05.2009, at 09:18, Adam McDougall wrote: > I encountered the same symptoms today on both a 32bit and 64bit > brand new install using gptzfsboot. It works for me when I use > a copy of loader from an 8-current box with zfs support compiled in. > I haven't looked into it much yet but it might help you. If you > want, you can try the loader I am using from: > http://www.egr.msu.edu/~mcdouga9/loader Hi, thanx a lot for this hint. Meanwhile, I was almost giving up, and had a try with ZFS on Root with GPT partitioning, using gptzfsboot as the bootloader, a UFS root partition as boot partition (gmirrored to both disks), and the rest (inclusive of a zvol for swap!) on ZFS. This worked perfectly on the first try. (if anyone is interested, I can post my commented command series for that, but it's just a mix of the available tutorials on the web..). I'll be glad do give the zfs-only solution a new try. Had the same impression, that the loader was involved in the problem, but had no env at hand to build a -CURRENT right away... (I did, in fact, repeat the dd-steps a zfsboot bootloader from a recent 8- snapshot iso... with the results being the same as before...). Sidenote: I encountered a few panics when using rsync with the HAX flags enabled (rsync -avxHAX from UFS to ZFS). I'll try to figure out which one of the flags caused it... (Hard links, ACLs, or eXtended attributes..). Never had even the slightest problem with rsync -avx. Thanx for posting me your loader, I'll try with this tomorrow night! (any hint, btw, on why the one in -STABLE seems to be broken, or whether it has actually been fixed by now?) Regards, Lorenzo > (...) > >> 2009/5/28 Lorenzo Perone: >>> Hi, >>> >>> I tried hard... but without success ;( >>> >>> the result is, when choosing the disk with the zfs boot >>> sectors in it (in my case F5, which goes to ad6), the kernel >>> is not found. the console shows: >>> >>> forth not found >>> definitions not found >>> only not found >>> (the above repeated several times) >>> >>> can't load 'kernel' >>> >>> and I get thrown to the loader prompt. >>> lsdev does not show any ZFS devices. >>> >>> (...) From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 17:21:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACBE51065677; Mon, 1 Jun 2009 17:21:28 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 778E28FC1B; Mon, 1 Jun 2009 17:21:28 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id EF8F171F4FD; Mon, 1 Jun 2009 13:21:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYyk7P3qh2BK; Mon, 1 Jun 2009 13:21:27 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id AB67371F4E6; Mon, 1 Jun 2009 13:21:27 -0400 (EDT) Message-ID: <4A240E17.30907@egr.msu.edu> Date: Mon, 01 Jun 2009 13:21:27 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 To: Kip Macy References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> In-Reply-To: <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Henri Hennebert , Lorenzo Perone , Mickael MAILLOT , FreeBSD Stable Mailing List , Alberto Villa Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 17:21:29 -0000 I'm thinking that too. I spent some time taking stabs at figuring it out yesterday but didn't get anywhere useful. I did try compiling the -current src/sys/boot tree on 7.2 after a couple header tweaks to make it compile but the loader still didn't work. The working loader is the same file size as the broken loader unless it was compiled on i386 and then it is ~30k bigger for some reason (it shrinks to the same size as the rest if I force it to use the same 32bit compilation flags as used on amd64). Just mentioning this in case it saves someone else some time. I'm real pleased it works at all. Kip Macy wrote: > Odds are that there are more changes that were made in HEAD to the > loader that need to be MFC'd. > > -Kip > > On Mon, Jun 1, 2009 at 3:55 AM, Alberto Villa wrote: > >> On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert wrote: >> >>> This is the file /boot/loader from 7.2-STABLE which is wrong. >>> >>> You can find a copy from 8.0-CURRENT and a script that I tested on a USB >>> key) and is running for me: >>> >> replacing /boot/loader with yours did the job >> thanks! >> -- >> Alberto Villa >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > > > From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 17:33:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666581065677 for ; Mon, 1 Jun 2009 17:33:54 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.17]) by mx1.freebsd.org (Postfix) with ESMTP id F2CE58FC1A for ; Mon, 1 Jun 2009 17:33:53 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp19.orange.fr (mwinf1928 [172.22.129.128]) by mwinf1915.orange.fr (SMTP Server) with ESMTP id 1894D1C00A76 for ; Mon, 1 Jun 2009 18:42:17 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1928.orange.fr (SMTP Server) with ESMTP id 8C53320000B4; Mon, 1 Jun 2009 18:42:15 +0200 (CEST) Received: from localhost (AToulouse-156-1-35-193.w81-49.abo.wanadoo.fr [81.49.90.193]) by mwinf1928.orange.fr (SMTP Server) with ESMTP id A6AD420000AD; Mon, 1 Jun 2009 18:42:14 +0200 (CEST) X-ME-UUID: 20090601164214682.A6AD420000AD@mwinf1928.orange.fr Message-ID: <4A2404E5.7010104@orange.fr> Date: Mon, 01 Jun 2009 18:42:13 +0200 From: Claude Buisson User-Agent: Thunderbird 2.0.0.21 (X11/20090420) MIME-Version: 1.0 To: Daniel O'Connor References: <20090531191456.M33035@onet.com.ua> <200906010940.26300.doconnor@gsoft.com.au> In-Reply-To: <200906010940.26300.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pavel Greenberg , freebsd-stable@freebsd.org Subject: Re: buildworld fails with "WITHOUT_CDDL=yes" in src.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 17:33:55 -0000 Daniel O'Connor wrote: > On Mon, 1 Jun 2009, Pavel Greenberg wrote: >> Hello everybody! >> After today's source update I have a problem when doing make >> buildworld: >> >> cc -O2 -fno-strict-aliasing -pipe -march=pentium4 >> -DLOADER_NFS_SUPPORT - DBOOT_FORTH >> -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/ >> i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT >> -DLOADER_GPT_SUPPORT -I/usr/ src/sys/boot/i386/loader/../../common >> -I. -Wall -I/usr/src/sys/boot/i386/ loader/.. >> -I/usr/src/sys/boot/i386/loader/../btx/lib -ffreestanding - >> mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >> -mno- sse3 -c >> /usr/src/sys/boot/i386/loader/../../common/interp_forth.c make: don't >> know how to make /usr/obj/usr/src/tmp/usr/lib/libzfs.a. Stop *** >> Error code 2 >> >> Stop in /usr/src/sys/boot/i386. >> *** Error code 1 >> >> Stop in /usr/src/sys/boot. >> *** Error code 1 >> >> Stop in /usr/src/sys. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> >> In my src.conf I have options >> WITHOUT_CDDL= true >> WITHOUT_ZFS= true >> because I don't use ZFS, my desktop haven't enought resources for it >> and I want not to build it. When I updated my OS some weeks ago with >> the same src.conf process ended OK. > > While the above IS a bug it should be pointed out that unless you > actually load the ZFS kld it won't use any memory on your system. > Same here.. The first bug is the use of a LIBZFS variable in src/sys/boot/i386/loader/Makefile, as this variable is set in share/mk/bsd.libnames.mk I just replaced LIBZFS by LIBZFSBOOT and the buildworld succeeded. The second bug is the use of LOADER_ZFS_SUPPORT without any consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) I won't comment the "it won't use any memory on your system".. Claude Buisson From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 17:48:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EA98106567A for ; Mon, 1 Jun 2009 17:48:58 +0000 (UTC) (envelope-from enricom@teppisti.it) Received: from smtp-out112.alice.it (smtp-out112.alice.it [85.37.17.112]) by mx1.freebsd.org (Postfix) with ESMTP id 096FD8FC1F for ; Mon, 1 Jun 2009 17:48:57 +0000 (UTC) (envelope-from enricom@teppisti.it) Received: from FBCMMO02.fbc.local ([192.168.68.196]) by smtp-out112.alice.it with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Jun 2009 19:48:56 +0200 Received: from FBCMCL01B07.fbc.local ([192.168.171.45]) by FBCMMO02.fbc.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jun 2009 19:48:55 +0200 Received: from hal.homeunix.net ([79.3.233.253]) by FBCMCL01B07.fbc.local with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Jun 2009 19:48:55 +0200 From: "Enrico M." To: freebsd-stable@freebsd.org Date: Mon, 1 Jun 2009 19:48:57 +0200 User-Agent: KMail/1.11.3 (FreeBSD/7.2-RELEASE; KDE/4.2.3; i386; ; ) References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A23A81A.5050600@restart.be> In-Reply-To: <4A23A81A.5050600@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906011948.58095.enricom@teppisti.it> X-OriginalArrivalTime: 01 Jun 2009 17:48:55.0170 (UTC) FILETIME=[3B91CE20:01C9E2E1] Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 17:48:59 -0000 On Monday 01 June 2009 12:06:18 Henri Hennebert wrote: > Lorenzo Perone wrote: > > Hi, > > > > I tried hard... but without success ;( > > > > the result is, when choosing the disk with the zfs boot > > sectors in it (in my case F5, which goes to ad6), the kernel > > is not found. the console shows: > > > > forth not found > > definitions not found > > only not found > > (the above repeated several times) > > This is the file /boot/loader from 7.2-STABLE which is wrong. > > You can find a copy from 8.0-CURRENT and a script that I tested on a USB > key) and is running for me: > > http://verbier.restart.be/xfer/boot-zfs/ Thanks! I replaced /boot/loader with the file from your link. Now the system boot. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 21:17:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A278B106566C for ; Mon, 1 Jun 2009 21:17:50 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 756B78FC08 for ; Mon, 1 Jun 2009 21:17:50 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DC11C34C7DB; Mon, 1 Jun 2009 17:17:49 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 01 Jun 2009 17:17:49 -0400 X-Sasl-enc: z0o0Y09Zkqpa9XSF8xamDa2BhOeuP7fZkvAprii1PTOV 1243891069 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 49DCE46056; Mon, 1 Jun 2009 17:17:49 -0400 (EDT) Message-ID: <4A24457C.6060100@FreeBSD.org> Date: Mon, 01 Jun 2009 22:17:48 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Jilles Tjoelker References: <20090601161903.GA40377@stack.nl> In-Reply-To: <20090601161903.GA40377@stack.nl> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vlad Galu , freebsd-stable@freebsd.org Subject: Re: Unnamed POSIX shared semaphores X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 21:17:51 -0000 Jilles Tjoelker wrote: > If process-shared semaphores really work, then the above structure is > not a pathological case. Effectively, sem_t is carved in stone. So > process-private semaphores should continue to have most of their stuff > in a separately allocated structure, to preserve flexibility. > There was an inadvertent race in FreeBSD's POSIX semaphores which I fixed in HEAD and STABLE about 6 weeks before 7.2 was released. I believe process-shared POSIX semaphores now work -- the Python 'multiprocessing' regression test now runs to completion with no errors on both HEAD and STABLE. cheers, BMS From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 21:44:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 270A0106566C; Mon, 1 Jun 2009 21:44:29 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D38028FC0A; Mon, 1 Jun 2009 21:44:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n51LUSsC009712; Mon, 1 Jun 2009 17:30:28 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 01 Jun 2009 17:30:28 -0400 (EDT) Date: Mon, 1 Jun 2009 17:30:28 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Bruce Simpson In-Reply-To: <4A24457C.6060100@FreeBSD.org> Message-ID: References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Vlad Galu , freebsd-stable@freebsd.org, Jilles Tjoelker Subject: Re: Unnamed POSIX shared semaphores X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 21:44:29 -0000 On Mon, 1 Jun 2009, Bruce Simpson wrote: > Jilles Tjoelker wrote: >> If process-shared semaphores really work, then the above structure is >> not a pathological case. Effectively, sem_t is carved in stone. So >> process-private semaphores should continue to have most of their stuff >> in a separately allocated structure, to preserve flexibility. >> > > There was an inadvertent race in FreeBSD's POSIX semaphores which I fixed in > HEAD and STABLE about 6 weeks before 7.2 was released. > > I believe process-shared POSIX semaphores now work -- the Python > 'multiprocessing' regression test now runs to completion with no errors on > both HEAD and STABLE. Process-shared semaphores, mutexes, etc, will never work until their public types are structs, not pointers to structs (i.e. allocated by our library functions). The intrinsic *kernel* semaphore functions (ksem) supposedly do support process-shared semantics, but our POSIX functions' use of them cannot be shared across processes. -- DE From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 22:15:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F308106566C for ; Mon, 1 Jun 2009 22:15:41 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id B29178FC08 for ; Mon, 1 Jun 2009 22:15:40 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so4156457ana.13 for ; Mon, 01 Jun 2009 15:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=IQVfPXQWHK53b+RWwyY9FutGwFTmhLKQ61U7uV+bg9s=; b=e+KfAQ40Yb3QcRiIO7GXp3TKwx7yIoxO99svWj9N56giAalNIMlHgEcgVcBvTeeCXG g4pwEyELhNz7VcegFyX2+/92WE6J3V2oHetwsG1/uhUOTguXM1a30bDJHdzM8EKpRWNc cwiszvWlnNEzlePtYWuEd8UD4RV/Q4QycWJfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wK5O2Qat/+Xa4FWL8qyDsCj/gsiZWwcnED/WHZgq/1fBHDdku4v0mDzOVAecZMpg5s 1aAIjdtNQ96Cpts5GWOJHD+z+aatlsCg2CgS48exJbnRVOwxIAWwjEBa3bWHZYE0lRUQ k1qHfMMm61PClkDPKnFPgXZUeLMEocg4F3KKs= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.143.17 with SMTP id q17mr7748041and.114.1243894539946; Mon, 01 Jun 2009 15:15:39 -0700 (PDT) In-Reply-To: <4A240E17.30907@egr.msu.edu> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> <4A240E17.30907@egr.msu.edu> Date: Mon, 1 Jun 2009 15:15:39 -0700 X-Google-Sender-Auth: 7101639e281604ce Message-ID: <3c1674c90906011515r5f706fdfl570e17a3c90f169f@mail.gmail.com> From: Kip Macy To: Adam McDougall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Henri Hennebert , Lorenzo Perone , Mickael MAILLOT , FreeBSD Stable Mailing List , Alberto Villa Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 22:15:41 -0000 On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall wrot= e: > I'm thinking that too. =A0I spent some time taking stabs at figuring it o= ut > yesterday but didn't get anywhere useful. =A0I did try compiling the -cur= rent > src/sys/boot tree on 7.2 after a couple header tweaks to make it compile = but > the loader still didn't work. =A0The working loader is the same file size= as > the broken loader unless it was compiled on i386 and then it is ~30k bigg= er > for some reason (it shrinks to the same size as the rest if I force it to > use the same 32bit compilation flags as used on amd64). =A0Just mentionin= g > this in case it saves someone else some time. =A0I'm real pleased it work= s at > all. If someone has the time to track down the differences I'll MFC them. I'm not using ZFS boot at the moment so I have no way of testing. Cheers, Kip From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 22:19:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50AE11065674 for ; Mon, 1 Jun 2009 22:19:01 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id AFB548FC0A for ; Mon, 1 Jun 2009 22:18:55 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so4149123ywe.13 for ; Mon, 01 Jun 2009 15:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=7JdjCT2pHR2VclLrVsGeh5AIfneMgIMoJLDSubjfhKo=; b=BSOcCiMvMB66Sm6NbdpS3onlpbkxACAtF0F/qOjwmBVXYcuadXOuevMPBDLzast9Xm DKkMlDu1HGZuKAvp9gT19ALYNNpDQiIuO8KloHHNz+Z5GLz982E2KU6vYuxvebzZ7GUX JutxvlH7MVVZLm7Gl+ceia8UABNQ39VEl1tHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=lpFOxv7JXlj+a5UKBOLzIAR6loLOlYl47iPPnUqJ8c8huapBscDsSsSp/OfXrIKJfR Qfsf4E6BxH4Rjav4ipev9I7Za/UU30oXdc00GvdojAwWh/C26efL6dRR9+ZNLAyd7nbh mI/MMZ7nlmxy+gEGCqWImc3a834aHrgbNL4ss= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.197.2 with SMTP id u2mr5308182anf.192.1243894731361; Mon, 01 Jun 2009 15:18:51 -0700 (PDT) In-Reply-To: <4A2404E5.7010104@orange.fr> References: <20090531191456.M33035@onet.com.ua> <200906010940.26300.doconnor@gsoft.com.au> <4A2404E5.7010104@orange.fr> Date: Mon, 1 Jun 2009 15:18:51 -0700 X-Google-Sender-Auth: f040c9bcde73ba12 Message-ID: <3c1674c90906011518k6d680125hf4b4d7608c92de44@mail.gmail.com> From: Kip Macy To: Claude Buisson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Pavel Greenberg Subject: Re: buildworld fails with "WITHOUT_CDDL=yes" in src.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jun 2009 22:19:01 -0000 > Same here.. > > The first bug is the use of a LIBZFS variable in > src/sys/boot/i386/loader/Makefile, as this variable is set in > share/mk/bsd.libnames.mk > > I just replaced LIBZFS by LIBZFSBOOT and the buildworld succeeded. > > The second bug is the use of LOADER_ZFS_SUPPORT without any > consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) > > I won't comment the "it won't use any memory on your system".. > I'll try get it fixed by Wednesday. Thanks, Kip From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 06:28:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C761106566B; Tue, 2 Jun 2009 06:28:11 +0000 (UTC) (envelope-from joe@freebsd.org) Received: from alpha.tao.org.uk (alpha.tao.org.uk [212.42.1.232]) by mx1.freebsd.org (Postfix) with ESMTP id DFFFE8FC12; Tue, 2 Jun 2009 06:28:09 +0000 (UTC) (envelope-from joe@freebsd.org) Received: from localhost (alpha.tao.org.uk [212.42.1.232]) by alpha.tao.org.uk (Postfix) with ESMTP id 8618D1076E37; Tue, 2 Jun 2009 07:28:08 +0100 (BST) Received: from alpha.tao.org.uk ([212.42.1.232]) by localhost (mail.tao.org.uk [212.42.1.232]) (amavisd-maia, port 10024) with LMTP id 70867-07; Tue, 2 Jun 2009 07:28:06 +0100 (BST) Received: from [192.168.0.180] (0x573973c6.cpe.ge-0-2-0-1109.srnqu1.customer.tele.dk [87.57.115.198]) (Authenticated sender: joemail@alpha.tao.org.uk) by alpha.tao.org.uk (Postfix) with ESMTPA id 163661076C96; Tue, 2 Jun 2009 07:28:06 +0100 (BST) Message-ID: <4A24C673.5090408@freebsd.org> Date: Tue, 02 Jun 2009 07:28:03 +0100 From: Joe Karthauser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 MIME-Version: 1.0 To: Alexander Motin References: <3c1674c90905201459k19776d53n309b2abeab0f8d0a@mail.gmail.com> <200905202209.n4KM9Bcg094853@lava.sentex.ca> <3c1674c90905201541n65f997e6jaa20d93bf566fb98@mail.gmail.com> <68BDAD74-021A-4169-B003-21A2BCF2AD5C@transsys.com> <4A156AD7.8000003@icyb.net.ua> <4A159482.9080903@freebsd.org> <3c1674c90905211128n45814519o903ee2b6eb3cf195@mail.gmail.com> <4A16E37C.2030005@freebsd.org> <3c1674c90905221139i6f335062k74d641b7c91c188c@mail.gmail.com> <4A16FF93.2020504@freebsd.org> <4A171AB6.8040607@freebsd.org> <4A177AED.8080600@FreeBSD.org> In-Reply-To: <4A177AED.8080600@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------030600000500090102020307" X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: freebsd-stable@freebsd.org, Kip Macy Subject: Re: Sudden wierd SATA problem on RELENG_7 (Re: ZFS hanging at kernel boot now, but didn't before... (Re: ZFS MFC heads up)) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 06:28:11 -0000 This is a multi-part message in MIME format. --------------030600000500090102020307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit on 23/05/2009 05:26 Alexander Motin said the following: > Hi. > > Joe Karthauser wrote: >> I spoke too soon. It must have just randomly booted, because it is now >> hanging again. No amount of jiggling cables has made any difference. > > Can you provide verbose boot messages of your system from the beginning > up to the problem? Especially, all related to the ATA. > Attached. > > Do you have AHCI mode enabled in BIOS, or you using legacy ATA emulation? > It's set up as AHCI in the bios. What is strange is that it has now started working again. I can't make any sense of it. The machine boots up fine. It was definitely hanging at the ata probes though, just after the ZFS messages are output. Joe --------------030600000500090102020307 Content-Type: text/plain; name="dmesg.boot.athenaeum" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.boot.athenaeum" Copyright (c) 1992-2009 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 7.2-STABLE #7: Fri May 22 23:10:15 BST 2009 root@athenaeum.tao.org.uk:/usr/obj/usr/src/sys/ATHENAEUM Preloaded elf kernel "/boot/kernel/kernel" at 0x80b47000. Preloaded elf module "/boot/kernel/zfs.ko" at 0x80b4719c. Preloaded elf module "/boot/kernel/opensolaris.ko" at 0x80b47244. Preloaded elf module "/boot/kernel/geom_eli.ko" at 0x80b472f4. Preloaded elf module "/boot/kernel/crypto.ko" at 0x80b473a4. Preloaded elf module "/boot/kernel/zlib.ko" at 0x80b47450. Preloaded elf module "/boot/kernel/geom_label.ko" at 0x80b474fc. Preloaded elf module "/boot/kernel/geom_mirror.ko" at 0x80b475ac. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x80b4765c. Preloaded elf module "/boot/kernel/acpi.ko" at 0x80b476b4. module_register: module g_label already exists! Module g_label failed to register: 17 Calibrating clock(s) ... i8254 clock: 1192003 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2402413236 Hz CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2402.41-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 4096 kbytes, 16-way associative, 64 bytes/line real memory = 3756916736 (3582 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x00000000dbf7ffff, 3677728768 bytes (897883 pages) avail memory = 3673681920 (3503 MB) Table 'FACP' at 0xdfee30c0 Table 'HPET' at 0xdfee7e00 Table 'MCFG' at 0xdfee7e80 Table 'APIC' at 0xdfee7d00 MADT: Found table at 0xdfee7d00 MP Configuration Table version 1.4 found at 0x800f0d00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 3 ACPI ID 1: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 bios32: Found BIOS32 Service Directory header at 0x800fad30 bios32: Entry = 0xfb3f0 (800fb3f0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb420 pnpbios: Found PnP BIOS data at 0x800fbf90 pnpbios: Entry = f0000:bfc0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ULE: setup cpu group 2 ULE: setup cpu 2 ULE: adding cpu 2 to group 2: cpus 1 mask 0x4 ULE: setup cpu group 3 ULE: setup cpu 3 ULE: adding cpu 3 to group 3: cpus 1 mask 0x8 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ACPI: RSDP @ 0x0xf6c30/0x0014 (v 0 GBT ) ACPI: RSDT @ 0x0xdfee3040/0x0034 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: FACP @ 0x0xdfee30c0/0x0074 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: DSDT @ 0x0xdfee3180/0x4B32 (v 1 GBT GBTUACPI 0x00001000 MSFT 0x0100000C) ACPI: FACS @ 0x0xdfee0000/0x0040 ACPI: HPET @ 0x0xdfee7e00/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x00000098) ACPI: MCFG @ 0x0xdfee7e80/0x003C (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: APIC @ 0x0xdfee7d00/0x0084 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 nfslock: pseudo-device mem: Pentium Pro MTRR support enabled crypto: null: kbd: new array size 4 kbd1 at kbdmux0 io: random: npx0: INT 16 interface cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0x86862000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=29c08086) pcibios: BIOS version 3.00 AcpiOsDerivePciId: \\_SB_.PCI0.PX40.PIRQ -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.PX40.PIR2 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dfde0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 14 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x29c0, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x29c1, revid=0x02 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2937, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2938, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=3 map[20]: type I/O Port, range 32, base 0xe100, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2939, revid=0x02 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xe500, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293c, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb105000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293e, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfb100000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2940, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2946, revid=0x02 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2948, revid=0x02 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2934, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0xe200, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2935, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0xe300, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2936, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xe400, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293a, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb104000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x92 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2918, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2923, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xe600, size 3, enabled map[14]: type I/O Port, range 32, base 0xe700, size 2, enabled map[18]: type I/O Port, range 32, base 0xe800, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe900, size 2, enabled map[20]: type I/O Port, range 32, base 0xea00, size 5, enabled map[24]: type Memory, range 32, base 0xfb106000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2930, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[10]: type Memory, range 64, base 0xfb107000, size 8, enabled map[20]: type I/O Port, range 32, base 0x500, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xa000-0xafff pcib1: memory decode 0xf4000000-0xf6ffffff pcib1: prefetched decode 0xe0000000-0xefffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x0392, revid=0xa1 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf4000000, size 24, enabled pcib1: requested memory range 0xf4000000-0xf4ffffff: good map[14]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib1: requested memory range 0xe0000000-0xefffffff: good map[1c]: type Memory, range 64, base 0xf5000000, size 24, enabled pcib1: requested memory range 0xf5000000-0xf5ffffff: good map[24]: type I/O Port, range 32, base 0xa000, size 7, enabled pcib1: requested I/O range 0xa000-0xa07f: in range pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 vgapci0: port 0xa000-0xa07f mem 0xf4000000-0xf4ffffff,0xe0000000-0xefffffff,0xf5000000-0xf5ffffff irq 16 at device 0.0 on pci1 uhci0: port 0xe000-0xe01f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe000 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe100-0xe11f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe100 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe500-0xe51f irq 18 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe500 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfb105000-0xfb1053ff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfb105000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x9000-0x9fff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: irq 19 at device 28.3 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xb000-0xbfff pcib3: memory decode 0xfb000000-0xfb0fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x197b, dev=0x2363, revid=0x02 domain=0, bus=3, slot=0, func=0 class=01-06-01, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[24]: type Memory, range 32, base 0xfb000000, size 13, enabled pcib3: requested memory range 0xfb000000-0xfb001fff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x197b, dev=0x2363, revid=0x02 domain=0, bus=3, slot=0, func=1 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled pcib3: requested I/O range 0xb000-0xb007: in range map[14]: type I/O Port, range 32, base 0xb100, size 2, enabled pcib3: requested I/O range 0xb100-0xb103: in range map[18]: type I/O Port, range 32, base 0xb200, size 3, enabled pcib3: requested I/O range 0xb200-0xb207: in range map[1c]: type I/O Port, range 32, base 0xb300, size 2, enabled pcib3: requested I/O range 0xb300-0xb303: in range map[20]: type I/O Port, range 32, base 0xb400, size 4, enabled pcib3: requested I/O range 0xb400-0xb40f: in range pcib3: matched entry for 3.0.INTB pcib3: slot 0 INTB hardwired to IRQ 16 atapci0: mem 0xfb000000-0xfb001fff irq 19 at device 0.0 on pci3 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 52 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xfb000000 atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: SATA connect time=0ms ata2: SIGNATURE: 00000101 ata2: ahci_reset devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect status=00000000 ata3: ahci_reset devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] atapci1: port 0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f irq 16 at device 0.1 on pci3 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb400 atapci1: [MPSAFE] atapci1: [ITHREAD] ata4: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xb000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xb100 ata4: reset tp1 mask=03 ostat0=00 ostat1=00 ata4: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata4: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=00 stat1=00 devices=0x4 ata4: [MPSAFE] ata4: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xf7000000-0xf8ffffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x10ec, dev=0x8168, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib4: requested I/O range 0xc000-0xc0ff: in range map[18]: type Memory, range 64, base 0xf8000000, size 12, enabled pcib4: requested memory range 0xf8000000-0xf8000fff: good pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 re0: port 0xc000-0xc0ff mem 0xf8000000-0xf8000fff irq 16 at device 0.0 on pci4 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xf8000000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) msi: routing MSI IRQ 256 to vector 54 re0: using IRQ 256 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:1a:4d:4a:1d:b1 re0: [MPSAFE] re0: [FILTER] uhci3: port 0xe200-0xe21f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe200 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 53 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe300-0xe31f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe300 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe400-0xe41f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe400 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfb104000-0xfb1043ff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfb104000 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xd000-0xdfff pcib5: memory decode 0xf9000000-0xfaffffff pcib5: no prefetched decode pcib5: Subtractively decoded bridge. pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x1186, dev=0x4300, revid=0x10 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd000, size 8, enabled pcib5: requested I/O range 0xd000-0xd0ff: in range map[14]: type Memory, range 32, base 0xfa000000, size 8, enabled pcib5: requested memory range 0xfa000000-0xfa0000ff: good pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 20 found-> vendor=0x1186, dev=0x4300, revid=0x10 domain=0, bus=5, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd100, size 8, enabled pcib5: requested I/O range 0xd100-0xd1ff: in range map[14]: type Memory, range 32, base 0xfa001000, size 8, enabled pcib5: requested memory range 0xfa001000-0xfa0010ff: good pcib5: matched entry for 5.1.INTA pcib5: slot 1 INTA hardwired to IRQ 19 found-> vendor=0x9004, dev=0x6178, revid=0x01 domain=0, bus=5, slot=2, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0x04 (1000 ns) intpin=a, irq=15 map[10]: type I/O Port, range 32, base 0xd200, size 8, enabled pcib5: requested I/O range 0xd200-0xd2ff: in range map[14]: type Memory, range 32, base 0xfa002000, size 12, enabled pcib5: requested memory range 0xfa002000-0xfa002fff: good pcib5: matched entry for 5.2.INTA pcib5: slot 2 INTA hardwired to IRQ 18 re1: port 0xd000-0xd0ff mem 0xfa000000-0xfa0000ff irq 20 at device 0.0 on pci5 re1: Reserved 0x100 bytes for rid 0x14 type 3 at 0xfa000000 re1: Chip rev. 0x10000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: bpf attached re1: Ethernet address: 00:1c:f0:6e:c7:d2 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 55 re1: [MPSAFE] re1: [FILTER] re2: port 0xd100-0xd1ff mem 0xfa001000-0xfa0010ff irq 19 at device 1.0 on pci5 re2: Reserved 0x100 bytes for rid 0x14 type 3 at 0xfa001000 re2: Chip rev. 0x10000000 re2: MAC rev. 0x00000000 miibus2: on re2 rgephy2: PHY 1 on miibus2 rgephy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re2: bpf attached re2: Ethernet address: 00:1c:f0:ba:be:ed re2: [MPSAFE] re2: [FILTER] ahc0: port 0xd200-0xd2ff mem 0xfa002000-0xfa002fff irq 18 at device 2.0 on pci5 ahc0: Defaulting to MEMIO off ahc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd200 ahc0: Reading SEEPROM...done. ahc0: Low byte termination Enabled ahc0: Downloading Sequencer Program... 460 instructions downloaded ahc0: Features 0x10101, Bugs 0x35, Flags 0x20481540 ahc0: [MPSAFE] ahc0: [ITHREAD] aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xfb106000-0xfb1067ff irq 19 at device 31.2 on pci0 atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xea00 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfb106000 atapci2: AHCI called from vendor specific driver atapci2: AHCI Version 01.20 controller with 4 ports detected ata5: on atapci2 ata5: SATA connect time=0ms ata5: SIGNATURE: 00000101 ata5: ahci_reset devices=0x1 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci2 ata6: SATA connect time=0ms ata6: SIGNATURE: 00000101 ata6: ahci_reset devices=0x1 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci2 ata7: port not implemented ata7: [MPSAFE] ata7: [ITHREAD] ata8: on atapci2 ata8: port not implemented ata8: [MPSAFE] ata8: [ITHREAD] ata9: on atapci2 ata9: SATA connect time=0ms ata9: SIGNATURE: 00000101 ata9: ahci_reset devices=0x1 ata9: [MPSAFE] ata9: [ITHREAD] ata10: on atapci2 ata10: SATA connect time=0ms ata10: SIGNATURE: 00000101 ata10: ahci_reset devices=0x1 ata10: [MPSAFE] ata10: [ITHREAD] pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 56 fdc0: [FILTER] sio0: irq maps: 0xdc29 0xdc39 0xdc29 0xdc29 sio0: irq maps: 0xdc29 0xdc39 0xdc29 0xdc29 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 cpu0: switching to generic Cx mode est0: enabling SpeedStep est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 920092006000620 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 920092006000620 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 920092006000620 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 920092006000620 device_attach: est3 attach returned 6 p4tcc3: on cpu3 atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it vga: vga0 already exists; skipping it 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 isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd1fff,0xd2000-0xd4fff,0xd5000-0xd57ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 14 (ISA IRQ 14) to vector 59 ata0: [MPSAFE] ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 60 ata1: [MPSAFE] ata1: [ITHREAD] bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 61 ppbus0: [MPSAFE] ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xdc29 0xdc29 0xdc29 0xdc29 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 230866 -> 100000 procfs registered WARNING: ZFS is considered to be an experimental feature in FreeBSD. lapic: Divisor 2, Frequency 133467407 hz Timecounter "TSC" frequency 2402413236 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached Waiting 5 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. The GEOM class LABEL is already loaded. ZFS filesystem version 13 ZFS storage pool version 13 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 476938MB at ata2-master SATA300 ad4: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire acd0: DVDR drive at ata4 as master acd0: read 8269KB/s (8269KB/s) write 8269KB/s (8269KB/s), 2048KB buffer, UDMA66 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 476938MB at ata5-master SATA300 ad10: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad12: 476938MB at ata6-master SATA300 ad12: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue ata9-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad18: 476938MB at ata9-master SATA300 ad18: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue ata10-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad20: 476938MB at ata10-master SATA300 ad20: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM_LABEL: Label for provider ad4 is label/sata5. GEOM: new disk ad10 GEOM: new disk ad12 GEOM: new disk ad18 GEOM: new disk ad20 GEOM_LABEL: Label for provider ad4s1a is ufsid/477454d17d3bf4f7. GEOM_LABEL: Label for provider ad4s1c is ufsid/4774549e7d9d0f30. GEOM_LABEL: Label for provider ad10 is label/sata1. GEOM_LABEL: Label for provider ad12 is label/sata2. GEOM_LABEL: Label for provider ad18 is label/sata3. GEOM_LABEL: Label for provider ad20 is label/sata4. GEOM_LABEL: Label ufsid/4774549e7d9d0f30 removed. GEOM_LABEL: Label ufsid/477454d17d3bf4f7 removed. GEOM_MIRROR: Device mirror/boot0 launched (5/5). ahc0: Selection Timeout on A:0. 0 SCBs aborted ahc0: Selection Timeout on A:1. 0 SCBs aborted ahc0: Selection Timeout on A:3. 0 SCBs aborted ahc0: Selection Timeout on A:4. 0 SCBs aborted ahc0: Selection Timeout on A:5. 0 SCBs aborted ahc0: Selection Timeout on A:6. 0 SCBs aborted ahc0: Selection Timeout on A:2. 0 SCBs aborted SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 2 ioapic0: Assigning ISA IRQ 7 to local APIC 3 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning ISA IRQ 15 to local APIC 2 ioapic0: Assigning PCI IRQ 16 to local APIC 3 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 20 to local APIC 2 ioapic0: Assigning PCI IRQ 21 to local APIC 3 ioapic0: Assigning PCI IRQ 23 to local APIC 0 msi: Assigning MSI IRQ 256 to local APIC 1 Trying to mount root from zfs:storage/rootfs start_init: trying /sbin/init GEOM_LABEL: Label for provider mirror/boot0 is ufsid/4774549e7d9d0f30. GEOM_LABEL: Label for provider mirror/boot0a is ufsid/477454d17d3bf4f7. GEOM_LABEL: Label ufsid/4774549e7d9d0f30 removed. GEOM_LABEL: Label ufsid/477454d17d3bf4f7 removed. ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled re0: link state changed to UP --------------030600000500090102020307-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 07:52:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 463F0106564A for ; Tue, 2 Jun 2009 07:52:32 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id ADA848FC17 for ; Tue, 2 Jun 2009 07:52:31 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id n527qSek000449 for ; Tue, 2 Jun 2009 09:52:29 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8552072 for ; Tue, 2 Jun 2009 09:52:28 +0200 (CEST) Date: Tue, 2 Jun 2009 09:52:28 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> In-Reply-To: References: Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.6.2.73733 Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 07:52:32 -0000 On Sat, 30 May 2009 21:41:36 +0300 Dan Naumov wrote about ZFS NAS configuration question: DN> So, this leaves me with 1 SATA port used for a FreeBSD disk and 4 SATA DN> ports available for tinketing with ZFS. Do you have a USB port available to boot from? A conventional USB stick (I use 4 GB or 8GB these days, but smaller ones would certainly also do) is enough to hold the base system on UFS, and you can give the whole of your disks to ZFS without having to bother with booting from them. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 08:24:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BACC31065677; Tue, 2 Jun 2009 08:24:24 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id 7824A8FC13; Tue, 2 Jun 2009 08:24:23 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:225:ff:feed:9426] (unknown [IPv6:2001:470:909f:1:225:ff:feed:9426]) by itchy.rabson.org (Postfix) with ESMTP id 032FE5CD3; Tue, 2 Jun 2009 09:23:54 +0100 (BST) Message-Id: From: Doug Rabson To: Henri Hennebert In-Reply-To: <4A23ABF2.3070601@restart.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 09:23:52 +0100 References: <4A23ABF2.3070601@restart.be> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: /boot/loader can't load kernel if too many pool/devices X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 08:24:25 -0000 On 1 Jun 2009, at 11:22, Henri Hennebert wrote: > Hello, > > During my tests (succesful) to directly boot from ZFS (with zfsboot > and gptzfsboot) I encounter the error "can't boot 'kernel'" if too > many devices/pools are connected to the machine. In my case: > > 2 SAS disks with 2 pools > 2 SATA disks with 2 pools > 1 USB key with one pool > > `heap` command: > > Active Allocations: 171/173 > 536576 bytes reserved 527800 bytes allocated > > `ls` command: > > open '/' failed: too many open files > > If I reboot without the USB key all is OK. > > If I reboot from the USB key after disconnecting 2 disks all is OK. > > By the way, the /boot/loader in 7.2-STABLE don't work, complains > about forth not found. > > The previous tests were made with 7.2-STABLE (May 31) with /boot/ > loader from 8.0-CURRENT. I recently increased the number of file descriptors available for / boot/loader. Could you rebuild and try again please. Make sure you rebuild libstand.a as well as /boot/loader. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 08:35:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00593106568E for ; Tue, 2 Jun 2009 08:34:59 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA8F8FC1D for ; Tue, 2 Jun 2009 08:34:53 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by bwz9 with SMTP id 9so8149653bwz.43 for ; Tue, 02 Jun 2009 01:34:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.111.134 with SMTP id s6mr3558138fap.37.1243931692442; Tue, 02 Jun 2009 01:34:52 -0700 (PDT) In-Reply-To: References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> From: Vlad Galu Date: Tue, 2 Jun 2009 11:34:31 +0300 Message-ID: To: Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Bruce Simpson , Jilles Tjoelker Subject: Re: Unnamed POSIX shared semaphores X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 08:35:00 -0000 On Tue, Jun 2, 2009 at 12:30 AM, Daniel Eischen wrote: [...] Thank you all for your swift replies. It seems to indeed work for forked processes. The app at $work (written on and for Linux) transported an unnamed semaphore over a POSIX shared memory object. I'll probably make it a named semaphore and only send its name over the shared memory space. Regards, Vlad From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 08:46:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A14971065673 for ; Tue, 2 Jun 2009 08:46:43 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 570EB8FC22 for ; Tue, 2 Jun 2009 08:46:43 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so4287349ana.13 for ; Tue, 02 Jun 2009 01:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aP2j1LVjjUzg6+NeUwBKRuvVcCty1BEZw4BMQOT6bKM=; b=PYWzoNJtE4/LOXinQrgFx1gjgLmTV+aa1v5u04FXpBG+LSo+PID9K0DBQ7euK1sA9d PDfmefvSvgckgT+TEGCCL02FHHHnIl8npN37LjEK8zd4RGQgu9ogbOsbzIwXOYMzXY2j FBU78FuI3iR39y97i61p+zwTjzWgwicWmLZkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CqgdpCmmNKqIshNiaITsVUZNHdH93hj/yjNJ0wjoRmQoOAdJfelbRG1v2sxJFnZesk aFPtiuiJ+7XmGhWlmGTDzKoSe/citi5Lq4xjOHaAtChR/e+oJQ7JwT/DhyD9KH0fqsXC ZLFnZA/i7X91VXr9puFLm/YrMdZfOxwqp0I6s= MIME-Version: 1.0 Received: by 10.100.231.16 with SMTP id d16mr8619777anh.63.1243932402672; Tue, 02 Jun 2009 01:46:42 -0700 (PDT) In-Reply-To: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> References: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> Date: Tue, 2 Jun 2009 11:46:42 +0300 Message-ID: From: Dan Naumov To: =?ISO-8859-1?Q?Gerrit_K=FChn?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 08:46:43 -0000 USB root partition for booting off UFS is something I have considered. I have looked around and it seems that all the "install FreeBSD onto USB stick" guides seem to involve a lot of manual work from a fixit environment= , does sysinstall not recognise USB drives as a valid disk device to parition/label/install FreeBSD on? If I do go with an USB boot/root, what things I should absolutely keep on it and which are "safe" to move to a ZFS pool? The idea is that in case my ZFS configuration goes bonkers for some reason, I still have a fully workable singleuser configuration to boot from for recovery. I haven't really used USB flash for many years, but I remember when they first started appearing on the shelves, they got well known for their horrible reliability (stick would die within a year of use, etc). Have they improved to the point of being good enough to host a root partition on, without having to setup some crazy GEOM mirror setup using 2 of them? - Dan Naumov 2009/6/2 Gerrit K=FChn > On Sat, 30 May 2009 21:41:36 +0300 Dan Naumov wrot= e > about ZFS NAS configuration question: > > DN> So, this leaves me with 1 SATA port used for a FreeBSD disk and 4 SAT= A > DN> ports available for tinketing with ZFS. > > Do you have a USB port available to boot from? A conventional USB stick (= I > use 4 GB or 8GB these days, but smaller ones would certainly also do) is > enough to hold the base system on UFS, and you can give the whole of your > disks to ZFS without having to bother with booting from them. > > > cu > Gerrit > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 09:15:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A8711065673 for ; Tue, 2 Jun 2009 09:15:41 +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 83A708FC12 for ; Tue, 2 Jun 2009 09:15:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-217-173.lns11.adl2.internode.on.net [121.45.217.173]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n529FbwK056802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Jun 2009 18:45:37 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 2 Jun 2009 18:45:26 +0930 User-Agent: KMail/1.9.10 References: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1260295.JiKEJ7TCrH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906021845.33739.doconnor@gsoft.com.au> X-Spam-Score: -1.395 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Gerrit =?utf-8?q?K=C3=BChn?= , Dan Naumov Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 09:15:41 -0000 --nextPart1260295.JiKEJ7TCrH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 2 Jun 2009, Dan Naumov wrote: > USB root partition for booting off UFS is something I have > considered. I have looked around and it seems that all the "install > FreeBSD onto USB stick" guides seem to involve a lot of manual work > from a fixit environment, does sysinstall not recognise USB drives as > a valid disk device to parition/label/install FreeBSD on? If I do go > with an USB boot/root, what things I should absolutely keep on it and > which are "safe" to move to a ZFS pool? The idea is that in case my > ZFS configuration goes bonkers for some reason, I still have a fully > workable singleuser configuration to boot from for recovery. It should see them as SCSI disks, note that if you plug them in after=20 the installer boots you will need to go into Options and tell it to=20 rescan the devices. > I haven't really used USB flash for many years, but I remember when > they first started appearing on the shelves, they got well known for > their horrible reliability (stick would die within a year of use, > etc). Have they improved to the point of being good enough to host a > root partition on, without having to setup some crazy GEOM mirror > setup using 2 of them? I would expect one to last a long time if you only use it for /boot and=20 use ZFS for the rest (or even just moving /var onto ZFS would save=20 heaps of writes). Also, you could setup 2 USB sticks (install on one then dd onto the=20 other) so you have a cold spare. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1260295.JiKEJ7TCrH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKJO215ZPcIHs/zowRAgg0AJ4uF3Dr6ChIaXBDFCuBka4vArOAZQCfRe4p iEHlF56WmqpaSqrd2i1IH3E= =is/n -----END PGP SIGNATURE----- --nextPart1260295.JiKEJ7TCrH-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 09:16:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D4EC1065670 for ; Tue, 2 Jun 2009 09:16:13 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0408FC27 for ; Tue, 2 Jun 2009 09:16:12 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n529GBN3093849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Jun 2009 11:16:11 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n529GAIX093848 for freebsd-stable@freebsd.org; Tue, 2 Jun 2009 11:16:10 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Tue, 2 Jun 2009 11:16:10 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: freebsd-stable@freebsd.org Message-ID: <20090602091610.GE93344@acme.spoerlein.net> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.19 (2009-01-05) Subject: ZFS weird device tasting loop since MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 09:16:13 -0000 Hi all, so I went ahead and updated my ~7.2 file server to the new ZFS goodness, and before running any further tests, I already discovered something weird and annoying. I'm using a mirror on GELI, where one disk is usually *not* attached as a means of poor man's backup. (I had to go that route, as send/recv of snapshots frequently deadlocked the system, whereas a mirror scrubbing did not) root@coyote:~# zpool status pool: tank state: DEGRADED status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 12333765091756463941 REMOVED 0 0 0 was /dev/da0.eli errors: No known data errors When imported, there is a constant "tasting" of all devices in the system, which also makes the floppy drive go spinning constantly, which is really annoying. It did not do this with the old ZFS, are there any remedies? gstat(8) is displaying the following every other second, together with a spinning fd0 drive. dT: 1.010s w: 1.000s filter: ^...$ L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| fd0 0 8 8 1014 0.1 0 0 0.0 0.1| md0 0 32 32 4055 9.2 0 0 0.0 29.2| ad0 0 77 10 1267 7.1 63 1125 2.3 31.8| ad4 There is no activity going on, especially md0 is for /tmp, yet it constantly tries to read stuff from everywhere. I will now insert the second drive and see if ZFS shuts up then ... Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 09:24:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744A21065673 for ; Tue, 2 Jun 2009 09:24:12 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 29AE18FC1B for ; Tue, 2 Jun 2009 09:24:09 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n529O8xd093990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Jun 2009 11:24:09 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n529O89a093989 for freebsd-stable@freebsd.org; Tue, 2 Jun 2009 11:24:08 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Tue, 2 Jun 2009 11:24:08 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: freebsd-stable@freebsd.org Message-ID: <20090602092408.GF93344@acme.spoerlein.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20090602091610.GE93344@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090602091610.GE93344@acme.spoerlein.net> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: ZFS weird device tasting loop since MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 09:24:12 -0000 On Tue, 02.06.2009 at 11:16:10 +0200, Ulrich Spörlein wrote: > Hi all, > > so I went ahead and updated my ~7.2 file server to the new ZFS goodness, > and before running any further tests, I already discovered something > weird and annoying. > > I'm using a mirror on GELI, where one disk is usually *not* attached as > a means of poor man's backup. (I had to go that route, as send/recv of > snapshots frequently deadlocked the system, whereas a mirror scrubbing > did not) > > root@coyote:~# zpool status > pool: tank > state: DEGRADED > status: The pool is formatted using an older on-disk format. The pool can > still be used, but some features are unavailable. > action: Upgrade the pool using 'zpool upgrade'. Once this is done, the > pool will no longer be accessible on older software versions. > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank DEGRADED 0 0 0 > mirror DEGRADED 0 0 0 > ad4.eli ONLINE 0 0 0 > 12333765091756463941 REMOVED 0 0 0 was /dev/da0.eli > > errors: No known data errors > > When imported, there is a constant "tasting" of all devices in the system, > which also makes the floppy drive go spinning constantly, which is really > annoying. It did not do this with the old ZFS, are there any remedies? > > gstat(8) is displaying the following every other second, together with a > spinning fd0 drive. > > dT: 1.010s w: 1.000s filter: ^...$ > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 0 0 0 0.0 0 0 0.0 0.0| fd0 > 0 8 8 1014 0.1 0 0 0.0 0.1| md0 > 0 32 32 4055 9.2 0 0 0.0 29.2| ad0 > 0 77 10 1267 7.1 63 1125 2.3 31.8| ad4 > > There is no activity going on, especially md0 is for /tmp, yet it > constantly tries to read stuff from everywhere. I will now insert the > second drive and see if ZFS shuts up then ... It does, but it also did not start resilvering the second disk: root@coyote:~# zpool status pool: tank state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4.eli ONLINE 0 0 0 da0.eli ONLINE 0 0 16 errors: No known data errors Will now run the scrub and report back in 6-9h. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 10:12:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CB37106564A for ; Tue, 2 Jun 2009 10:12:10 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 527268FC12 for ; Tue, 2 Jun 2009 10:12:08 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 1EA4819E045; Tue, 2 Jun 2009 12:12:05 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9246319E044; Tue, 2 Jun 2009 12:11:59 +0200 (CEST) Message-ID: <4A24FAF0.2020603@quip.cz> Date: Tue, 02 Jun 2009 12:12:00 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Daniel O'Connor References: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> <200906021845.33739.doconnor@gsoft.com.au> In-Reply-To: <200906021845.33739.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Naumov , freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 10:12:10 -0000 Daniel O'Connor wrote: > On Tue, 2 Jun 2009, Dan Naumov wrote: > >>USB root partition for booting off UFS is something I have >>considered. I have looked around and it seems that all the "install >>FreeBSD onto USB stick" guides seem to involve a lot of manual work >>from a fixit environment, does sysinstall not recognise USB drives as >>a valid disk device to parition/label/install FreeBSD on? If I do go >>with an USB boot/root, what things I should absolutely keep on it and >>which are "safe" to move to a ZFS pool? The idea is that in case my >>ZFS configuration goes bonkers for some reason, I still have a fully >>workable singleuser configuration to boot from for recovery. > > > It should see them as SCSI disks, note that if you plug them in after > the installer boots you will need to go into Options and tell it to > rescan the devices. > > >>I haven't really used USB flash for many years, but I remember when >>they first started appearing on the shelves, they got well known for >>their horrible reliability (stick would die within a year of use, >>etc). Have they improved to the point of being good enough to host a >>root partition on, without having to setup some crazy GEOM mirror >>setup using 2 of them? > > > I would expect one to last a long time if you only use it for /boot and > use ZFS for the rest (or even just moving /var onto ZFS would save > heaps of writes). I am using this setup (booting from USB with UFS) in our backup storage server with FreeBSD 7.2 + ZFS. 2GB USB flash disk contains normal installation of the whole system, but is set to read only in fstab. ZFS is used for /tmp /var /usr/ports /usr/src /usr/obj and storage. root filesystem is remounted read write only for some configuration changes, then remounted back to read only. Miroslav Lachman # df -h Filesystem Size Used Avail Capacity Mounted on /dev/ufs/2gLive 1.6G 863M 642M 57% / devfs 1.0K 1.0K 0B 100% /dev tank 1.1T 128K 1.1T 0% /tank tank/system 1.1T 128K 1.1T 0% /tank/system tank/system/usr 1.1T 128K 1.1T 0% /tank/system/usr tank/system/tmp 1.1T 128K 1.1T 0% /tmp tank/system/usr/obj 1.1T 128K 1.1T 0% /usr/obj tank/system/usr/ports 1.1T 218M 1.1T 0% /usr/ports tank/system/usr/ports/distfiles 1.1T 108M 1.1T 0% /usr/ports/distfiles tank/system/usr/ports/packages 1.1T 125M 1.1T 0% /usr/ports/packages tank/system/usr/src 1.1T 171M 1.1T 0% /usr/src tank/system/var 1.1T 256K 1.1T 0% /var tank/system/var/db 1.1T 716M 1.1T 0% /var/db tank/system/var/db/pkg 1.1T 384K 1.1T 0% /var/db/pkg tank/system/var/log 1.1T 45M 1.1T 0% /var/log tank/system/var/run 1.1T 128K 1.1T 0% /var/run tank/vol0 2.6T 1.5T 1.1T 57% /vol0 tank/vol0/mon 1.1T 128K 1.1T 0% /vol0/mon (some filesystems are using compression, that's why ports and var are splitted in to more filesystems) From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 10:31:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 614B11065672; Tue, 2 Jun 2009 10:31:14 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id E31C08FC17; Tue, 2 Jun 2009 10:31:13 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id F2C104E79; Tue, 2 Jun 2009 12:31:12 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n52AV9Fw024619; Tue, 2 Jun 2009 12:31:10 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243938672; bh=zJaiGhDEaUyTO2eTkdbEZtUFw90XV05BJ3f/PRZVlQQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EASE1eGqYPXDOeno0kwO98xe6dGXP+Q1qdPV4nuZ8APUYuRihks8XdbNjqe16O8Km EwiPLvc+8Wb+STe4u5KjQ== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=vwA6yqNp9ytl34WLyxCWmZgwLPTDA/1KgfbRt8k1hYn2CLrDdqb0t8VRQHgEwGCKU sQjT0xfsZ0vvWcnORENMg== Message-ID: <4A24FF6E.7020209@restart.be> Date: Tue, 02 Jun 2009 12:31:10 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Doug Rabson References: <4A23ABF2.3070601@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: /boot/loader can't load kernel if too many pool/devices X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 10:31:14 -0000 Doug Rabson wrote: > > On 1 Jun 2009, at 11:22, Henri Hennebert wrote: > >> Hello, >> >> During my tests (succesful) to directly boot from ZFS (with zfsboot >> and gptzfsboot) I encounter the error "can't boot 'kernel'" if too >> many devices/pools are connected to the machine. In my case: >> >> 2 SAS disks with 2 pools >> 2 SATA disks with 2 pools >> 1 USB key with one pool >> >> `heap` command: >> >> Active Allocations: 171/173 >> 536576 bytes reserved 527800 bytes allocated >> >> `ls` command: >> >> open '/' failed: too many open files >> >> If I reboot without the USB key all is OK. >> >> If I reboot from the USB key after disconnecting 2 disks all is OK. >> >> By the way, the /boot/loader in 7.2-STABLE don't work, complains about >> forth not found. >> >> The previous tests were made with 7.2-STABLE (May 31) with >> /boot/loader from 8.0-CURRENT. > > I recently increased the number of file descriptors available for > /boot/loader. Could you rebuild and try again please. Make sure you > rebuild libstand.a as well as /boot/loader. > OK - I can boot with the USB key and 4 disks Thanks Henri From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 11:04:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAFA910656FA for ; Tue, 2 Jun 2009 11:04:11 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 3AFA08FC28 for ; Tue, 2 Jun 2009 11:04:11 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 2105 invoked from network); 2 Jun 2009 10:37:30 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 2 Jun 2009 10:37:30 -0000 Date: Tue, 02 Jun 2009 12:37:30 +0200 (CEST) Message-Id: <20090602.123730.41694829.sthaug@nethelp.no> To: 000.fbsd@quip.cz From: sthaug@nethelp.no In-Reply-To: <4A24FAF0.2020603@quip.cz> References: <200906021845.33739.doconnor@gsoft.com.au> <4A24FAF0.2020603@quip.cz> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 11:04:12 -0000 > root filesystem is remounted read write only for some configuration > changes, then remounted back to read only. Does this work reliably for you? I tried doing the remounting trick, both for root and /usr, back in the 4.x time frame. And could never get it to work - would always end up with inconsistent file systems. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 11:49:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A185106566B for ; Tue, 2 Jun 2009 11:49:24 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1297C8FC08 for ; Tue, 2 Jun 2009 11:49:23 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: by qyk3 with SMTP id 3so11962369qyk.3 for ; Tue, 02 Jun 2009 04:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=btLR9IX6D4RbKqhg6h8X02jVOJB8ua7a6JT7c5G4TG0=; b=qjt+Ee62NbvpOkidJ1datZ33UC5y+JOiOdiFt5KbPpvA2xFVAKWjxCiVWHKTaTcN74 1fjSUPK2wwpqTG2qslDrdnKb63wUW2ugqAXSi62vNnSFP0LvaCWy5Ht9nxjgMzFTlVn7 UKUpt0sVbQ5lRGrKskl50eHQ0vZ6euGDiV62c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=M3545DKbZI+NZf+lyrOxNuPTESpF+0gXCD9LBeMfy2CMh6Z5CaaGZ4/WnzxNxngy3M CIyFvsGnCV8aFA1KYyf1nHWAZww+4u6JEzUNb0JpFGL9d4pQcduZQxuCeYkzDCx5/B7p n2teYAT2qlt0rQQaeab2Iu8XcJzIj2v6d19L8= MIME-Version: 1.0 Received: by 10.229.97.19 with SMTP id j19mr1926696qcn.54.1243943363263; Tue, 02 Jun 2009 04:49:23 -0700 (PDT) Date: Tue, 2 Jun 2009 21:49:23 +1000 Message-ID: <4d7dd86f0906020449m43d03311jf7fcae2fbb5339c1@mail.gmail.com> From: David N To: freebsd-stable , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Crash with GJournal switcher X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 11:49:26 -0000 FreeBSD 7.2-RELEASE GPT + gmirror + gjournal May 31 10:15:48 netserv1 kernel: Fatal trap 9: general protection fault while in kernel mode May 31 10:15:48 netserv1 kernel: cpuid = 0; apic id = 00 May 31 10:15:48 netserv1 kernel: instruction pointer = 0x8:0xffffffff8059f667 May 31 10:15:48 netserv1 kernel: stack pointer = 0x10:0xfffffffe801e0a60 May 31 10:15:48 netserv1 kernel: frame pointer = 0x10:0xfffffffe801e0a90 May 31 10:15:48 netserv1 kernel: code segment = base 0x0, limit 0xfffff, type 0x1b May 31 10:15:48 netserv1 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May 31 10:15:48 netserv1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 May 31 10:15:48 netserv1 kernel: current process = 39 (g_journal switcher) This caused one of my mirrors to become stale upon reboot. There wasn't any crash dumps. I've got WITNESS compiled at the moment, hopefully a crash/lockup will show something. Would the gjournal fail if one of the gmirror disks was faulty? Regards David N From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 12:01:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E873106568D; Tue, 2 Jun 2009 12:01:10 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6E58FC27; Tue, 2 Jun 2009 12:01:09 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: by qyk3 with SMTP id 3so11970617qyk.3 for ; Tue, 02 Jun 2009 05:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=z+tcS0Dj2yy432TcqMIH/Xkdg/maxyvNwecpnCv6Pds=; b=pKgPaHgerrzPpSHNWUl0/VqMvy79bXT+gaaTjHNlCyz3orqcrPRr6G1XRgcvz8GfLe CDD/J2lJ21RWVrYVoW7AbvZDtMBTYv/f+aWzJikymJgJxphYel1XgJF2hA6JchTlDezx /GGfVkgKzNT8PkzFTGKENUBlyjWHrcgF7uNsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=rD+OA8suQKbggwZvOWu6OyiG7wRBTNcfLs+hufzlyhmuGIVxAeUJs9cHAg+RX1IQm5 pzTfbTL4BNeFt3wfZ/Sa3z71DhlVriwRnXRUd0jAzgkmKxvQ8SjN+MK3ho9VglSm3rcv Veb8c7cxepXd9rIyE2ozk7PS4FN8g/P9f9HfM= MIME-Version: 1.0 Received: by 10.229.85.21 with SMTP id m21mr2013931qcl.9.1243944069369; Tue, 02 Jun 2009 05:01:09 -0700 (PDT) In-Reply-To: <4d7dd86f0906020449m43d03311jf7fcae2fbb5339c1@mail.gmail.com> References: <4d7dd86f0906020449m43d03311jf7fcae2fbb5339c1@mail.gmail.com> Date: Tue, 2 Jun 2009 22:01:09 +1000 Message-ID: <4d7dd86f0906020501h1439eb92g15ae886f72f4d226@mail.gmail.com> From: David N To: freebsd-stable , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Crash with GJournal switcher X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 12:01:12 -0000 2009/6/2 David N : > FreeBSD 7.2-RELEASE > GPT + gmirror + gjournal > > May 31 10:15:48 netserv1 kernel: Fatal trap 9: general protection > fault while in kernel mode > May 31 10:15:48 netserv1 kernel: cpuid =3D 0; apic id =3D 00 > May 31 10:15:48 netserv1 kernel: instruction pointer =A0 =A0=3D 0x8:0xfff= fffff8059f667 > May 31 10:15:48 netserv1 kernel: stack pointer =A0 =A0 =A0 =A0 =A0=3D > 0x10:0xfffffffe801e0a60 > May 31 10:15:48 netserv1 kernel: frame pointer =A0 =A0 =A0 =A0 =A0=3D > 0x10:0xfffffffe801e0a90 > May 31 10:15:48 netserv1 kernel: code segment =A0 =A0 =A0 =A0 =A0 =3D bas= e 0x0, > limit 0xfffff, type 0x1b > May 31 10:15:48 netserv1 kernel: =3D DPL 0, pres 1, long 1, def32 0, gran= 1 > May 31 10:15:48 netserv1 kernel: processor eflags =A0 =A0 =A0 =3D interru= pt > enabled, resume, IOPL =3D 0 > May 31 10:15:48 netserv1 kernel: current process =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0=3D 39 > (g_journal switcher) > > > This caused one of my mirrors to become stale upon reboot. There > wasn't any crash dumps. > > I've got WITNESS compiled at the moment, hopefully a crash/lockup will > show something. Would the gjournal fail if one of the gmirror disks > was faulty? > > Regards > David N > lock order reversal: 1st 0xffffffff80b184c0 sleepq chain (sleepq chain) @ /usr/src/sys/kern/kern_sig.c:2291 2nd 0xffffffff80afb5b0 scrlock (scrlock) @ /usr/src/sys/dev/syscons/syscons.c:2519 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x565 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d sc_puts() at sc_puts+0x93 sc_cnputc() at sc_cnputc+0x5a cnputc() at cnputc+0x49 putchar() at putchar+0x6b kvprintf() at kvprintf+0x72 printf() at printf+0xa4 witness_checkorder() at witness_checkorder+0x44c _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d wakeup() at wakeup+0x11 tdsignal() at tdsignal+0x526 realitexpire() at realitexpire+0x3e softclock() at softclock+0x270 ithread_loop() at ithread_loop+0xe7 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfffffffe8001cd30, rbp =3D 0 --- acquiring duplicate lock of same type: "sleepq chain" 1st sleepq chain @ /usr/src/sys/kern/kern_sig.c:2291 2nd sleepq chain @ /usr/src/sys/kern/subr_sleepqueue.c:232 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x565 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d wakeup() at wakeup+0x11 tdsignal() at tdsignal+0x526 realitexpire() at realitexpire+0x3e softclock() at softclock+0x270 ithread_loop() at ithread_loop+0xe7 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfffffffe8001cd30, rbp =3D 0 --- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 12:43:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02D7810656A6; Tue, 2 Jun 2009 12:43:02 +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 6F93D8FC30; Tue, 2 Jun 2009 12:43:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2220646B52; Tue, 2 Jun 2009 08:43:01 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 27E698A02B; Tue, 2 Jun 2009 08:43:00 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 2 Jun 2009 08:42:41 -0400 User-Agent: KMail/1.9.7 References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> In-Reply-To: <4A24457C.6060100@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906020842.42330.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 02 Jun 2009 08:43:00 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Vlad Galu , Bruce Simpson , Jilles Tjoelker Subject: Re: Unnamed POSIX shared semaphores X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 12:43:03 -0000 On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote: > Jilles Tjoelker wrote: > > If process-shared semaphores really work, then the above structure is > > not a pathological case. Effectively, sem_t is carved in stone. So > > process-private semaphores should continue to have most of their stuff > > in a separately allocated structure, to preserve flexibility. > > > > There was an inadvertent race in FreeBSD's POSIX semaphores which I > fixed in HEAD and STABLE about 6 weeks before 7.2 was released. > > I believe process-shared POSIX semaphores now work -- the Python > 'multiprocessing' regression test now runs to completion with no errors > on both HEAD and STABLE. The semaphores in recent 7 and 8 are definitely not process-shared (at least not intentionally). They may work across a fork accidentally, but you can't store it in an mmap() region and share it with an arbitrary process. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 13:45:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38B081065672 for ; Tue, 2 Jun 2009 13:45:57 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mail.gmx.com (unknown [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 80F3F8FC1F for ; Tue, 2 Jun 2009 13:45:56 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: (qmail invoked by alias); 02 Jun 2009 13:45:54 -0000 Received: from unknown (EHLO [192.168.254.1]) [91.140.118.23] by mail.gmx.com (mp-eu001) with SMTP; 02 Jun 2009 15:45:54 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX18wcr43mT0wYvY/rdxmztmRjY9i624k+ALGc2aU2E 6dplTUgCum9a5N Message-ID: <4A252CC5.1030900@gmx.com> Date: Tue, 02 Jun 2009 16:44:37 +0300 From: Nikos Vassiliadis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: sthaug@nethelp.no References: <200906021845.33739.doconnor@gsoft.com.au> <4A24FAF0.2020603@quip.cz> <20090602.123730.41694829.sthaug@nethelp.no> In-Reply-To: <20090602.123730.41694829.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: freebsd-stable@freebsd.org, 000.fbsd@quip.cz Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 13:45:57 -0000 sthaug@nethelp.no wrote: >> root filesystem is remounted read write only for some configuration >> changes, then remounted back to read only. > > Does this work reliably for you? I tried doing the remounting trick, > both for root and /usr, back in the 4.x time frame. And could never > get it to work - would always end up with inconsistent file systems. There were many fixes in this area lately. The case where a file system with softdeps would fail to update to read-only is fixed in -CURRENT and these changes are merged to -STABLE. It is believed to work correctly. http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046001.html Remounting with soft updates enabled used to be too fragile to be useful. Now it seems very solid. Nikos From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 14:06:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 765CD1065674; Tue, 2 Jun 2009 14:06:24 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5C68FC15; Tue, 2 Jun 2009 14:06:22 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00321; Tue, 02 Jun 2009 17:06:19 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A2531DA.2070608@freebsd.org> Date: Tue, 02 Jun 2009 17:06:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Henri Hennebert , Kip Macy References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> <4A240063.207@freebsd.org> In-Reply-To: <4A240063.207@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 14:06:24 -0000 on 01/06/2009 19:22 Andriy Gapon said the following: > Henri, > > thank you very much for testing! > It look like the patch did its job. > > P.S. hopefully someone is looking into the cause of the assertion. I think I cracked it. This is where ds->ds_lock.m_owner gets corrupted: (gdb) c Continuing. Watchpoint 8: *(void **) 34385649856 Old value = (void *) 0x0 New value = (void *) 0x8018f7ce0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 (gdb) bt #0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 #1 0x0000000800a733ca in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #2 0x0000000800a736ab in pthread_mutex_isowned_np () from /lib/libthr.so.3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 ... (gdb) fr 3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 264 if (mutex_owned(&ds->ds_lock)) (gdb) list 259 if (ds->ds_dir) 260 dsl_dir_close(ds->ds_dir, ds); 261 262 ASSERT(!list_link_active(&ds->ds_synced_link)); 263 264 if (mutex_owned(&ds->ds_lock)) 265 mutex_exit(&ds->ds_lock); mutex_owned is defined: cddl/contrib/opensolaris/head/thread.h #define mutex_owned(l) pthread_mutex_isowned_np(l) So we pass kmutex_t* parameter to pthread_mutex_isowned_np call where in fact we should be passing pthread_mutex_t* parameter. So I am quite sure that mutex_owned should be defined as follows: #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Or it should be called on m_lock member of kmutex_t. Thanks to Henri for all the debugging info! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 14:14:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03B3106564A; Tue, 2 Jun 2009 14:14:20 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 86F708FC15; Tue, 2 Jun 2009 14:14:19 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00512; Tue, 02 Jun 2009 17:14:17 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A2533B8.8040007@freebsd.org> Date: Tue, 02 Jun 2009 17:14:16 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Henri Hennebert , Kip Macy References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> <4A240063.207@freebsd.org> <4A2531DA.2070608@freebsd.org> In-Reply-To: <4A2531DA.2070608@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 14:14:21 -0000 on 02/06/2009 17:06 Andriy Gapon said the following: > So I am quite sure that mutex_owned should be defined as follows: > #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Actually: #define mutex_owned(l) pthread_mutex_isowned_np(&(l)->m_lock) And on dangers of ignored compiler warnings: /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type This is during libzpool compilation. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 17:13:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D2E81065672 for ; Tue, 2 Jun 2009 17:13:29 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9908FC1B for ; Tue, 2 Jun 2009 17:13:28 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n52Gcg9K008421 for ; Tue, 2 Jun 2009 18:38:43 +0200 (CEST) X-Ids: 166 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id B30F389E58 for ; Tue, 2 Jun 2009 18:38:41 +0200 (CEST) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id 7CBE113D; Tue, 2 Jun 2009 18:38:41 +0200 (CEST) Date: Tue, 2 Jun 2009 18:38:41 +0200 From: Michel Talon To: freebsd-stable@freebsd.org Message-ID: <20090602163841.GA15567@lpthe.jussieu.fr> Mail-Followup-To: Michel Talon , freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.jussieu.fr [134.157.0.166]); Tue, 02 Jun 2009 18:38:43 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9414/Tue Jun 2 13:11:57 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A255592.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A255592.002/134.157.10.1/parthe.lpthe.jussieu.fr/parthe.lpthe.jussieu.fr/ X-j-chkmail-Score: MSGID : 4A255592.002 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.053 -> S=0.053 X-j-chkmail-Status: Ham Subject: FreeBSD-7.2 works excellent X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 17:13:29 -0000 Hello, just a word to say that the upgrade from FreeBSD-7.1 to 7.2 has solved all problems i had on my desktop (very slow windowing, etc.) without changing anything to the installed ports. Now everything works excellent in accordance with the FreeBSD tradition. Thanks for the good work of the developers -- Michel TALON From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 18:47:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 907CC106566B for ; Tue, 2 Jun 2009 18:47:44 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id 13C1F8FC12 for ; Tue, 2 Jun 2009 18:47:43 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by fxm7 with SMTP id 7so2014004fxm.43 for ; Tue, 02 Jun 2009 11:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/P7Gf3ooqiCbXanPKaApdk/Rs9KaszWy2PqdVYb0ziM=; b=TgpQ73W4MEYyQtzMZt0jirLcGlIqcHzUMB3pjrmRlhN5zlj+cSRO0C1CrYkK3hQHi5 XojV7u/K8d8GQ+aQMXyXHSqp/e/WNSBvrovNS7ksIiZsAFKeTAUyb53b0VTubaJpSFaH fSh3RLGg6RUjNXWA/2rd2v6IvGz+Jen50jcVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lu/3L3hzaDe8btpQ0QBNjganwj0+uj6ECXGyZOVyo8Gbjb/n2Kfjcto2OEXAEz4Igk vAiZ1oLf7au5He++AEpE4kR4Py0vXoTWU2z43b+6Thuds/96mRBP6gygmBuPpC0s/jLM zLRP0cetqAcw00ZtKMxFvNwoHbYWP6CEQ0Pa4= MIME-Version: 1.0 Received: by 10.204.63.143 with SMTP id b15mr56177bki.8.1243968462401; Tue, 02 Jun 2009 11:47:42 -0700 (PDT) In-Reply-To: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> Date: Tue, 2 Jun 2009 14:47:42 -0400 Message-ID: <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> From: Zaphod Beeblebrox To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Dan Naumov Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 18:47:44 -0000 On Sun, May 31, 2009 at 4:43 AM, Aristedes Maniatis wrote: > > On 31/05/2009, at 4:41 AM, Dan Naumov wrote: > > To top that >> off, even when/if you do it right, not your entire disk goes to ZFS >> anyway, because you still do need a swap and a /boot to be non-ZFS, so >> you will have to install ZFS onto a slice and not the entire disk and >> even SUN discourages to do that. >> > > ZFS on root is still pretty new to FreeBSD, and until it gets ironed out > and all the sysinstall tools support it nicely, it isn't hard to use a small > UFS slice to get things going during boot. And there is nothing wrong with > putting ZFS onto a slice rather than the entire disk: that is a very common > approach. > It's worth noting that there are a few sensible appliance designs... (although as a ZFS server, you might want 4, 8 or 16G in your "appliance"). You could, for instance, boot from flash. If your true purpose is an appliance, this is very reasonable. It means that your appliance "boots" when no "disks" are attached. Useful to instruct the appliance user how to attache disks and do diagnostics, for instance. My own ZFS is 5x 1.5TB disks running on a few week old 8-CURRENT. I gave up waiting for v13 in 7.x. Maybe I should have waited. But I've avoided most of the most recent foo-for-ah by not tracking current incessantly. If I was installing new, I'd probably stick with 7.x for a server... for now. I must admit, however, that the system seems happy with 8-CURRENT. The system boots from a pair of drives in a gmirror. Mot because you can't boot from ZFS, but because it's just so darn stable (and it predates the use of ZFS). Really there are two camps here --- booting from ZFS is the use of ZFS as the machine's own filesystem. This is one goal of ZFS that is somewhat imperfect on FreeBSD at the momment. ZFS file servers are another goal where booting from ZFS is not really required and only marginally beneficial. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 19:16:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 389961065686 for ; Tue, 2 Jun 2009 19:16:06 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id F197C8FC1D for ; Tue, 2 Jun 2009 19:16:04 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 6920719E044; Tue, 2 Jun 2009 21:16:02 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CC5EE19E043; Tue, 2 Jun 2009 21:15:59 +0200 (CEST) Message-ID: <4A257A70.2020905@quip.cz> Date: Tue, 02 Jun 2009 21:16:00 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: sthaug@nethelp.no References: <200906021845.33739.doconnor@gsoft.com.au> <4A24FAF0.2020603@quip.cz> <20090602.123730.41694829.sthaug@nethelp.no> In-Reply-To: <20090602.123730.41694829.sthaug@nethelp.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 19:16:07 -0000 sthaug@nethelp.no wrote: >>root filesystem is remounted read write only for some configuration >>changes, then remounted back to read only. > > > Does this work reliably for you? I tried doing the remounting trick, > both for root and /usr, back in the 4.x time frame. And could never > get it to work - would always end up with inconsistent file systems. The system is in production from October 2008 and never paniced in remounting. In this time frame, we got only two deadlocks caused by earlier versions of ZFS. At this time, files on ZFS are using 28151719 inodes, storage is for daily rsync backups of dozen webservers and mailserver. I am using mount -u -o current,rw / [do some configuration work] sync; sync; sync; mount -u -o current,ro / The sync command is maybe useless, but I feel safer with it ;o) (root filesystem is not using soft-updates) Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 19:20:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C0601065676 for ; Tue, 2 Jun 2009 19:20:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B50AC8FC0C for ; Tue, 2 Jun 2009 19:20:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 15110 invoked by uid 399); 2 Jun 2009 19:20:35 -0000 Received: from localhost (HELO ?192.168.0.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jun 2009 19:20:35 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A257B82.1000701@FreeBSD.org> Date: Tue, 02 Jun 2009 12:20:34 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 19:20:43 -0000 Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Thanks, Doug From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 19:39:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68B33106568A for ; Tue, 2 Jun 2009 19:39:19 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7BE8FC15 for ; Tue, 2 Jun 2009 19:39:18 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so4466740ana.13 for ; Tue, 02 Jun 2009 12:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hRHI6rnWs/NmuOVo9THfFyOL+Ej3hArjDNfhwPtlNhs=; b=DF6ci5Pg38XOn+nFBLFqZ9Rtl1VNaDEZ7PaAaa8BSyTiII5qH4XwJ4eClQTaN1c4GZ /TD8YUFNH3jOfJxPTWzlEjFHz2LMLDKx06yLTYz4jb8W8SNmhMdDQdiSVB3fCynO2QLH qlrBg8uUmulF/E9Ql7pQOMC305bysnawj2L2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NRvLj+LMfVCDk6wO6ry6oy2G1hDLHBXW749RGX4PsTI+lMTYKmQhPa4If4flEbIlM0 J5i1cfPubTj8oGNvXDHtqEbOZ7jkZYlOgxpMhYux/wMU69cCg5ED6z+0mOa8PUZwQENP 0BbFR02XCyt1rO3RMRL0tX/ZPoATNNVx9c8ZA= MIME-Version: 1.0 Received: by 10.100.251.7 with SMTP id y7mr86781anh.178.1243971558555; Tue, 02 Jun 2009 12:39:18 -0700 (PDT) In-Reply-To: <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> Date: Tue, 2 Jun 2009 22:39:17 +0300 Message-ID: From: Dan Naumov To: Zaphod Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 19:39:19 -0000 This reminds me. I was reading the release and upgrade notes of OpenSolaris 2009.6 and noted one thing about upgrading from a previous version to the new one:: When you pick the "upgrade OS" option in the OpenSolaris installer, it will check if you are using a ZFS root partition and if you do, it intelligently suggests to take a current snapshot of the root filesystem. After you finish the upgrade and do a reboot, the boot menu offers you the option of booting the new upgraded version of the OS or alternatively _booting from the snapshot taken by the upgrade installation procedure_. Reading that made me pause for a second and made me go "WOW", this is how UNIX system upgrades should be done. Any hope of us lowly users ever seeing something like this implemented in FreeBSD? :) - Dan Naumov On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox wrote: > > > The system boots from a pair of drives in a gmirror. Mot because you can't > boot from ZFS, but because it's just so darn stable (and it predates the use > of ZFS). > > Really there are two camps here --- booting from ZFS is the use of ZFS as > the machine's own filesystem. This is one goal of ZFS that is somewhat > imperfect on FreeBSD at the momment. ZFS file servers are another goal > where booting from ZFS is not really required and only marginally > beneficial. > > > From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 19:55:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 487B81065672 for ; Tue, 2 Jun 2009 19:55:45 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id F35938FC17 for ; Tue, 2 Jun 2009 19:55:44 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so4461241ywe.13 for ; Tue, 02 Jun 2009 12:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A8Y46IV/BF1g7zG9Mh2q3cbBB3EsPw65mtN/M8cDGuI=; b=waQDdQD/dL7KDi2tHCw7sd2bw1JbAnGMnoXp+zKYJE7GpeK03UklLjd4W6IfBG4+SB NT12i7oB4P8gQ+qsvTMzq8OOvSZDBMRKt5ha/HrNa71oXEcNpDuApdZuYJg3PpmHpHjd hNOfmIrQ5+aoEtgtNcKZd5scNDOx1dlLtKDtU= 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=ELsqURvcROTCJv4taIsIL83IY/9sJVptO4C6YGzWxEI/vcBY3ST/e2U+vivMYFgCTH gSyx8QoSZarCqatafD8wnlur3pogQm2jBRtL0+TPovtrYyrxMFl2E1ccJG52Y+mYeOKW bp1PQZb7ZZWown0aNE57Jr03R8tDrjR9bOG04= MIME-Version: 1.0 Received: by 10.100.251.7 with SMTP id y7mr110649anh.178.1243972544248; Tue, 02 Jun 2009 12:55:44 -0700 (PDT) In-Reply-To: References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> Date: Tue, 2 Jun 2009 22:55:43 +0300 Message-ID: From: Dan Naumov To: Zaphod Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 19:55:45 -0000 A little more info for the (perhaps) curious: Managing Multiple Boot Environments: http://dlc.sun.com/osol/docs/content/2009.06/getstart/bootenv.html#bootenvm= gr Introduction to Boot Environments: http://dlc.sun.com/osol/docs/content/2009.06/snapupgrade/index.html - Dan Naumov On Tue, Jun 2, 2009 at 10:39 PM, Dan Naumov wrote: > > This reminds me. I was reading the release and upgrade notes of OpenSolar= is 2009.6 and noted one thing about upgrading from a previous version to th= e new one:: > > When you pick the "upgrade OS" option in the OpenSolaris installer, it wi= ll check if you are using a ZFS root partition and if you do, it intelligen= tly suggests to take a current snapshot of the root filesystem. After you f= inish the upgrade and do a reboot, the boot menu offers you the option of b= ooting the new upgraded version of the OS or alternatively _booting from th= e snapshot taken by the upgrade installation procedure_. > > Reading that made me pause for a second and made me go "WOW", this is how= UNIX system upgrades should be done. Any hope of us lowly users ever seein= g something like this implemented in FreeBSD? :) > > - Dan Naumov > > > > > > On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox wro= te: >> >> >> The system boots from a pair of drives in a gmirror.=A0 Mot because you = can't boot from ZFS, but because it's just so darn stable (and it predates = the use of ZFS). >> >> Really there are two camps here --- booting from ZFS is the use of ZFS a= s the machine's own filesystem.=A0 This is one goal of ZFS that is somewhat= imperfect on FreeBSD at the momment.=A0 ZFS file servers are another goal = where booting from ZFS is not really required and only marginally beneficia= l. >> >> > From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 20:30:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 695DA106566B; Tue, 2 Jun 2009 20:30:51 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id ED6558FC18; Tue, 2 Jun 2009 20:30:50 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from [192.168.1.22] (helium.xs4all.nl [194.109.251.55]) (authenticated bits=0) by erg.verweg.com (8.14.3/8.14.3) with ESMTP id n52KUlcx068558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Jun 2009 20:30:47 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host helium.xs4all.nl [194.109.251.55] claimed to be [192.168.1.22] Message-Id: From: Ruben van Staveren To: Doug Barton In-Reply-To: <4A257B82.1000701@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 22:30:46 +0200 References: <4A257B82.1000701@FreeBSD.org> X-Mailer: Apple Mail (2.935.3) X-Spam-Status: No, score=3.3 required=5.0 tests=DATE_IN_FUTURE_12_24 autolearn=no version=3.2.5 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on erg.verweg.com X-Virus-Scanned: ClamAV 0.94.2/9414/Tue Jun 2 11:11:57 2009 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (erg.verweg.com [94.142.245.8]); Tue, 02 Jun 2009 20:30:49 +0000 (UTC) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 20:30:52 -0000 On 2 Jun 2009, at 21:20, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I removed > that warning in HEAD Sunday, and there is no a discussion about > whether or not it should be put back, and whether or not there is any > need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a ipv6_ifconfig_bge1="down" and nail network_interfaces to bge0 bge1 lo0 only I'll get autoconfiguration of v6 where I don't want it to be. Being a bit of my own devils advocate here, network_interfaces="AUTO" is already true for ipv6. with network_interfaces="bge0 lo0" network.subr nevertheless sees bge1, and no configuration and takes the responsibility of starting ipv6 autoconfiguration for it. > If you use a value of network_interfaces other than AUTO please speak > up so that we can make an intelligent decision about this issue. you want to have a system where one still can control which interfaces are explicitly configured or skipped, with no side effects of default actions > > > Thanks, > > Doug > _______________________________________________ > 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 > " > Regards, Ruben From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 20:49:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BC651065686 for ; Tue, 2 Jun 2009 20:49:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 89D8D8FC2C for ; Tue, 2 Jun 2009 20:49:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30078 invoked by uid 399); 2 Jun 2009 20:48:57 -0000 Received: from localhost (HELO ?192.168.0.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jun 2009 20:48:57 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A259039.8040001@FreeBSD.org> Date: Tue, 02 Jun 2009 13:48:57 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ruben van Staveren References: <4A257B82.1000701@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 20:49:07 -0000 Ruben van Staveren wrote: > Being a bit of my own devils advocate here, network_interfaces="AUTO" is > already true for ipv6. FYI, ipv6_network_interfaces exists for this purpose. Thanks for your post, it's good information to add to the pile. Doug From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 21:19:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B83D11065674 for ; Tue, 2 Jun 2009 21:19:27 +0000 (UTC) (envelope-from dkelly@Grumpy.DynDNS.org) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by mx1.freebsd.org (Postfix) with ESMTP id 66EAD8FC1E for ; Tue, 2 Jun 2009 21:19:26 +0000 (UTC) (envelope-from dkelly@Grumpy.DynDNS.org) Received: (qmail 20006 invoked by uid 0); 2 Jun 2009 20:51:25 -0000 Received: from unknown (HELO Grumpy.DynDNS.org) (24.42.224.110) by smtp7.knology.net with SMTP; 2 Jun 2009 20:51:25 -0000 Received: by Grumpy.DynDNS.org (Postfix, from userid 928) id 38EEA2841F; Tue, 2 Jun 2009 15:51:25 -0500 (CDT) Date: Tue, 2 Jun 2009 15:51:25 -0500 From: David Kelly To: Ruben van Staveren Message-ID: <20090602205125.GA75470@Grumpy.DynDNS.org> References: <4A257B82.1000701@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 21:19:28 -0000 On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > > >Up till Sunday in 8-current, and for a long time in general > >network.subr (part of the rc.d system) has emitted a warning that > >values of network_interfaces other than AUTO are deprecated. I > >removed that warning in HEAD Sunday, and there is no a discussion > >about whether or not it should be put back, and whether or not there > >is any need for the user to specify the list of network interfaces at > >all. > > Well, I do. > > I only want to configure only the interfaces that are connected and > that I know about. especially in combination with IPv6 there is a nit > that you'll get autoconfiguration for all interfaces unless they are > all explicitly configured. And while I'm not currently using anything other than AUTO I would think there is a security ramification if someone were to plug in to a supposedly unused port, then reboot the machine to prompt AUTO to configure their interface. Its not just a security thing, its an "idiot-proof" thing. If someone is moving machines around I don't want them to come up and partially work if the wires are plugged into the wrong holes. Would rather it be completely broken. I think its good that there is an AUTO *option*. Is also OK that it be the default. I don't think mandatory AUTO is good, if I want a port disabled then I want it to stay disabled. A quick glance of my 7.2-STABLE machine only found network_interfaces used in /etc/defaults/rc.conf. ipv6_network_interfaces is used in many places. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 22:06:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C02010656B5; Tue, 2 Jun 2009 22:06:13 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 01F0E8FC15; Tue, 2 Jun 2009 22:06:12 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n52M6Odo018821; Tue, 2 Jun 2009 17:06:24 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n52M6OeV018820; Tue, 2 Jun 2009 17:06:24 -0500 (CDT) (envelope-from brooks) Date: Tue, 2 Jun 2009 17:06:24 -0500 From: Brooks Davis To: David Kelly Message-ID: <20090602220624.GD15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hxkXGo8AKqTJ+9QI" Content-Disposition: inline In-Reply-To: <20090602205125.GA75470@Grumpy.DynDNS.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 02 Jun 2009 17:06:24 -0500 (CDT) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 22:06:14 -0000 --hxkXGo8AKqTJ+9QI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 02, 2009 at 03:51:25PM -0500, David Kelly wrote: > On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > >=20 > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > >=20 > > >Up till Sunday in 8-current, and for a long time in general > > >network.subr (part of the rc.d system) has emitted a warning that > > >values of network_interfaces other than AUTO are deprecated. I > > >removed that warning in HEAD Sunday, and there is no a discussion > > >about whether or not it should be put back, and whether or not there > > >is any need for the user to specify the list of network interfaces at > > >all. > >=20 > > Well, I do. > >=20 > > I only want to configure only the interfaces that are connected and > > that I know about. especially in combination with IPv6 there is a nit > > that you'll get autoconfiguration for all interfaces unless they are > > all explicitly configured. >=20 > And while I'm not currently using anything other than AUTO I would think > there is a security ramification if someone were to plug in to a > supposedly unused port, then reboot the machine to prompt AUTO to > configure their interface. >=20 > Its not just a security thing, its an "idiot-proof" thing. If someone is > moving machines around I don't want them to come up and partially work > if the wires are plugged into the wrong holes. Would rather it be > completely broken. >=20 > I think its good that there is an AUTO *option*. Is also OK that it be > the default. I don't think mandatory AUTO is good, if I want a port > disabled then I want it to stay disabled. To repeat what I wrote earlier today on another list there's no need to worry about hot plugged or newly added interfaces getting magically configured to do dhcp or anything else[0]. For the system to do something with an interface the following must be true: - It makes it in to the list of interfaces somehow (either by adding it to network_interfaces or leaving network_interfaces alone) - It actually exists or is create early in the process via cloned_interfaces, gif_interfaces, etc - The ifconfig_ variable is set (I think i can be "", but "up" is always a good choice if you just want a stub. - The ifconfig_ variable must not contain the NOAUTO keyword. If all of those things are true, the interface will be configured at startup or on insert. Otherwise, it won't be. -- Brooks [0] This is at least true in the IPv4 case, the IPv6 case really needs work. I thought someone had patches to bring the IPv6 support up to par with the IPv4 case, but they haven't been committed yet. --hxkXGo8AKqTJ+9QI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJaJfXY6L6fI4GtQRAsTIAJ44ujZ0IyN+UOFfrEYO+fOuoPJU/QCfUQ9L QDD118Wna7ApeNBlsLL0pcE= =56aR -----END PGP SIGNATURE----- --hxkXGo8AKqTJ+9QI-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 22:09:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20DF510656A8; Tue, 2 Jun 2009 22:09:22 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 843BC8FC23; Tue, 2 Jun 2009 22:09:21 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n52M9X5G018858; Tue, 2 Jun 2009 17:09:33 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n52M9XvM018857; Tue, 2 Jun 2009 17:09:33 -0500 (CDT) (envelope-from brooks) Date: Tue, 2 Jun 2009 17:09:33 -0500 From: Brooks Davis To: Ruben van Staveren Message-ID: <20090602220933.GE15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q8BnQc91gJZX4vDc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 02 Jun 2009 17:09:33 -0500 (CDT) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 22:09:23 -0000 --Q8BnQc91gJZX4vDc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: >=20 > On 2 Jun 2009, at 21:20, Doug Barton wrote: >=20 >> Up till Sunday in 8-current, and for a long time in general >> network.subr (part of the rc.d system) has emitted a warning that >> values of network_interfaces other than AUTO are deprecated. I removed >> that warning in HEAD Sunday, and there is no a discussion about >> whether or not it should be put back, and whether or not there is any >> need for the user to specify the list of network interfaces at all. >=20 > Well, I do. >=20 > I only want to configure only the interfaces that are connected and that = I=20 > know about. especially in combination with IPv6 there is a nit that you'l= l=20 > get autoconfiguration for all interfaces unless they are all explicitly= =20 > configured. See my other post on why this is a needless worry for the IPv4 case. > e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a=20 > ipv6_ifconfig_bge1=3D"down" and nail network_interfaces to bge0 bge1 lo0 = only=20 > I'll get autoconfiguration of v6 where I don't want it to be. >=20 >=20 > Being a bit of my own devils advocate here, network_interfaces=3D"AUTO" i= s=20 > already true for ipv6. with network_interfaces=3D"bge0 lo0" network.subr= =20 > nevertheless sees bge1, and no configuration and takes the responsibility= =20 > of starting ipv6 autoconfiguration for it. The IPv6 case is clearly a bug. We should really consolidate the two cases and I think there are patches to do so if someone wants to setup up and help get them in. -- Brooks --Q8BnQc91gJZX4vDc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJaMbXY6L6fI4GtQRApXSAJ409BZvxW77XiaT8jHFpTh5YJgHEQCg2AiK y4z8ZdrHH5k//BBnWsrv4mc= =lupY -----END PGP SIGNATURE----- --Q8BnQc91gJZX4vDc-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 22:20:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53BC8106566B; Tue, 2 Jun 2009 22:20:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 307CF8FC1B; Tue, 2 Jun 2009 22:20:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBcLq-000KsI-DR; Tue, 02 Jun 2009 22:20:58 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id DD2A41DA5B0B; Wed, 3 Jun 2009 07:20:57 +0900 (JST) Date: Wed, 03 Jun 2009 07:20:57 +0900 Message-ID: From: Randy Bush To: Ruben van Staveren In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 22:20:59 -0000 > I only want to configure only the interfaces that are connected and > that I know about. especially in combination with IPv6 there is a nit > that you'll get autoconfiguration for all interfaces unless they are > all explicitly configured. bingo! From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 22:22:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC1C106564A; Tue, 2 Jun 2009 22:22:35 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB968FC1D; Tue, 2 Jun 2009 22:22:35 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBcNO-000KsQ-Ng; Tue, 02 Jun 2009 22:22:34 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 1E09C1DA5DA1; Wed, 3 Jun 2009 07:22:34 +0900 (JST) Date: Wed, 03 Jun 2009 07:22:34 +0900 Message-ID: From: Randy Bush To: Brooks Davis In-Reply-To: <20090602220624.GD15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> <20090602220624.GD15552@lor.one-eyed-alien.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: David Kelly , Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 22:22:35 -0000 > To repeat what I wrote earlier today on another list there's no need > to worry about hot plugged or newly added interfaces getting magically > configured to do dhcp or anything else[0]. such as detected by services such as bind/unbound? randy From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 22:29:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DD93106567C; Tue, 2 Jun 2009 22:29:21 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id AB2608FC18; Tue, 2 Jun 2009 22:29:20 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 02 Jun 2009 18:00:55 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.5-GA) with ESMTP id PYC58560; Tue, 2 Jun 2009 18:00:54 -0400 (EDT) Received: from 209-6-22-188.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 02 Jun 2009 18:00:54 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18981.41237.246524.796@jerusalem.litteratus.org> Date: Tue, 2 Jun 2009 18:00:53 -0400 To: Ruben van Staveren In-Reply-To: References: X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 22:29:21 -0000 Ruben van Staveren writes: > > Up till Sunday in 8-current, and for a long time in general > > network.subr (part of the rc.d system) has emitted a warning that > > values of network_interfaces other than AUTO are deprecated. I removed > > that warning in HEAD Sunday, and there is no a discussion about > > whether or not it should be put back, and whether or not there is any > > need for the user to specify the list of network interfaces at all. > > Well, I do. > > I only want to configure only the interfaces that are connected and > that I know about. What he said. In my case complicated by the fact the interfaces in question do some wierd-ass initialization (which is legacy from like sometime in 5.x and might be unnecessary ... but it took a long time to get working and isn't broke). Robert Huff From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 22:32:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEE5E1065673 for ; Tue, 2 Jun 2009 22:32:51 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 717AA8FC1C for ; Tue, 2 Jun 2009 22:32:51 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id DA98071F212; Tue, 2 Jun 2009 18:32:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC43wnFcyLXK; Tue, 2 Jun 2009 18:32:50 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id B6C9271F1D8; Tue, 2 Jun 2009 18:32:50 -0400 (EDT) Message-ID: <4A25A892.80903@egr.msu.edu> Date: Tue, 02 Jun 2009 18:32:50 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 To: Dan Naumov References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Zaphod Beeblebrox , freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 22:32:52 -0000 I have a proof of concept system doing this. I started with a 7.2 install on zfs root, compiled world and kernel from 8, took a snapshot and made a clone for the 7.2 install, and proceeded to upgrade the current fs to 8.0. After updating the loader.conf in the 7.2 zfs to point to its own cloned fs, I can pick which one to boot with a simple "zpool set bootfs=z/ROOT/7.2" or "zpool set bootfs=z/ROOT/8.0" before rebooting. I also tried rsyncing from a FFS based system into a new ZFS in that same zpool, used DESTDIR with installkernel and installworld to update the imported OS to support zfs, setup its boot loader and misc config files, and was able to boot from it using zpool to set it as the bootfs. Somewhat like shifting around OS images in a virtualization environment except its easy to reach inside the "image" to upgrade/modify it, copy them between systems, and no execution overhead while running one since its still on bare metal (but only one running OS per server of course). This makes it very easy to swap an OS onto another server if you need better/lesser hardware or just want to test. Dan Naumov wrote: > This reminds me. I was reading the release and upgrade notes of OpenSolaris > 2009.6 and noted one thing about upgrading from a previous version to the > new one:: > > When you pick the "upgrade OS" option in the OpenSolaris installer, it will > check if you are using a ZFS root partition and if you do, it intelligently > suggests to take a current snapshot of the root filesystem. After you finish > the upgrade and do a reboot, the boot menu offers you the option of booting > the new upgraded version of the OS or alternatively _booting from the > snapshot taken by the upgrade installation procedure_. > > Reading that made me pause for a second and made me go "WOW", this is how > UNIX system upgrades should be done. Any hope of us lowly users ever seeing > something like this implemented in FreeBSD? :) > > - Dan Naumov > > > > > > On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox wrote: > > >> The system boots from a pair of drives in a gmirror. Mot because you can't >> boot from ZFS, but because it's just so darn stable (and it predates the use >> of ZFS). >> >> Really there are two camps here --- booting from ZFS is the use of ZFS as >> the machine's own filesystem. This is one goal of ZFS that is somewhat >> imperfect on FreeBSD at the momment. ZFS file servers are another goal >> where booting from ZFS is not really required and only marginally >> beneficial. >> >> >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 22:48:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B0CB10656FB; Tue, 2 Jun 2009 22:48:41 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id BDC038FC15; Tue, 2 Jun 2009 22:48:40 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n52MmqQp019195; Tue, 2 Jun 2009 17:48:52 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n52MmqUL019194; Tue, 2 Jun 2009 17:48:52 -0500 (CDT) (envelope-from brooks) Date: Tue, 2 Jun 2009 17:48:52 -0500 From: Brooks Davis To: Randy Bush Message-ID: <20090602224852.GF15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> <20090602220624.GD15552@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TU+u6i6jrDPzmlWF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 02 Jun 2009 17:48:52 -0500 (CDT) Cc: David Kelly , Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 22:48:42 -0000 --TU+u6i6jrDPzmlWF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 07:22:34AM +0900, Randy Bush wrote: > > To repeat what I wrote earlier today on another list there's no need > > to worry about hot plugged or newly added interfaces getting magically > > configured to do dhcp or anything else[0]. >=20 > such as detected by services such as bind/unbound? The rc system will do nothing with interfaces that don't pass the tests I enumerated so if you don't have an ifconfig_ interface there won't be any difference no matter how you set network_interfaces. I'd be rather supprised if bind did anything with interaces that weren't configured with an address (or even up in the case of correctly funtioning drivers). -- Brooks --TU+u6i6jrDPzmlWF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJaxTXY6L6fI4GtQRAgh6AJ9zQvOVNC5NIoQAvjfljCTRAjF4+QCbBiCZ UuhCwCv4FQm3vK9Nvh7CqDY= =+BW4 -----END PGP SIGNATURE----- --TU+u6i6jrDPzmlWF-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 2 23:26:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F2E910656AA; Tue, 2 Jun 2009 23:26:35 +0000 (UTC) (envelope-from erik@barragry.com) Received: from cork.barragry.com (cork.barragry.com [72.232.202.93]) by mx1.freebsd.org (Postfix) with ESMTP id 5241E8FC0C; Tue, 2 Jun 2009 23:26:35 +0000 (UTC) (envelope-from erik@barragry.com) Received: by cork.barragry.com (Postfix, from userid 1006) id 1F57E1D8012; Tue, 2 Jun 2009 18:06:48 -0500 (CDT) Date: Tue, 2 Jun 2009 18:06:48 -0500 From: Erik Osterholm To: Doug Barton Message-ID: <20090602230648.GB88740@barragry.com> References: <4A257B82.1000701@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A257B82.1000701@FreeBSD.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jun 2009 23:26:36 -0000 On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I > removed that warning in HEAD Sunday, and there is no a discussion > about whether or not it should be put back, and whether or not there > is any need for the user to specify the list of network interfaces > at all. > > If you use a value of network_interfaces other than AUTO please > speak up so that we can make an intelligent decision about this > issue. > > Thanks, > > Doug I'll have to preface this by disclosing that I have not been running -current, nor following any changes to the RC system. In 7.1, if you compile a custom kernel and comment out an interface (such that it is compiled as a module), one way to ensure that the module is loaded is to explicitly list it in network_interfaces. If -current works the same way, then users will be required to modify /boot/loader.conf in order to load the module. Could there could be possible side-effects to this change, since the loading of the module happens at a different time? At best, users doing things the 'network_interfaces' way may be in for a surprise when the update (remotely), and this may be worthy of a note in UPDATING. If this has changed in 7.2 or -current, then I apologize for the noise! Erik From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 12:15:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87F11106564A for ; Wed, 3 Jun 2009 12:15:56 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 20E4F8FC08 for ; Wed, 3 Jun 2009 12:15:55 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by bwz9 with SMTP id 9so8835953bwz.43 for ; Wed, 03 Jun 2009 05:15:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.109.199 with SMTP id k7mr500476fap.45.1244031354821; Wed, 03 Jun 2009 05:15:54 -0700 (PDT) From: Vlad Galu Date: Wed, 3 Jun 2009 15:15:32 +0300 Message-ID: To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=001636c5ab5bfe60d8046b709e6b Subject: poll()-ing a pipe descriptor, watching for POLLHUP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 12:15:56 -0000 --001636c5ab5bfe60d8046b709e6b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? Thanks, Vlad --001636c5ab5bfe60d8046b709e6b Content-Type: application/octet-stream; name="poll.cpp" Content-Disposition: attachment; filename="poll.cpp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fvi00x8j0 I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3dhaXQuaD4KI2luY2x1ZGUgPHBv bGwuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgoKI2luY2x1ZGUgPGlvc3RyZWFtPgojaW5jbHVkZSA8 bWFwPgojaW5jbHVkZSA8dmVjdG9yPgp1c2luZyBuYW1lc3BhY2Ugc3RkOwoKaW50IG1haW4oaW50 IGFyZ2MsIGNoYXIqIGFyZ3ZbXSkgewoJbWFwPHBpZF90LCBpbnQ+IGNoaWxkcmVuOwoKCWZvciAo aW50IGkgPSAwOyBpIDwgNDsgaSsrKSB7CgkJaW50IHBpcGVwYWlyWzJdOwoJCWlmICghcGlwZShw aXBlcGFpcikpIHsKCQkJcGlkX3QgcGlkID0gZm9yaygpOwoJCQlpZiAocGlkID4gMCkgewkvLyBw YXJlbnQKCQkJCWNoaWxkcmVuW3BpZF0gPSBwaXBlcGFpclswXTsKCQkJCWNvdXQgPDwgIkNoaWxk IHByb2Nlc3MgIiA8PCBwaWQgPDwgIiBzcGF3bmVkIiA8PCBlbmRsOwoJCQl9IGVsc2UgaWYgKHBp ZCA9PSAwKSB7IC8vIGNoaWxkCgkJCQkvLyBzbGVlcCBmb3IgYSB3aGlsZQoJCQkJc2xlZXAoNSk7 CgkJCQkvLyBncmFjZWZ1bGx5IGV4aXQKCQkJCWV4aXQoMCk7CgkJCX0KCQl9IGVsc2UKCQkJY2Vy ciA8PCAiQ291bGRuJ3QgY3JlYXRlIHRoZSBwaXBlcyEiIDw8IGVuZGw7Cgl9CgoJLy8gY2hlY2sg dGhlIGNoaWxkcmVuCgl3aGlsZSAoIWNoaWxkcmVuLmVtcHR5KCkpIHsKCQlmb3IgKG1hcDxwaWRf dCwgaW50Pjo6aXRlcmF0b3IgaXQgPSBjaGlsZHJlbi5iZWdpbigpOyBpdCAhPSBjaGlsZHJlbi5l bmQoKTsgaXQrKykgewoJCQkvLyBwb2xsIGVhY2ggY2hpbGQncyBwaXBlIHRvIGNoZWNrIGZvciBk YXRhCgkJCXN0cnVjdCBwb2xsZmQgcGZkID0geyBpdC0+c2Vjb25kLCBQT0xMSU4sIDAgfTsKCQkJ aW50IHBvbGxyZXQgPSBwb2xsKCZwZmQsIDEsIDEwMDApOwoJCQljb3V0IDw8ICJwb2xscmV0OiAi IDw8IHBvbGxyZXQgPDwgZW5kbDsKCQkJaWYgKHBvbGxyZXQgPiAwKSB7CgkJCQlpZiAoKHBmZC5y ZXZlbnRzICYgUE9MTElOKSAmJiAocGZkLnJldmVudHMgJiBQT0xMSFVQKSkKCQkJCQljb3V0IDw8 ICJDaGlsZCAiIDw8IGl0LT5maXJzdCA8PCAiIGV4aXRlZCEiIDw8IGVuZGw7CgoJCQkJaWYgKHBm ZC5yZXZlbnRzICYgUE9MTElOKSB7CgkJCQkJdmVjdG9yPGNoYXI+IHRtcGJ1Zig0KTsKCQkJCQlp bnQgcmVhZHJldCA9IHJlYWQoaXQtPnNlY29uZCwgJnRtcGJ1ZlswXSwgNCk7CgoJCQkJCWlmIChy ZWFkcmV0ID4gMCkKCQkJCQkJY291dCA8PCAiQ2hpbGQgIiA8PCBpdC0+Zmlyc3QgPDwgIiBzYWlk OiAiIDw8IHN0cmluZyh0bXBidWYuYmVnaW4oKSwgdG1wYnVmLmVuZCgpKSA8PCBlbmRsOwoJCQkJ CWVsc2UgaWYgKHJlYWRyZXQgPT0gMCkKCQkJCQkJY291dCA8PCAiRU9GIGZyb20gY2hpbGQgIiA8 PCBpdC0+Zmlyc3QgPDwgIiwgbXVzdCd2ZSBleGl0ZWQiIDw8IGVuZGw7CgkJCQkJZWxzZSBpZiAo cmVhZHJldCA8IDApCgkJCQkJCWNvdXQgPDwgIlJlYWQgZXJyb3IiIDw8IGVuZGw7CgkJCQl9CgkJ CX0KCgkJCWludCBzdGF0dXMgPSAwOwoJCQlpZiAod2FpdHBpZChpdC0+Zmlyc3QsICZzdGF0dXMs IFdOT0hBTkcpKSB7CgkJCQlpZiAoV0lGRVhJVEVEKHN0YXR1cykpIHsKCQkJCQljb3V0IDw8ICJD aGlsZCAiIDw8IGl0LT5maXJzdCA8PCAiIHN0b3BwZWQiIDw8IGVuZGw7Ci8vCQkJCQljaGlsZHJl bi5lcmFzZShpdCsrKTsKCQkJCX0KCQkJfSBlbHNlIHsKLy8JCQkJKytpdDsKCQkJfQoJCQlzbGVl cCgxKTsKCQl9Cgl9Cn0KCi8vIHZpOnRzPTQKCg== --001636c5ab5bfe60d8046b709e6b-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 12:25:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBF51106564A for ; Wed, 3 Jun 2009 12:25:36 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id 5AECF8FC15 for ; Wed, 3 Jun 2009 12:25:35 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fxm7 with SMTP id 7so2621668fxm.43 for ; Wed, 03 Jun 2009 05:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.104.74 with SMTP id n10mr534121fao.5.1244031935175; Wed, 03 Jun 2009 05:25:35 -0700 (PDT) In-Reply-To: References: From: Vlad Galu Date: Wed, 3 Jun 2009 15:25:14 +0300 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: poll()-ing a pipe descriptor, watching for POLLHUP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 12:25:37 -0000 Hm, according to the code at http://www.greenend.org.uk/rjk/2001/06/poll.html, it seems to work as expected (returning both POLLIN and POLLHUP), when closing the write end of the pipe from within the same process. On Wed, Jun 3, 2009 at 3:15 PM, Vlad Galu wrote: > Hello, > > Please take a look at the attached code. Shouldn't poll() get a > POLLHUP event when the child process exits, closing the write end of > the pipe? > > Thanks, > Vlad > From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 12:32:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 081671065672 for ; Wed, 3 Jun 2009 12:32:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id A08178FC15 for ; Wed, 3 Jun 2009 12:32:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MBpdb-000MD4-NA; Wed, 03 Jun 2009 15:32:11 +0300 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 n53CW8ka059880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 15:32:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n53CW8Nu044003; Wed, 3 Jun 2009 15:32:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n53CW8Ap044002; Wed, 3 Jun 2009 15:32:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Jun 2009 15:32:08 +0300 From: Kostik Belousov To: Vlad Galu Message-ID: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P/XS8wfvSybnnBkt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MBpdb-000MD4-NA 3726c448bc926a66023c8bf49fac77d8 X-Terabit: YES Cc: freebsd-stable@freebsd.org Subject: Re: poll()-ing a pipe descriptor, watching for POLLHUP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 12:32:14 -0000 --P/XS8wfvSybnnBkt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: > Hello, >=20 > Please take a look at the attached code. Shouldn't poll() get a > POLLHUP event when the child process exits, closing the write end of > the pipe? It seems that you code forgot to close the write end of the pipe in parent. Thus, pipe is referenced by another file descriptor from the parent process, and you do not get close event. --P/XS8wfvSybnnBkt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkombUgACgkQC3+MBN1Mb4iUXwCguGpFVwSoqdLGQTXPgREz6qQ9 dVIAn27VmRGfYLY7sU4d4th1rvWFhfD8 =c69w -----END PGP SIGNATURE----- --P/XS8wfvSybnnBkt-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 12:36:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E83106566B for ; Wed, 3 Jun 2009 12:36:16 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 59D6E8FC22 for ; Wed, 3 Jun 2009 12:36:16 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by bwz9 with SMTP id 9so8850337bwz.43 for ; Wed, 03 Jun 2009 05:36:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.109.199 with SMTP id k7mr520294fap.45.1244032575133; Wed, 03 Jun 2009 05:36:15 -0700 (PDT) In-Reply-To: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> From: Vlad Galu Date: Wed, 3 Jun 2009 15:35:54 +0300 Message-ID: To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: poll()-ing a pipe descriptor, watching for POLLHUP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 12:36:17 -0000 On Wed, Jun 3, 2009 at 3:32 PM, Kostik Belousov wrote: > On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: >> Hello, >> >> Please take a look at the attached code. Shouldn't poll() get a >> POLLHUP event when the child process exits, closing the write end of >> the pipe? > > It seems that you code forgot to close the write end of the pipe in > parent. Thus, pipe is referenced by another file descriptor from > the parent process, and you do not get close event. > Aaarhg! You're right! Sorry for the noise! From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 13:10:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B054B1065670 for ; Wed, 3 Jun 2009 13:10:55 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD878FC0A for ; Wed, 3 Jun 2009 13:10:55 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fxm7 with SMTP id 7so2653021fxm.43 for ; Wed, 03 Jun 2009 06:10:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.74 with SMTP id e10mr550677fap.35.1244034654285; Wed, 03 Jun 2009 06:10:54 -0700 (PDT) In-Reply-To: References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> From: Vlad Galu Date: Wed, 3 Jun 2009 16:10:34 +0300 Message-ID: To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: poll()-ing a pipe descriptor, watching for POLLHUP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 13:10:56 -0000 On Wed, Jun 3, 2009 at 3:35 PM, Vlad Galu wrote: > On Wed, Jun 3, 2009 at 3:32 PM, Kostik Belousov wrote: >> On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: >>> Hello, >>> >>> Please take a look at the attached code. Shouldn't poll() get a >>> POLLHUP event when the child process exits, closing the write end of >>> the pipe? >> >> It seems that you code forgot to close the write end of the pipe in >> parent. Thus, pipe is referenced by another file descriptor from >> the parent process, and you do not get close event. >> > > Aaarhg! You're right! Sorry for the noise! > Hm, I was having an issue with an internal piece of software, but never checked what kind of pipe caused the problem. Turns out it was a FIFO, and I got bitten by the same bug described here: http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html The problem is that the reader process isn't notified when the writer process exits or closes the FIFO fd... From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 13:42:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 546D91065688 for ; Wed, 3 Jun 2009 13:42:16 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id D66468FC27 for ; Wed, 3 Jun 2009 13:42:11 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from furia.intranet ([93.104.53.72]) (AUTH: LOGIN lopez.on.the.lists@yellowspace.net) by mail.yellowspace.net with esmtp; Wed, 03 Jun 2009 15:42:09 +0200 id 0048F502.000000004A267DB1.00016CAD Message-Id: <4CB9BD6A-EB09-4FF0-AC34-74CF36837381@yellowspace.net> From: Lorenzo Perone To: Lorenzo Perone In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 3 Jun 2009 15:42:08 +0200 References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <63548432-B73D-4A08-BA99-FEF5BCC1028A@yellowspace.net> <20090531071759.GA35763@egr.msu.edu> X-Mailer: Apple Mail (2.935.3) Cc: Mickael MAILLOT , Adam McDougall , FreeBSD Stable Mailing List Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 13:42:17 -0000 OK, so I've got my next little adventure here to share :-) ... after reading Your posts I was very eager to give the whole boot-zfs-without-partitions thing a new try. My starting situation was a ZFS mirror made up, as I wrote, of two GPT partitions, so my pool looked like: phaedrus# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ad6p4 ONLINE 0 0 0 ad4p4 ONLINE 0 0 0 it was root-mounted and everything was seemingly working fine, with the machine surviving several bonnie++'s, sysbenches, and supersmacks concurrently for many hours (cool!). So to give it another try my plan was to detach one partition, clear the gmirror on the UFS boot partition, make a new pool made out of the free disk and start the experiment over. it looked almost like this: zpool offline tank ad4p4 zpool detach tank ad4p4 gmirror stop gmboot (made out of ad6p2 and ad4p2) gmirror remove gmboot ad4p2 then I had to reboot cause it wouldn't give up on the swap partition on the zpool. That's where the first problem began: it wouldn't boot anymore... just because I removed a device? In this case I was stuck at the mountroot: stage. It wouldn't find the root filesystem on zfs. (this happened also when physically detaching ad4). So I booted off a recent 8-CURRENT iso DVD, and although the mounroot stage is, iirc, at a later stage than the loader, I smelled it could have something to do with it and downloaded Adam's CURRENT/ZFS loader, put it in the appropriate place on my UFS boot partition... note: From the CD, I had to import the pool with zpool import -o altroot=/somewhere tank to avoid having problems with the datasets being mounted on top of the 8-fixit environment's /usr ... Ok, rebooted, and whoops it would boot again in the previous environment. So... from there I started over with the creation of a ZFS-bootonly situation on ad4 (with the intention of zpool-attaching ad6 later on) dd if=/dev/zero bs=1m of=/dev/ad4 count=200 (just to be safe, some 'whitespace'..) zpool create esso da4 zfs snapshot -r tank@night zfs send -R tank@night | zfs recv -d -F esso (it did what it had to do - cool new v13 feature BTW!) zpool export esso dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 dd if=/boot/zfsboot of=/dev/ad4 bs=512 skip=1 seek=1024 zpool import esso zpool set bootfs=esso esso the mountpoints (legacy on the poolfs, esso, and the corresponding ones) had been correctly copied by the send -R. Just shortly mounted esso somewhere else, edited loader.conf and fstab, and put it back to legacy. shutdown -r now. Upon boot, it would wait a while, not present any F1/F5, and booted into the old environment (ad6p2 boot partition and then mounted tank as root). From there, a zfs list or zpool status just showed the root pool (tank), but the new one (esso) was not present. A zpool import showed: heidegger# zpool import pool: esso id: 865609520845688328 state: UNAVAIL status: One or more devices are missing from the system. action: The pool cannot be imported. Attach the missing devices and try again. see: http://www.sun.com/msg/ZFS-8000-3C config: esso UNAVAIL insufficient replicas ad4 UNAVAIL cannot open zpool import -f esso did not succeed, instead, looking on the console, I found ZFS: WARNING: could not open ad4 for writing I repeated the steps above two more times, making sure I had wiped everyhing off ad4 before trying... but it would always come up with that message. The disk is OK, the cables too, I triple-checked it. Besides, writing to the disk with other means (such as dd or creating a new pool) succeeded... (albeit after the usual sysctl kern.geom.debugflags=16 ...) well for now I think I'll stick to the GPT + UFS Root + ZFS Root solution (I'm so happy this works seemlessly, so this is a big THANX and not a complaint!), but I thought I'd share the latest hickups... I won't be getting to that machine for a few days before restoring to the gpt-ufs-based mirror, so if someone would like me to provide other info I'll be happy to contribute it. Big Regards! Lorenzo On 01.06.2009, at 19:09, Lorenzo Perone wrote: > On 31.05.2009, at 09:18, Adam McDougall wrote: > >> I encountered the same symptoms today on both a 32bit and 64bit >> brand new install using gptzfsboot. It works for me when I use >> a copy of loader from an 8-current box with zfs support compiled in. >> I haven't looked into it much yet but it might help you. If you >> want, you can try the loader I am using from: >> http://www.egr.msu.edu/~mcdouga9/loader > > Thanx for posting me your loader, I'll try with this tomorrow night! > (any hint, btw, on why the one in -STABLE seems to be > broken, or whether it has actually been fixed by now?) From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 14:13:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B0F41065675; Wed, 3 Jun 2009 14:13:13 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBED8FC16; Wed, 3 Jun 2009 14:13:12 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n53EDMp8029429; Wed, 3 Jun 2009 09:13:22 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n53EDLLc029428; Wed, 3 Jun 2009 09:13:21 -0500 (CDT) (envelope-from brooks) Date: Wed, 3 Jun 2009 09:13:21 -0500 From: Brooks Davis To: Erik Osterholm Message-ID: <20090603141321.GC28486@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602230648.GB88740@barragry.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OBd5C1Lgu00Gd/Tn" Content-Disposition: inline In-Reply-To: <20090602230648.GB88740@barragry.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 03 Jun 2009 09:13:22 -0500 (CDT) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 14:13:13 -0000 --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > Up till Sunday in 8-current, and for a long time in general > > network.subr (part of the rc.d system) has emitted a warning that > > values of network_interfaces other than AUTO are deprecated. I > > removed that warning in HEAD Sunday, and there is no a discussion > > about whether or not it should be put back, and whether or not there > > is any need for the user to specify the list of network interfaces > > at all. > >=20 > > If you use a value of network_interfaces other than AUTO please > > speak up so that we can make an intelligent decision about this > > issue. > >=20 > > Thanks, > >=20 > > Doug >=20 > I'll have to preface this by disclosing that I have not been running > -current, nor following any changes to the RC system. >=20 > In 7.1, if you compile a custom kernel and comment out an interface > (such that it is compiled as a module), one way to ensure that the > module is loaded is to explicitly list it in network_interfaces. If > -current works the same way, then users will be required to modify > /boot/loader.conf in order to load the module. Could there could be > possible side-effects to this change, since the loading of the module > happens at a different time? Do you actually do this? > At best, users doing things the 'network_interfaces' way may be in for > a surprise when the update (remotely), and this may be worthy of a > note in UPDATING. >=20 > If this has changed in 7.2 or -current, then I apologize for the > noise! The deprecation is a change relative to 7.0, but was in 7.1. -- Brooks --OBd5C1Lgu00Gd/Tn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJoUBXY6L6fI4GtQRAsgqAKCzq55ZffxXXs0D1DTb8XcF7IOMhgCfR2CK anLA01POzE4Uw0+wr2EVJHI= =HEew -----END PGP SIGNATURE----- --OBd5C1Lgu00Gd/Tn-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 14:30:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AEBA106564A for ; Wed, 3 Jun 2009 14:30:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id D10498FC14 for ; Wed, 3 Jun 2009 14:30:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MBrUV-000DUB-0D; Wed, 03 Jun 2009 17:30:55 +0300 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 n53EUqLG068198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 17:30:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n53EUp0d046061; Wed, 3 Jun 2009 17:30:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n53EUpB1046060; Wed, 3 Jun 2009 17:30:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Jun 2009 17:30:51 +0300 From: Kostik Belousov To: Vlad Galu Message-ID: <20090603143051.GM1927@deviant.kiev.zoral.com.ua> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jxLVDeTGe4tAzjlH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MBrUV-000DUB-0D 8cfc13a91a7d89a41b55d60f024764a4 X-Terabit: YES Cc: freebsd-stable@freebsd.org, Oliver Fromme Subject: Re: poll()-ing a pipe descriptor, watching for POLLHUP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 14:30:57 -0000 --jxLVDeTGe4tAzjlH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote: > Hm, I was having an issue with an internal piece of software, but > never checked what kind of pipe caused the problem. Turns out it was a > FIFO, and I got bitten by the same bug described here: > http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html >=20 > The problem is that the reader process isn't notified when the writer > process exits or closes the FIFO fd... So you did found the relevant PR with long audit trail and patches attached. You obviously should contact the author of the patches, Oliver Fromme, who is FreeBSD committer for some time (CCed). I agree that the thing shall be fixed finally. Skimming over the patches in kern/94772, I have some doubts about removal of POLLINIGNEOF flag. The reason is that we are generally do not remove exposed user interfaces. --jxLVDeTGe4tAzjlH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkomiRsACgkQC3+MBN1Mb4i5QwCg38abRFz3z8NlU8plofI6HPSW 5rkAn2bBljcyVHzNbj8VBTZzKZsN0Z0s =6P8O -----END PGP SIGNATURE----- --jxLVDeTGe4tAzjlH-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 14:42:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4462F1065675 for ; Wed, 3 Jun 2009 14:42:53 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5DA8FC22 for ; Wed, 3 Jun 2009 14:42:52 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 75328 invoked from network); 3 Jun 2009 14:42:51 -0000 Received: from unknown (HELO snowwhite.local) (smtpsend@62.220.7.20) by mail.h3q.com with AES256-SHA encrypted SMTP; 3 Jun 2009 14:42:51 -0000 Message-ID: <4A268BEA.5040706@h3q.com> Date: Wed, 03 Jun 2009 16:42:50 +0200 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dan Naumov References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Zaphod Beeblebrox , freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 14:42:53 -0000 Dan Naumov wrote: > > Reading that made me pause for a second and made me go "WOW", this is how > UNIX system upgrades should be done. Any hope of us lowly users ever seeing > something like this implemented in FreeBSD? :) I wrote a script implementing the most useful features of the solaris live upgrade, the only thing missing is selecting a boot-environment from the loader and freebsd-update support as I write the script on a system running current. I use this on all my freebsd-zfs boxes and it is extremely useful! http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE greetings, philipp From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 14:48:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8DB106567B; Wed, 3 Jun 2009 14:48:28 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id B823E8FC28; Wed, 3 Jun 2009 14:48:27 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from guest-17.ripe.net (guest-17.ripe.net [193.0.2.17]) (authenticated bits=0) by erg.verweg.com (8.14.3/8.14.3) with ESMTP id n53EmJNo040445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Jun 2009 14:48:24 GMT (envelope-from ruben@verweg.com) Message-Id: From: Ruben van Staveren To: FreeBSD Mailing List , freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 3 Jun 2009 16:48:04 +0200 X-Mailer: Apple Mail (2.935.3) X-Spam-Status: No, score=3.1 required=5.0 tests=DATE_IN_FUTURE_06_12 autolearn=no version=3.2.5 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on erg.verweg.com X-Virus-Scanned: ClamAV 0.94.2/9418/Wed Jun 3 12:18:15 2009 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (erg.verweg.com [94.142.245.8]); Wed, 03 Jun 2009 14:48:26 +0000 (UTC) Cc: Subject: On the topic of network_interfaces, optional full automatic renaming of interfaces X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 14:48:28 -0000 Hi lists, Now the topic of network_interfaces has been mentioned, and the freeze for 8-stable is near I wonder if there is enough interest in the following feature to be included: http://ruben.is.verweg.com/stuff/freebsd/ifrename/ There is some dust there in that directory (It works, but is nowhere finished yet), but basically this early rc.d script takes the functionality of ifconfig_XXX_name a step further and enables optional automatic renaming of all ethernet capable interfaces, and enumerate them in the order probed by the kernel. A possible usage scenario is where you do massive imaging of a freebsd installation in where you don't know beforehand it will end up on hardware that has Broadcom or Intel NICs but it is for certain the cable will be connected to the first interface available and the same interface name can be referenced throughout all configuration files that need it (pf.conf, rc.conf(.local), /etc/rc.conf.d/network ) An other application usage is nailing down interface names using ethernet address, either because of correcting "mistakes" in the hardware (e.g. some Dell PowerEdges have the port labelled first to be probed as second and vice versa) or the necessity to only allow that interface to exist if it's MAC is the one that was configured (because of switch port ACL's) Regards, Ruben From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 14:56:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D481065673 for ; Wed, 3 Jun 2009 14:56:08 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id ED8788FC0A for ; Wed, 3 Jun 2009 14:56:07 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so16193ywe.13 for ; Wed, 03 Jun 2009 07:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OAyFeRfJ0p6q4jqLpBFfehQ5l/a6ZFRPmVN/+SFC7eo=; b=P1fi7wjxBvswt3FhnDQUq0nRdxY3q6I2FY0Lzm/RxGR26tDkCxpEw1XL8Nhh0WUk8N 474GZHcchK9mC6GO/oiAl5kE1yTat1o7I0MCrlwBOpZtgPMbKV7c99aQk2pak8o6osEi G107W6dzLx9jyzOI03AUzXBnf2NKRacy1mTyI= 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=fb9ybBdSICRpeRoph4cQ14VYS8aoPz3fJr3dhu++eHbFE94SJHS44P+SiEuiTgcXvl 1FAsy6GSg+H9B8krmePoP/UTsLgTXIDQPRnNlSYhyy+zvHqXoRI01tH/AL3uaciR+I4G Kd1TrsvTqGB959HWG6puMbsngrOnE+waIHn24= MIME-Version: 1.0 Received: by 10.100.10.15 with SMTP id 15mr1262142anj.8.1244040966891; Wed, 03 Jun 2009 07:56:06 -0700 (PDT) In-Reply-To: <4A268BEA.5040706@h3q.com> References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> <4A268BEA.5040706@h3q.com> Date: Wed, 3 Jun 2009 17:56:06 +0300 Message-ID: From: Dan Naumov To: Philipp Wuensche Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Zaphod Beeblebrox , freebsd-stable@freebsd.org Subject: Re: ZFS NAS configuration question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 14:56:08 -0000 Anyone else think that this combined with freebsd-update integration and a simplistic menu GUI for choosing the preferred boot environment would make an _awesome_ addition to the base system? :) - Dan Naumov On Wed, Jun 3, 2009 at 5:42 PM, Philipp Wuensche wrote: > I wrote a script implementing the most useful features of the solaris > live upgrade, the only thing missing is selecting a boot-environment > from the loader and freebsd-update support as I write the script on a > system running current. I use this on all my freebsd-zfs boxes and it is > extremely useful! > > http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE > > greetings, > philipp From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 15:07:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE337106564A; Wed, 3 Jun 2009 15:07:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 444CB8FC1B; Wed, 3 Jun 2009 15:07:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MBs3d-000IB1-V7; Wed, 03 Jun 2009 18:07:14 +0300 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 n53F7AW6071028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 18:07:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n53F7A4W046411; Wed, 3 Jun 2009 18:07:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n53F7ALs046410; Wed, 3 Jun 2009 18:07:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Jun 2009 18:07:10 +0300 From: Kostik Belousov To: Vlad Galu Message-ID: <20090603150710.GN1927@deviant.kiev.zoral.com.ua> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> <20090603143051.GM1927@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UNnSMTKiCAppeLf" Content-Disposition: inline In-Reply-To: <20090603143051.GM1927@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MBs3d-000IB1-V7 64bece8ad271cb2307d6c26bd7ee18d4 X-Terabit: YES Cc: freebsd-stable@freebsd.org, Oliver Fromme , bde@freebsd.org Subject: Re: poll()-ing a pipe descriptor, watching for POLLHUP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 15:07:15 -0000 --1UNnSMTKiCAppeLf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 05:30:51PM +0300, Kostik Belousov wrote: > On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote: > > Hm, I was having an issue with an internal piece of software, but > > never checked what kind of pipe caused the problem. Turns out it was a > > FIFO, and I got bitten by the same bug described here: > > http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html > >=20 > > The problem is that the reader process isn't notified when the writer > > process exits or closes the FIFO fd... >=20 > So you did found the relevant PR with long audit trail and patches > attached. You obviously should contact the author of the patches, > Oliver Fromme, who is FreeBSD committer for some time (CCed). >=20 > I agree that the thing shall be fixed finally. Skimming over the > patches in kern/94772, I have some doubts about removal of > POLLINIGNEOF flag. The reason is that we are generally do not > remove exposed user interfaces. I forward-ported Bruce' patch to the CURRENT. It passes the tests from tools/regression/fifo and a test from kern/94772. For my liking, I did not removed POLLINIGNEOF. diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c index 66963bc..7e279ca 100644 --- a/sys/fs/fifofs/fifo_vnops.c +++ b/sys/fs/fifofs/fifo_vnops.c @@ -226,11 +226,47 @@ fail1: if (ap->a_mode & FREAD) { fip->fi_readers++; if (fip->fi_readers =3D=3D 1) { + SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); + if (fip->fi_writers > 0) + fip->fi_readsock->so_rcv.sb_state |=3D + SBS_COULDRCV; + else + /* + * Sloppy? Might be necessary to clear it + * in all the places where fi_readers is + * decremented to 0. I think only writers + * polling for input could be confused by + * having it not set, and there is a problem + * with these anyway now that we have + * reversed the sense of the flag -- they + * now block (?), but shouldn't. + */ + fip->fi_readsock->so_rcv.sb_state &=3D + ~SBS_COULDRCV; + SOCKBUF_UNLOCK(&fip->fi_readsock->so_rcv); SOCKBUF_LOCK(&fip->fi_writesock->so_snd); fip->fi_writesock->so_snd.sb_state &=3D ~SBS_CANTSENDMORE; SOCKBUF_UNLOCK(&fip->fi_writesock->so_snd); if (fip->fi_writers > 0) { wakeup(&fip->fi_writers); + SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); + if (fip->fi_writers > 0) + fip->fi_readsock->so_rcv.sb_state |=3D + SBS_COULDRCV; + else + /* + * Sloppy? Might be necessary to clear it + * in all the places where fi_readers is + * decremented to 0. I think only writers + * polling for input could be confused by + * having it not set, and there is a problem + * with these anyway now that we have + * reversed the sense of the flag -- they + * now block (?), but shouldn't. + */ + fip->fi_readsock->so_rcv.sb_state &=3D + ~SBS_COULDRCV; + SOCKBUF_UNLOCK(&fip->fi_readsock->so_rcv); sowwakeup(fip->fi_writesock); } } @@ -244,6 +280,7 @@ fail1: if (fip->fi_writers =3D=3D 1) { SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); fip->fi_readsock->so_rcv.sb_state &=3D ~SBS_CANTRCVMORE; + fip->fi_readsock->so_rcv.sb_state |=3D SBS_COULDRCV; SOCKBUF_UNLOCK(&fip->fi_readsock->so_rcv); if (fip->fi_readers > 0) { wakeup(&fip->fi_readers); @@ -672,28 +709,10 @@ fifo_poll_f(struct file *fp, int events, struct ucred= *cred, struct thread *td) levents =3D events & (POLLIN | POLLINIGNEOF | POLLPRI | POLLRDNORM | POLLRDBAND); if ((fp->f_flag & FREAD) && levents) { - /* - * If POLLIN or POLLRDNORM is requested and POLLINIGNEOF is - * not, then convert the first two to the last one. This - * tells the socket poll function to ignore EOF so that we - * block if there is no writer (and no data). Callers can - * set POLLINIGNEOF to get non-blocking behavior. - */ - if (levents & (POLLIN | POLLRDNORM) && - !(levents & POLLINIGNEOF)) { - levents &=3D ~(POLLIN | POLLRDNORM); - levents |=3D POLLINIGNEOF; - } - filetmp.f_data =3D fip->fi_readsock; filetmp.f_cred =3D cred; - revents |=3D soo_poll(&filetmp, levents, cred, td); - - /* Reverse the above conversion. */ - if ((revents & POLLINIGNEOF) && !(events & POLLINIGNEOF)) { - revents |=3D (events & (POLLIN | POLLRDNORM)); - revents &=3D ~POLLINIGNEOF; - } + revents |=3D soo_poll(&filetmp, levents | (events & POLLPOLL), + cred, td); } levents =3D events & (POLLOUT | POLLWRNORM | POLLWRBAND); if ((fp->f_flag & FWRITE) && levents) { diff --git a/sys/kern/sys_generic.c b/sys/kern/sys_generic.c index 616c5b7..98ccc9e 100644 --- a/sys/kern/sys_generic.c +++ b/sys/kern/sys_generic.c @@ -1226,8 +1226,8 @@ pollscan(td, fds, nfd) * POLLERR if appropriate. */ selfdalloc(td, fds); - fds->revents =3D fo_poll(fp, fds->events, - td->td_ucred, td); + fds->revents =3D fo_poll(fp, + fds->events | POLLPOLL, td->td_ucred, td); if (fds->revents !=3D 0) n++; } diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c index 7341d3f..a13d648 100644 --- a/sys/kern/uipc_socket.c +++ b/sys/kern/uipc_socket.c @@ -2706,6 +2706,42 @@ sopoll_generic(struct socket *so, int events, struct= ucred *active_cred, if (sowriteable(so)) revents |=3D events & (POLLOUT | POLLWRNORM); =20 + /* + * SBS_CANTRCVMORE (which is checked by soreadable()) normally + * implies EOF (and thus readable) and hung up, but for + * compatibility with other systems and to obtain behavior that + * is otherwise unavailable we make the case of poll() on a fifo + * that has never had any writers during the lifetime of any + * current reader special: then we pretend that the fifo is + * unreadable unless it contains non-null data, and that it is + * not hung up. The POLLPOLL flag is set by poll() to identify + * poll() here, and the SBS_COULDRCV flag is set by the fifo + * layer to indicate a fifo that is not in the special state. + */ + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { + if (!(events & POLLPOLL) || so->so_rcv.sb_state & SBS_COULDRCV) + revents |=3D POLLHUP; /* finish settings */ + else if (!(so->so_rcv.sb_cc >=3D so->so_rcv.sb_lowat || + !TAILQ_EMPTY(&so->so_comp) || so->so_error)) + revents &=3D ~(POLLIN | POLLRDNORM); /* undo settings */ + } + + /* + * Testing of hangup for writers could be optimized by combining + * it with testing for writeability, but we keep the test separate + * and with the same organization as the test for readers for + * clarity. Note that writeable implies not hung up, so if POLLHUP + * is set here then (POLLOUT | POLLWRNORM) is not set above, as + * standards require. Less obviously, if POLLHUP was set above for + * a reader, then the output flags cannot have been set above for + * a writer. Even less obviously, we cannot end up with both + * POLLHUP output flags set in revents after ORing the revents for + * the read and write socket in fifo_poll(). + */ + if (so->so_snd.sb_state & SBS_CANTSENDMORE) + revents |=3D POLLHUP; + + if (events & (POLLPRI | POLLRDBAND)) if (so->so_oobmark || (so->so_rcv.sb_state & SBS_RCVATMARK)) revents |=3D events & (POLLPRI | POLLRDBAND); diff --git a/sys/sys/poll.h b/sys/sys/poll.h index c955f32..cfd5f01 100644 --- a/sys/sys/poll.h +++ b/sys/sys/poll.h @@ -71,6 +71,10 @@ struct pollfd { #define POLLINIGNEOF 0x2000 /* like POLLIN, except ignore EOF */ #endif =20 +#ifdef _KERNEL +#define POLLPOLL 0x8000 /* system call is actually poll() */ +#endif + /* * These events are set if they occur regardless of whether they were * requested. diff --git a/sys/sys/sockbuf.h b/sys/sys/sockbuf.h index b8e6699..0da4fa1 100644 --- a/sys/sys/sockbuf.h +++ b/sys/sys/sockbuf.h @@ -56,6 +56,7 @@ #define SBS_CANTSENDMORE 0x0010 /* can't send more data to peer */ #define SBS_CANTRCVMORE 0x0020 /* can't receive more data from peer */ #define SBS_RCVATMARK 0x0040 /* at mark on input */ +#define SBS_COULDRCV 0x0080 /* could receive previously (or now) */ =20 struct mbuf; struct sockaddr; --1UNnSMTKiCAppeLf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkomkZ0ACgkQC3+MBN1Mb4gr2gCdGq4WE9des8oKJ7Ha1JNLfWsV elMAoM5Kwu6d2xeufKLw8uPAp81MGOR3 =w4Un -----END PGP SIGNATURE----- --1UNnSMTKiCAppeLf-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 16:36:55 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACD1F106564A; Wed, 3 Jun 2009 16:36:55 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.bestunion.it (mail.bestunion.it [85.18.201.87]) by mx1.freebsd.org (Postfix) with ESMTP id 387648FC0A; Wed, 3 Jun 2009 16:36:54 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from [192.168.33.30] (nbcommit.home.commit.it [192.168.33.30] (may be forged)) (authenticated bits=0) by mail.bestunion.it (8.14.3/8.14.3) with ESMTP id n53GIEg3056886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 18:18:15 +0200 (CEST) (envelope-from aturetta@commit.it) Message-ID: <4A26A239.5050608@commit.it> Date: Wed, 03 Jun 2009 18:18:01 +0200 From: Angelo Turetta User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Doug Barton References: <4A257B82.1000701@FreeBSD.org> In-Reply-To: <4A257B82.1000701@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at mail.bestunion.it X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 16:36:56 -0000 Doug Barton wrote: > If you use a value of network_interfaces other than AUTO please speak > up so that we can make an intelligent decision about this issue. Maybe I am wrong, setting network_interfaces is the way I found I had to use to be able to rename cloned interfaces. eg: network_interfaces="lo0 em0 dmz" ifconfig_em0="up" cloned_interfaces="vlan0" ifconfig_vlan0_name="dmz" ifconfig_dmz="192.168.34.129/24 vlan 2 vlandev em0" I seem to remember I had to put that 'dmz' in network_interfaces, to make everything happy at boot. I can do more tests if needed. Ciao, Angelo. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 20:05:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5398C10656D7; Wed, 3 Jun 2009 20:05:09 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B5EA48FC1B; Wed, 3 Jun 2009 20:05:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n53K50Cm079776; Wed, 3 Jun 2009 15:05:00 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n53K4x93079775; Wed, 3 Jun 2009 15:04:59 -0500 (CDT) (envelope-from brooks) Date: Wed, 3 Jun 2009 15:04:59 -0500 From: Brooks Davis To: Angelo Turetta Message-ID: <20090603200459.GG28486@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <4A26A239.5050608@commit.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gvF4niNJ+uBMJnEh" Content-Disposition: inline In-Reply-To: <4A26A239.5050608@commit.it> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 03 Jun 2009 15:05:00 -0500 (CDT) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 20:05:10 -0000 --gvF4niNJ+uBMJnEh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 06:18:01PM +0200, Angelo Turetta wrote: > Doug Barton wrote: >> If you use a value of network_interfaces other than AUTO please speak >> up so that we can make an intelligent decision about this issue. >=20 > Maybe I am wrong, setting network_interfaces is the way I found I had to= =20 > use to be able to rename cloned interfaces. >=20 > eg: >=20 > network_interfaces=3D"lo0 em0 dmz" > ifconfig_em0=3D"up" > cloned_interfaces=3D"vlan0" >=20 > ifconfig_vlan0_name=3D"dmz" > ifconfig_dmz=3D"192.168.34.129/24 vlan 2 vlandev em0" >=20 > I seem to remember I had to put that 'dmz' in network_interfaces, to make= =20 > everything happy at boot. I can do more tests if needed. Hmm, there might be a bug related to cloned interfaces and renaming. That should be easy to fix. -- Brooks --gvF4niNJ+uBMJnEh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJtdrXY6L6fI4GtQRAg2OAJ9Vm/SWtVbWsvK9T00xfd1+8WrmAACglhIi rcFHXO28RxL5F1XHew+EPxw= =R/2Z -----END PGP SIGNATURE----- --gvF4niNJ+uBMJnEh-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 20:37:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBC21065687; Wed, 3 Jun 2009 20:37:37 +0000 (UTC) (envelope-from erik@barragry.com) Received: from cork.barragry.com (cork.barragry.com [72.232.202.93]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1EF8FC12; Wed, 3 Jun 2009 20:37:36 +0000 (UTC) (envelope-from erik@barragry.com) Received: by cork.barragry.com (Postfix, from userid 1006) id BC33C1D8012; Wed, 3 Jun 2009 15:37:36 -0500 (CDT) Date: Wed, 3 Jun 2009 15:37:36 -0500 From: Erik Osterholm To: Brooks Davis Message-ID: <20090603203736.GA23840@barragry.com> References: <4A257B82.1000701@FreeBSD.org> <20090602230648.GB88740@barragry.com> <20090603141321.GC28486@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090603141321.GC28486@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 20:37:37 -0000 On Wed, Jun 03, 2009 at 09:13:21AM -0500, Brooks Davis wrote: > On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > > Up till Sunday in 8-current, and for a long time in general > > > network.subr (part of the rc.d system) has emitted a warning > > > that values of network_interfaces other than AUTO are > > > deprecated. I removed that warning in HEAD Sunday, and there is > > > no a discussion about whether or not it should be put back, and > > > whether or not there is any need for the user to specify the > > > list of network interfaces at all. > > > > > > If you use a value of network_interfaces other than AUTO please > > > speak up so that we can make an intelligent decision about this > > > issue. > > > > > > Thanks, > > > > > > Doug > > > > I'll have to preface this by disclosing that I have not been > > running -current, nor following any changes to the RC system. > > > > In 7.1, if you compile a custom kernel and comment out an > > interface (such that it is compiled as a module), one way to > > ensure that the module is loaded is to explicitly list it in > > network_interfaces. If -current works the same way, then users > > will be required to modify /boot/loader.conf in order to load the > > module. Could there could be possible side-effects to this > > change, since the loading of the module happens at a different > > time? > > Do you actually do this? We do use modules for a number of machines instead of leaving the NIC driver compiled into the kernel. I think that the impetus for doing this involved a driver bug back in 6.1 which crashed the machine if it passed too much traffic. The thinking was that for future bugs, it would be easier and faster to ship off the kernel module, unload the old one, load the new one, and reconfigure the interface than to ship over a whole new kernel and reboot. We also used to have a couple of machines for which the vendor supplied NIC kernel modules, but I don't think that they're in use anymore. And yes, the machines use network_interfaces to load the modules, though I'm not arrogant enough to assume that this is the best way. Maybe it is worth considering changing ifconfig_$DRIVER to load the driver? Erik From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 20:42:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D0F61065670; Wed, 3 Jun 2009 20:42:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 280E38FC0A; Wed, 3 Jun 2009 20:42:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n53Ignb1006729; Thu, 4 Jun 2009 04:42:49 +1000 Received: from besplex.bde.org (c122-106-151-9.carlnfd1.nsw.optusnet.com.au [122.106.151.9]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n53IgeGB031774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2009 04:42:40 +1000 Date: Thu, 4 Jun 2009 04:42:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20090603150710.GN1927@deviant.kiev.zoral.com.ua> Message-ID: <20090604030724.V1181@besplex.bde.org> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> <20090603143051.GM1927@deviant.kiev.zoral.com.ua> <20090603150710.GN1927@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Vlad Galu , freebsd-stable@freebsd.org, Oliver Fromme , bde@freebsd.org Subject: Re: poll()-ing a pipe descriptor, watching for POLLHUP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 20:42:33 -0000 On Wed, 3 Jun 2009, Kostik Belousov wrote: > On Wed, Jun 03, 2009 at 05:30:51PM +0300, Kostik Belousov wrote: >> On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote: >>> Hm, I was having an issue with an internal piece of software, but >>> never checked what kind of pipe caused the problem. Turns out it was a >>> FIFO, and I got bitten by the same bug described here: >>> http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html >>> >>> The problem is that the reader process isn't notified when the writer G>>> process exits or closes the FIFO fd... >> >> So you did found the relevant PR with long audit trail and patches >> attached. You obviously should contact the author of the patches, >> Oliver Fromme, who is FreeBSD committer for some time (CCed). >> >> I agree that the thing shall be fixed finally. Skimming over the >> patches in kern/94772, I have some doubts about removal of >> POLLINIGNEOF flag. The reason is that we are generally do not >> remove exposed user interfaces. Maybe, but this flag was not a documented interface, and too much ugliness might be required to preserve its behaviour bug-for-bug compatibly (the old buggy behaviour would probably be more wanted for compatibility than the strange behaviour given by this flag! > I forward-ported Bruce' patch to the CURRENT. It passes the tests > from tools/regression/fifo and a test from kern/94772. Thanks. I won't be committing it any time soon, so you should. I rewrote the test programs extensively (enclosed at the end) in Oct 2007 and updated the kernel patches to match. Please run the new tests to see if you are missing anything important in the kernel part. If so, I will search for the kernel patches later (actually, now -- enclosed in the middle). I just ran them under RELENG_7 and unpatched -current and found no differences with the Oct 2007 version for RELENG_7 in the old test output. The old test output is in the following subdirectories: 4: FreeBSD-4 7: FreeBSD-7 l: Linux-2.6.10 m: my version of FreeBSD-5.2 including patches for this problem. AFAIR, the FreeBSD output in "m" is the same as the Linux output in all except a couple of cases where Linux select is inconsistent with itself and/or with Linux poll. However, the differences in the saved output are that the Linux output is mysteriously missing results for tests 5-8. The tests attempt to test certain race possibilities in a non-racy way. This is not easy and the differences might be due to some races/states not occurring under Linux. POSIX finally specified the behaviour strictly enough for it to be possible to test it a couple of years ago. I didn't follow all the developments and forget the details, but it was close to the Linux behaviour. > For my liking, I did not removed POLLINIGNEOF. > > diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c > index 66963bc..7e279ca 100644 > --- a/sys/fs/fifofs/fifo_vnops.c > +++ b/sys/fs/fifofs/fifo_vnops.c > @@ -226,11 +226,47 @@ fail1: > if (ap->a_mode & FREAD) { > fip->fi_readers++; > if (fip->fi_readers == 1) { > + SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); > + if (fip->fi_writers > 0) > + fip->fi_readsock->so_rcv.sb_state |= > + SBS_COULDRCV; My current version is in fact completely different. It doesn't have SBS_COULDRCV, but uses a generation count. IIRC, this is the same method as is used in Linux, and is needed for the same reasons (something to do with keeping new "connections" separate from old ones). So I will try to enclose the components of the patch in the order of your diff (might miss some). First one: % Index: fifo_vnops.c % =================================================================== % RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v % retrieving revision 1.100 % diff -u -2 -r1.100 fifo_vnops.c % --- fifo_vnops.c 23 Jun 2004 00:35:50 -0000 1.100 % +++ fifo_vnops.c 17 Oct 2007 11:36:23 -0000 % @@ -36,4 +36,5 @@ % #include % #include % +#include % #include % #include % @@ -61,4 +62,5 @@ % long fi_readers; % long fi_writers; % + int fi_wgen; % }; % % @@ -182,8 +184,11 @@ % struct ucred *a_cred; % struct thread *a_td; % + int a_fdidx; % } */ *ap; % { % struct vnode *vp = ap->a_vp; % struct fifoinfo *fip; % + struct file *fp; % + struct filedesc *fdp; % struct thread *td = ap->a_td; % struct ucred *cred = ap->a_cred; % @@ -240,4 +245,10 @@ % } % } % + fdp = td->td_proc->p_fd; % + FILEDESC_LOCK(fdp); % + fp = fget_locked(fdp, ap->a_fdidx); % + /* Abuse f_msgcount as a generation count. */ % + fp->f_msgcount = fip->fi_wgen - fip->fi_writers; % + FILEDESC_UNLOCK(fdp); % } % if (ap->a_mode & FWRITE) { % @@ -248,10 +259,10 @@ % fip->fi_writers++; % if (fip->fi_writers == 1) { % - SOCKBUF_LOCK(&fip->fi_writesock->so_rcv); % + SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); % fip->fi_readsock->so_rcv.sb_state &= ~SBS_CANTRCVMORE; % - SOCKBUF_UNLOCK(&fip->fi_writesock->so_rcv); % + SOCKBUF_UNLOCK(&fip->fi_readsock->so_rcv); % if (fip->fi_readers > 0) { % wakeup(&fip->fi_readers); % - sorwakeup(fip->fi_writesock); % + sorwakeup(fip->fi_readsock); % } % } % @@ -588,6 +599,8 @@ % if (ap->a_fflag & FWRITE) { % fip->fi_writers--; % - if (fip->fi_writers == 0) % + if (fip->fi_writers == 0) { % socantrcvmore(fip->fi_readsock); % + fip->fi_wgen++; % + } % } % fifo_cleanup(vp); % @@ -669,2 +682,28 @@ % return (ap->a_flags & F_FLOCK ? EOPNOTSUPP : EINVAL); % } % + % +fo_poll_t fifo_poll_f; % +int % +fifo_poll_f(struct file *fp, int events, struct ucred *cred, struct thread *td) % +{ % + struct file filetmp; % + struct fifoinfo *fip; % + int levents, revents = 0; % + % + fip = fp->f_vnode->v_fifoinfo; % + levents = events & (POLLIN | POLLPRI | POLLRDNORM | POLLRDBAND); % + if (levents) { % + filetmp.f_data = fip->fi_readsock; % + filetmp.f_cred = fp->f_cred; % + if (fp->f_msgcount == fip->fi_wgen) % + levents |= POLLINIGNEOF; % + revents |= soo_poll(&filetmp, levents, cred, td); % + } % + levents = events & (POLLOUT | POLLWRNORM | POLLWRBAND); % + if (levents) { % + filetmp.f_data = fip->fi_writesock; % + filetmp.f_cred = fp->f_cred; % + revents |= soo_poll(&filetmp, levents, cred, td); % + } + return (revents); +} Large parts of this (the existence of fifo_poll_f()...) are already in -current -- I copied them from -current to fix a critical bug. The above version of fifo_poll_f() is essentially much simpler. It still uses POLLINIGNEOF but sets it better using the generation counts. I don't remember why f_msgcount is abused as a generation count instead of adding a second generation count; probably it needs to go in `struct file' and I didn't want to edit file.h and/or bloat `struct file'. > diff --git a/sys/kern/sys_generic.c b/sys/kern/sys_generic.c > index 616c5b7..98ccc9e 100644 > --- a/sys/kern/sys_generic.c > +++ b/sys/kern/sys_generic.c > @@ -1226,8 +1226,8 @@ pollscan(td, fds, nfd) > * POLLERR if appropriate. > */ > selfdalloc(td, fds); > - fds->revents = fo_poll(fp, fds->events, > - td->td_ucred, td); > + fds->revents = fo_poll(fp, > + fds->events | POLLPOLL, td->td_ucred, td); > if (fds->revents != 0) > n++; > } I now seem to have only style fixes in pollscan() and selscan(). I don't need POLLPOLL. IIRC, the more intelligent/state-dependent setting of POLLINIGNEOF handles this for fifos, while different treatments work better for nameless pipes and sockets. The following is for nameless pipes: % Index: sys_pipe.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v % retrieving revision 1.171 % diff -u -2 -r1.171 sys_pipe.c % --- sys_pipe.c 27 Mar 2004 19:50:22 -0000 1.171 % +++ sys_pipe.c 16 Oct 2007 07:18:55 -0000 % @@ -1296,6 +1295,5 @@ % if (events & (POLLIN | POLLRDNORM)) % if ((rpipe->pipe_state & PIPE_DIRECTW) || % - (rpipe->pipe_buffer.cnt > 0) || % - (rpipe->pipe_state & PIPE_EOF)) % + (rpipe->pipe_buffer.cnt > 0)) % revents |= events & (POLLIN | POLLRDNORM); % POLLHUP will be set a little later if PIPE_EOF, and it is at best confusing for PIPE_EOF to imply POLLIN and POLLRDNORM (especially, "normal input"). I now vaguely remember that the differences with Linux are in this area. IIRC, the above makes nameless pipes behave like fifos in Linux (and now in FreeBSD), while nameless pipes behave differently from fifos in Linux. The tests assert that POLLIN and POLLHUP are set when there is EOF and (previously buffered) data to read, and that POLLIN becomes clear on reading the data. This is also be related to the longstanding bug in gdb -- "echo 'print 0' | gdb" exits before reading any input because it sees POLLIN | POLLHUP and thinks that POLLHUP implies no more input. poll() is hard to use unless it clears POLLIN once the input is read, and gdb-6.1 still doesn't understand how to use poll() whether or not poll() does the wrong thing here. gdb used to work OK using select(): With select(), there is nothing like POLLHUP and select() returns the equivalent of POLLIN for EOF with no data; then the reader must try a read() and hope that a read() of 0 means EOF. With broken poll(), readers must try a read similarly since they can't trust POLLIN if POLLHUP is also set. With non-broken poll(), they can trust POLLIN and not quit until poll() returns only POLLHUP. The tests describe this with different details. > diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c > index 7341d3f..a13d648 100644 > --- a/sys/kern/uipc_socket.c > +++ b/sys/kern/uipc_socket.c > @@ -2706,6 +2706,42 @@ sopoll_generic(struct socket *so, int events, struct ucred *active_cred, > if (sowriteable(so)) > revents |= events & (POLLOUT | POLLWRNORM); > > + /* > + * SBS_CANTRCVMORE (which is checked by soreadable()) normally > + * implies EOF (and thus readable) and hung up, but for > + * compatibility with other systems and to obtain behavior that > + * is otherwise unavailable we make the case of poll() on a fifo > + * that has never had any writers during the lifetime of any > + * current reader special: then we pretend that the fifo is > + * unreadable unless it contains non-null data, and that it is > + * not hung up. The POLLPOLL flag is set by poll() to identify > + * poll() here, and the SBS_COULDRCV flag is set by the fifo > + * layer to indicate a fifo that is not in the special state. > + */ > + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { > + if (!(events & POLLPOLL) || so->so_rcv.sb_state & SBS_COULDRCV) > + revents |= POLLHUP; /* finish settings */ > + else if (!(so->so_rcv.sb_cc >= so->so_rcv.sb_lowat || > + !TAILQ_EMPTY(&so->so_comp) || so->so_error)) > + revents &= ~(POLLIN | POLLRDNORM); /* undo settings */ > + } > + > + /* > + * Testing of hangup for writers could be optimized by combining > + * it with testing for writeability, but we keep the test separate > + * and with the same organization as the test for readers for > + * clarity. Note that writeable implies not hung up, so if POLLHUP > + * is set here then (POLLOUT | POLLWRNORM) is not set above, as > + * standards require. Less obviously, if POLLHUP was set above for > + * a reader, then the output flags cannot have been set above for > + * a writer. Even less obviously, we cannot end up with both > + * POLLHUP output flags set in revents after ORing the revents for > + * the read and write socket in fifo_poll(). > + */ > + if (so->so_snd.sb_state & SBS_CANTSENDMORE) > + revents |= POLLHUP; > + > + > if (events & (POLLPRI | POLLRDBAND)) > if (so->so_oobmark || (so->so_rcv.sb_state & SBS_RCVATMARK)) > revents |= events & (POLLPRI | POLLRDBAND); My version is only subtly different from the above (except it doesn't add any comments -- not sure why). It uses a soreadable1() macro instead of getting tangled up trying to use soreadable(): % Index: uipc_socket.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v % retrieving revision 1.189 % diff -u -2 -r1.189 uipc_socket.c % --- uipc_socket.c 24 Jun 2004 04:28:30 -0000 1.189 % +++ uipc_socket.c 17 Oct 2007 10:44:50 -0000 % @@ -1862,4 +1860,8 @@ % } % % +#define soreadable1(so) \ % + ((so)->so_rcv.sb_cc >= (so)->so_rcv.sb_lowat || \ % + !TAILQ_EMPTY(&(so)->so_comp) || (so)->so_error) % + % int % sopoll(struct socket *so, int events, struct ucred *active_cred, % @@ -1869,12 +1871,7 @@ % % if (events & (POLLIN | POLLRDNORM)) % - if (soreadable(so)) % + if (soreadable1(so)) % revents |= events & (POLLIN | POLLRDNORM); % % - if (events & POLLINIGNEOF) % - if (so->so_rcv.sb_cc >= so->so_rcv.sb_lowat || % - !TAILQ_EMPTY(&so->so_comp) || so->so_error) % - revents |= POLLINIGNEOF; % - % if (events & (POLLOUT | POLLWRNORM)) % if (sowriteable(so)) % @@ -1885,8 +1882,12 @@ % revents |= events & (POLLPRI | POLLRDBAND); % % + if ((events & POLLINIGNEOF) == 0) % + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) % + revents |= POLLHUP; % + if (so->so_rcv.sb_state & SBS_CANTSENDMORE) % + revents |= POLLHUP; % + % if (revents == 0) { % - if (events & % - (POLLIN | POLLINIGNEOF | POLLPRI | POLLRDNORM | % - POLLRDBAND)) { % + if (events & (POLLIN | POLLPRI | POLLRDNORM | POLLRDBAND)) { % SOCKBUF_LOCK(&so->so_rcv); % selrecord(td, &so->so_rcv.sb_sel); > diff --git a/sys/sys/poll.h b/sys/sys/poll.h > index c955f32..cfd5f01 100644 > --- a/sys/sys/poll.h > +++ b/sys/sys/poll.h > @@ -71,6 +71,10 @@ struct pollfd { > #define POLLINIGNEOF 0x2000 /* like POLLIN, except ignore EOF */ > #endif > > +#ifdef _KERNEL > +#define POLLPOLL 0x8000 /* system call is actually poll() */ > +#endif > + > /* > * These events are set if they occur regardless of whether they were > * requested. I don't have any changes here (still have POLLINIGNEOF). > diff --git a/sys/sys/sockbuf.h b/sys/sys/sockbuf.h > index b8e6699..0da4fa1 100644 > --- a/sys/sys/sockbuf.h > +++ b/sys/sys/sockbuf.h > @@ -56,6 +56,7 @@ > #define SBS_CANTSENDMORE 0x0010 /* can't send more data to peer */ > #define SBS_CANTRCVMORE 0x0020 /* can't receive more data from peer */ > #define SBS_RCVATMARK 0x0040 /* at mark on input */ > +#define SBS_COULDRCV 0x0080 /* could receive previously (or now) */ > > struct mbuf; > struct sockaddr; > I still had this patch, but no references to SBS_COULDRCV. Now I don't have it :-). Now for the test programs: #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh './4/pipeselect.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected clear; got clear Xok 2 Pipe state 5: expected set; got set Xok 3 Pipe state 6: expected set; got set Xok 4 Pipe state 6a: expected set; got set Xok 5 Sock state 4: expected clear; got clear Xok 6 Sock state 5: expected set; got set Xok 7 Sock state 6: expected set; got set Xok 8 Sock state 6a: expected set; got set Xnot ok 9 FIFO state 0: expected clear; got set Xok 10 FIFO state 1: expected clear; got clear Xok 11 FIFO state 2: expected set; got set Xok 12 FIFO state 2a: expected clear; got clear Xok 13 FIFO state 3: expected set; got set Xok 14 FIFO state 4: expected clear; got clear Xok 15 FIFO state 5: expected set; got set Xok 16 FIFO state 6: expected set; got set Xok 17 FIFO state 6a: expected set; got set Xnot ok 18 FIFO state 6b: expected clear; got set Xok 19 FIFO state 6c: expected set; got set Xok 20 FIFO state 6d: expected set; got set END_OF_FILE if test 957 -ne `wc -c <'./4/pipeselect.out'`; then echo shar: \"'./4/pipeselect.out'\" unpacked with wrong size! fi # end of './4/pipeselect.out' fi if test -f './4/pipepoll.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./4/pipepoll.out'\" else echo shar: Extracting \"'./4/pipepoll.out'\" \(1049 characters\) sed "s/^X//" >'./4/pipepoll.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected 0; got 0 Xok 2 Pipe state 5: expected POLLIN; got POLLIN Xok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xnot ok 4 Pipe state 6a: expected POLLHUP; got POLLIN | POLLHUP Xok 5 Sock state 4: expected 0; got 0 Xok 6 Sock state 5: expected POLLIN; got POLLIN Xnot ok 7 Sock state 6: expected POLLIN | POLLHUP; got POLLIN Xnot ok 8 Sock state 6a: expected POLLHUP; got POLLIN Xnot ok 9 FIFO state 0: expected 0; got POLLIN Xok 10 FIFO state 1: expected 0; got 0 Xok 11 FIFO state 2: expected POLLIN; got POLLIN Xok 12 FIFO state 2a: expected 0; got 0 Xnot ok 13 FIFO state 3: expected POLLHUP; got POLLIN Xok 14 FIFO state 4: expected 0; got 0 Xok 15 FIFO state 5: expected POLLIN; got POLLIN Xnot ok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN Xnot ok 17 FIFO state 6a: expected POLLHUP; got POLLIN Xnot ok 18 FIFO state 6b: expected 0; got POLLIN Xnot ok 19 FIFO state 6c: expected POLLHUP; got POLLIN Xnot ok 20 FIFO state 6d: expected POLLHUP; got POLLIN END_OF_FILE if test 1049 -ne `wc -c <'./4/pipepoll.out'`; then echo shar: \"'./4/pipepoll.out'\" unpacked with wrong size! fi # end of './4/pipepoll.out' fi if test -f './pipepoll.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./pipepoll.c'\" else echo shar: Extracting \"'./pipepoll.c'\" \(5929 characters\) sed "s/^X//" >'./pipepoll.c' <<'END_OF_FILE' X#include X#include X#include X X#include X#include X#include X#include X#include X#include X X#define FIFONAME "fifo.tmp" X#define FT_END 3 X#define FT_FIFO 2 X#define FT_PIPE 0 X#define FT_SOCKETPAIR 1 X Xstatic int filetype; X Xstatic const char * Xdecode_events(int events) X{ X char *ncresult; X const char *result; X X switch (events) { X case POLLIN: X result = "POLLIN"; X break; X case POLLHUP: X result = "POLLHUP"; X break; X case POLLIN | POLLHUP: X result = "POLLIN | POLLHUP"; X break; X default: X asprintf(&ncresult, "%#x", events); X result = ncresult; X break; X } X return (result); X} X Xstatic void Xreport(int num, const char *state, int expected, int got) X{ X if (expected == got) X printf("ok %-2d ", num); X else X printf("not ok %-2d", num); X printf(" %s state %s: expected %s; got %s\n", X filetype == FT_PIPE ? "Pipe" : X filetype == FT_SOCKETPAIR ? "Sock" : "FIFO", X state, decode_events(expected), decode_events(got)); X fflush(stdout); X} X Xstatic pid_t cpid; Xstatic pid_t ppid; Xstatic volatile sig_atomic_t state; X Xstatic void Xcatch(int sig) X{ X state++; X} X Xstatic void Xchild(int fd, int num) X{ X struct pollfd pfd; X int fd2; X char buf[256]; X X if (filetype == FT_FIFO) { X fd = open(FIFONAME, O_RDONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for read"); X } X pfd.fd = fd; X pfd.events = POLLIN; X X if (filetype == FT_FIFO) { X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "0", 0, pfd.revents); X } X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 1) X ; X if (filetype != FT_FIFO) { X /* X * The connection cannot be restablished. Use the code that X * delays the read until after the writer disconnects since X * that case is more interesting. X */ X state = 4; X goto state4; X } X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "1", 0, pfd.revents); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 2) X ; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "2", POLLIN, pfd.revents); X if (read(fd, buf, sizeof buf) != 1) X err(1, "read"); X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "2a", 0, pfd.revents); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 3) X ; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "3", POLLHUP, pfd.revents); X kill(ppid, SIGUSR1); X X /* X * Now we expect a new writer, and a new connection too since X * we read all the data. The only new point is that we didn't X * start quite from scratch since the read fd is not new. Check X * startup state as above, but don't do the read as above. X */ X usleep(1); X while (state != 4) X ; Xstate4: X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "4", 0, pfd.revents); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 5) X ; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "5", POLLIN, pfd.revents); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 6) X ; X /* X * Now we have no writer, but should still have data from the old X * writer. Check that we have both a data condition and a hangup X * condition, and that the data can read the data in the usual way. X * Since Linux does this, programs must not quit reading when they X * see POLLHUP; they must see POLLHUP without POLLIN (or another X * input condition) before they decide that there is EOF. gdb-6.1.1 X * is an example of a broken program that quits on POLLHUP only -- X * see its event-loop.c. X */ X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6", POLLIN | POLLHUP, pfd.revents); X if (read(fd, buf, sizeof buf) != 1) X err(1, "read"); X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6a", POLLHUP, pfd.revents); X if (filetype == FT_FIFO) { X /* X * Check that POLLHUP is not seen by new readers but is X * still seen by old readers. X */ X fd2 = open(FIFONAME, O_RDONLY | O_NONBLOCK); X if (fd2 < 0) X err(1, "open for read"); X pfd.fd = fd2; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6b", 0, pfd.revents); X pfd.fd = fd; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6c", POLLHUP, pfd.revents); X close(fd2); X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6d", POLLHUP, pfd.revents); X } X close(fd); X kill(ppid, SIGUSR1); X X exit(0); X} X Xstatic void Xparent(int fd) X{ X usleep(1); X while (state != 1) X ; X if (filetype == FT_FIFO) { X fd = open(FIFONAME, O_WRONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for write"); X } X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 2) X ; X if (write(fd, "", 1) != 1) X err(1, "write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 3) X ; X if (close(fd) != 0) X err(1, "close for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 4) X ; X if (filetype != FT_FIFO) X return; X fd = open(FIFONAME, O_WRONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 5) X ; X if (write(fd, "", 1) != 1) X err(1, "write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 6) X ; X if (close(fd) != 0) X err(1, "close for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 7) X ; X} X Xint Xmain(void) X{ X int fd[2], num; X X num = 1; X printf("1..20\n"); X fflush(stdout); X signal(SIGUSR1, catch); X ppid = getpid(); X for (filetype = 0; filetype < FT_END; filetype++) { X switch (filetype) { X case FT_FIFO: X if (mkfifo(FIFONAME, 0666) != 0) X err(1, "mkfifo"); X fd[0] = -1; X fd[1] = -1; X break; X case FT_SOCKETPAIR: X if (socketpair(AF_UNIX, SOCK_STREAM, AF_UNSPEC, X fd) != 0) X err(1, "socketpair"); X break; X case FT_PIPE: X if (pipe(fd) != 0) X err(1, "pipe"); X break; X } X state = 0; X switch (cpid = fork()) { X case -1: X err(1, "fork"); X case 0: X (void)close(fd[1]); X child(fd[0], num); X break; X default: X (void)close(fd[0]); X parent(fd[1]); X break; X } X num += filetype == FT_FIFO ? 12 : 4; X } X (void)unlink(FIFONAME); X return (0); X} END_OF_FILE if test 5929 -ne `wc -c <'./pipepoll.c'`; then echo shar: \"'./pipepoll.c'\" unpacked with wrong size! fi # end of './pipepoll.c' fi if test -f './pipeselect.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./pipeselect.c'\" else echo shar: Extracting \"'./pipeselect.c'\" \(6476 characters\) sed "s/^X//" >'./pipeselect.c' <<'END_OF_FILE' X#include X#include X#include X X#include X#include X#include X#include X#include X#include X X#define FIFONAME "fifo.tmp" X#define FT_END 3 X#define FT_FIFO 2 X#define FT_PIPE 0 X#define FT_SOCKETPAIR 1 X X#define SETUP(fd, rfds, tv) do { \ X FD_ZERO(&(rfds)); \ X FD_SET((fd), &(rfds)); \ X (tv).tv_sec = 0; \ X (tv).tv_usec = 0; \ X} while (0) X Xstatic int filetype; X Xstatic const char * Xdecode_events(int events) X{ X return (events ? "set" : "clear"); X} X Xstatic void Xreport(int num, const char *state, int expected, int got) X{ X if (!expected == !got) X printf("ok %-2d ", num); X else X printf("not ok %-2d", num); X printf(" %s state %s: expected %s; got %s\n", X filetype == FT_PIPE ? "Pipe" : X filetype == FT_SOCKETPAIR ? "Sock" : "FIFO", X state, decode_events(expected), decode_events(got)); X fflush(stdout); X} X Xstatic pid_t cpid; Xstatic pid_t ppid; Xstatic volatile sig_atomic_t state; X Xstatic void Xcatch(int sig) X{ X state++; X} X Xstatic void Xchild(int fd, int num) X{ X fd_set rfds; X struct timeval tv; X int fd1, fd2; X char buf[256]; X X if (filetype == FT_FIFO) { X fd = open(FIFONAME, O_RDONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for read"); X } X if (fd >= FD_SETSIZE) X errx(1, "fd = %d too large for select()", fd); X X if (filetype == FT_FIFO) { X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "0", 0, FD_ISSET(fd, &rfds)); X } X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 1) X ; X if (filetype != FT_FIFO) { X /* X * The connection cannot be restablished. Use the code that X * delays the read until after the writer disconnects since X * that case is more interesting. X */ X state = 4; X goto state4; X } X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "1", 0, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 2) X ; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "2", 1, FD_ISSET(fd, &rfds)); X if (read(fd, buf, sizeof buf) != 1) X err(1, "read"); X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "2a", 0, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 3) X ; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "3", 1, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X /* X * Now we expect a new writer, and a new connection too since X * we read all the data. The only new point is that we didn't X * start quite from scratch since the read fd is not new. Check X * startup state as above, but don't do the read as above. X */ X usleep(1); X while (state != 4) X ; Xstate4: X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "4", 0, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 5) X ; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "5", 1, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 6) X ; X /* X * Now we have no writer, but should still have data from the old X * writer. Check that we have both a data condition and a hangup X * condition, and that the data can read the data in the usual way. X * Since Linux does this, programs must not quit reading when they X * see POLLHUP; they must see POLLHUP without POLLIN (or another X * input condition) before they decide that there is EOF. gdb-6.1.1 X * is an example of a broken program that quits on POLLHUP only -- X * see its event-loop.c. X */ X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6", 1, FD_ISSET(fd, &rfds)); X if (read(fd, buf, sizeof buf) != 1) X err(1, "read"); X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6a", 1, FD_ISSET(fd, &rfds)); X if (filetype == FT_FIFO) { X /* X * Check that POLLHUP is not seen by new readers but is X * still seen by old readers. X */ X fd2 = open(FIFONAME, O_RDONLY | O_NONBLOCK); X if (fd2 < 0) X err(1, "open for read"); X fd1 = fd; X fd = fd2; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6b", 0, FD_ISSET(fd, &rfds)); X fd = fd1; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6c", 1, FD_ISSET(fd, &rfds)); X close(fd2); X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6d", 1, FD_ISSET(fd, &rfds)); X } X close(fd); X kill(ppid, SIGUSR1); X X exit(0); X} X Xstatic void Xparent(int fd) X{ X usleep(1); X while (state != 1) X ; X if (filetype == FT_FIFO) { X fd = open(FIFONAME, O_WRONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for write"); X } X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 2) X ; X if (write(fd, "", 1) != 1) X err(1, "write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 3) X ; X if (close(fd) != 0) X err(1, "close for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 4) X ; X if (filetype != FT_FIFO) X return; X fd = open(FIFONAME, O_WRONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 5) X ; X if (write(fd, "", 1) != 1) X err(1, "write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 6) X ; X if (close(fd) != 0) X err(1, "close for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 7) X ; X} X Xint Xmain(void) X{ X int fd[2], num; X X num = 1; X printf("1..20\n"); X fflush(stdout); X signal(SIGUSR1, catch); X ppid = getpid(); X for (filetype = 0; filetype < FT_END; filetype++) { X switch (filetype) { X case FT_FIFO: X if (mkfifo(FIFONAME, 0666) != 0) X err(1, "mkfifo"); X fd[0] = -1; X fd[1] = -1; X break; X case FT_SOCKETPAIR: X if (socketpair(AF_UNIX, SOCK_STREAM, AF_UNSPEC, X fd) != 0) X err(1, "socketpair"); X break; X case FT_PIPE: X if (pipe(fd) != 0) X err(1, "pipe"); X break; X } X state = 0; X switch (cpid = fork()) { X case -1: X err(1, "fork"); X case 0: X (void)close(fd[1]); X child(fd[0], num); X break; X default: X (void)close(fd[0]); X parent(fd[1]); X break; X } X num += filetype == FT_FIFO ? 12 : 4; X } X (void)unlink(FIFONAME); X return (0); X} END_OF_FILE if test 6476 -ne `wc -c <'./pipeselect.c'`; then echo shar: \"'./pipeselect.c'\" unpacked with wrong size! fi # end of './pipeselect.c' fi if test -f './m/pipeselect.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./m/pipeselect.out'\" else echo shar: Extracting \"'./m/pipeselect.out'\" \(961 characters\) sed "s/^X//" >'./m/pipeselect.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected clear; got clear Xok 2 Pipe state 5: expected set; got set Xok 3 Pipe state 6: expected set; got set Xok 4 Pipe state 6a: expected set; got set Xok 5 Sock state 4: expected clear; got clear Xok 6 Sock state 5: expected set; got set Xok 7 Sock state 6: expected set; got set Xok 8 Sock state 6a: expected set; got set Xok 9 FIFO state 0: expected clear; got clear Xok 10 FIFO state 1: expected clear; got clear Xok 11 FIFO state 2: expected set; got set Xok 12 FIFO state 2a: expected clear; got clear Xok 13 FIFO state 3: expected set; got set Xok 14 FIFO state 4: expected clear; got clear Xok 15 FIFO state 5: expected set; got set Xok 16 FIFO state 6: expected set; got set Xok 17 FIFO state 6a: expected set; got set Xok 18 FIFO state 6b: expected clear; got clear Xok 19 FIFO state 6c: expected set; got set Xok 20 FIFO state 6d: expected set; got set END_OF_FILE if test 961 -ne `wc -c <'./m/pipeselect.out'`; then echo shar: \"'./m/pipeselect.out'\" unpacked with wrong size! fi # end of './m/pipeselect.out' fi if test -f './m/pipepoll.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./m/pipepoll.out'\" else echo shar: Extracting \"'./m/pipepoll.out'\" \(1055 characters\) sed "s/^X//" >'./m/pipepoll.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected 0; got 0 Xok 2 Pipe state 5: expected POLLIN; got POLLIN Xok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 4 Pipe state 6a: expected POLLHUP; got POLLHUP Xok 5 Sock state 4: expected 0; got 0 Xok 6 Sock state 5: expected POLLIN; got POLLIN Xok 7 Sock state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 8 Sock state 6a: expected POLLHUP; got POLLHUP Xok 9 FIFO state 0: expected 0; got 0 Xok 10 FIFO state 1: expected 0; got 0 Xok 11 FIFO state 2: expected POLLIN; got POLLIN Xok 12 FIFO state 2a: expected 0; got 0 Xok 13 FIFO state 3: expected POLLHUP; got POLLHUP Xok 14 FIFO state 4: expected 0; got 0 Xok 15 FIFO state 5: expected POLLIN; got POLLIN Xok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 17 FIFO state 6a: expected POLLHUP; got POLLHUP Xok 18 FIFO state 6b: expected 0; got 0 Xok 19 FIFO state 6c: expected POLLHUP; got POLLHUP Xok 20 FIFO state 6d: expected POLLHUP; got POLLHUP END_OF_FILE if test 1055 -ne `wc -c <'./m/pipepoll.out'`; then echo shar: \"'./m/pipepoll.out'\" unpacked with wrong size! fi # end of './m/pipepoll.out' fi if test -f './7/pipeselect.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./7/pipeselect.out'\" else echo shar: Extracting \"'./7/pipeselect.out'\" \(969 characters\) sed "s/^X//" >'./7/pipeselect.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected clear; got clear Xok 2 Pipe state 5: expected set; got set Xok 3 Pipe state 6: expected set; got set Xok 4 Pipe state 6a: expected set; got set Xok 5 Sock state 4: expected clear; got clear Xok 6 Sock state 5: expected set; got set Xok 7 Sock state 6: expected set; got set Xok 8 Sock state 6a: expected set; got set Xok 9 FIFO state 0: expected clear; got clear Xok 10 FIFO state 1: expected clear; got clear Xok 11 FIFO state 2: expected set; got set Xok 12 FIFO state 2a: expected clear; got clear Xnot ok 13 FIFO state 3: expected set; got clear Xok 14 FIFO state 4: expected clear; got clear Xok 15 FIFO state 5: expected set; got set Xok 16 FIFO state 6: expected set; got set Xnot ok 17 FIFO state 6a: expected set; got clear Xok 18 FIFO state 6b: expected clear; got clear Xnot ok 19 FIFO state 6c: expected set; got clear Xnot ok 20 FIFO state 6d: expected set; got clear END_OF_FILE if test 969 -ne `wc -c <'./7/pipeselect.out'`; then echo shar: \"'./7/pipeselect.out'\" unpacked with wrong size! fi # end of './7/pipeselect.out' fi if test -f './7/pipepoll.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./7/pipepoll.out'\" else echo shar: Extracting \"'./7/pipepoll.out'\" \(1019 characters\) sed "s/^X//" >'./7/pipepoll.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected 0; got 0 Xok 2 Pipe state 5: expected POLLIN; got POLLIN Xok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xnot ok 4 Pipe state 6a: expected POLLHUP; got POLLIN | POLLHUP Xok 5 Sock state 4: expected 0; got 0 Xok 6 Sock state 5: expected POLLIN; got POLLIN Xnot ok 7 Sock state 6: expected POLLIN | POLLHUP; got POLLIN Xnot ok 8 Sock state 6a: expected POLLHUP; got POLLIN Xok 9 FIFO state 0: expected 0; got 0 Xok 10 FIFO state 1: expected 0; got 0 Xok 11 FIFO state 2: expected POLLIN; got POLLIN Xok 12 FIFO state 2a: expected 0; got 0 Xnot ok 13 FIFO state 3: expected POLLHUP; got 0 Xok 14 FIFO state 4: expected 0; got 0 Xok 15 FIFO state 5: expected POLLIN; got POLLIN Xnot ok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN Xnot ok 17 FIFO state 6a: expected POLLHUP; got 0 Xok 18 FIFO state 6b: expected 0; got 0 Xnot ok 19 FIFO state 6c: expected POLLHUP; got 0 Xnot ok 20 FIFO state 6d: expected POLLHUP; got 0 END_OF_FILE if test 1019 -ne `wc -c <'./7/pipepoll.out'`; then echo shar: \"'./7/pipepoll.out'\" unpacked with wrong size! fi # end of './7/pipepoll.out' fi if test -f './Makefile' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./Makefile'\" else echo shar: Extracting \"'./Makefile'\" \(494 characters\) sed "s/^X//" >'./Makefile' <<'END_OF_FILE' X# This makefile has been uglified for portability. X# Nothing yet works with gmake for the path to the sources. X.PATH: .. X XPROG= pipepoll pipeselect XCFLAGS+= -Werror -Wall X Xall: ${PROG} Xpipepoll: pipepoll.c Xpipeselect: pipeselect.c X Xpipepoll pipeselect: X ${CC} ${CFLAGS} ${LDFLAGS} -o $@ $@.c X Xtest: all X -for prog in ${PROG}; do \ X ./$${prog} > $${prog}.out.new; \ X diff -u1 $${prog}.out $${prog}.out.new; \ X done X Xclean: X for prog in ${PROG}; do \ X rm -f $${prog} $${prog}.out.new; \ X done END_OF_FILE if test 494 -ne `wc -c <'./Makefile'`; then echo shar: \"'./Makefile'\" unpacked with wrong size! fi # end of './Makefile' fi if test -f './l/pipepoll.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./l/pipepoll.out'\" else echo shar: Extracting \"'./l/pipepoll.out'\" \(834 characters\) sed "s/^X//" >'./l/pipepoll.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected 0; got 0 Xok 2 Pipe state 5: expected POLLIN; got POLLIN Xok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 4 Pipe state 6a: expected POLLHUP; got POLLHUP Xok 9 FIFO state 0: expected 0; got 0 Xok 10 FIFO state 1: expected 0; got 0 Xok 11 FIFO state 2: expected POLLIN; got POLLIN Xok 12 FIFO state 2a: expected 0; got 0 Xok 13 FIFO state 3: expected POLLHUP; got POLLHUP Xok 14 FIFO state 4: expected 0; got 0 Xok 15 FIFO state 5: expected POLLIN; got POLLIN Xok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 17 FIFO state 6a: expected POLLHUP; got POLLHUP Xok 18 FIFO state 6b: expected 0; got 0 Xok 19 FIFO state 6c: expected POLLHUP; got POLLHUP Xok 20 FIFO state 6d: expected POLLHUP; got POLLHUP END_OF_FILE if test 834 -ne `wc -c <'./l/pipepoll.out'`; then echo shar: \"'./l/pipepoll.out'\" unpacked with wrong size! fi # end of './l/pipepoll.out' fi if test -f './l/pipeselect.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./l/pipeselect.out'\" else echo shar: Extracting \"'./l/pipeselect.out'\" \(772 characters\) sed "s/^X//" >'./l/pipeselect.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected clear; got clear Xok 2 Pipe state 5: expected set; got set Xok 3 Pipe state 6: expected set; got set Xok 4 Pipe state 6a: expected set; got set Xok 9 FIFO state 0: expected clear; got clear Xok 10 FIFO state 1: expected clear; got clear Xok 11 FIFO state 2: expected set; got set Xok 12 FIFO state 2a: expected clear; got clear Xok 13 FIFO state 3: expected set; got set Xok 14 FIFO state 4: expected clear; got clear Xok 15 FIFO state 5: expected set; got set Xok 16 FIFO state 6: expected set; got set Xok 17 FIFO state 6a: expected set; got set Xok 18 FIFO state 6b: expected clear; got clear Xok 19 FIFO state 6c: expected set; got set Xok 20 FIFO state 6d: expected set; got set END_OF_FILE if test 772 -ne `wc -c <'./l/pipeselect.out'`; then echo shar: \"'./l/pipeselect.out'\" unpacked with wrong size! fi # end of './l/pipeselect.out' fi echo shar: End of shell archive. exit 0 Bruce From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 22:56:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E87CA106566C; Wed, 3 Jun 2009 22:56:26 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8FDE18FC19; Wed, 3 Jun 2009 22:56:26 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 7D92B5C024; Thu, 4 Jun 2009 06:56:25 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 07FC355CDB58; Thu, 4 Jun 2009 06:56:25 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id x27gMP7BqFzp; Thu, 4 Jun 2009 06:55:28 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id D319955CDB47; Thu, 4 Jun 2009 06:55:21 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=gkhh5L4YOGulF2RqmGN/3rD4edug0TPZnp8Zxem0xMJIc+pWX0YfSjLUDl5aubHvN 5J8jqX2J5UvJ+1h6UWGsg== Message-ID: <4A26FF44.3040609@delphij.net> Date: Wed, 03 Jun 2009 15:55:00 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: FreeBSD Stable , David Christensen X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 22:56:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, David and I have committed some fixes to 7-STABLE tree, and I think all important bce(4) fixes has been merged now. If you have bce(4) interfaces PLEASE help us to test them, the simplest way of doing this is to sync your code with RELENG_7 and rebuild kernel. [1] For those who can't test this under 7-STABLE environment, I have extracted corresponding files here: http://people.freebsd.org/~delphij/misc/193358.tar.bz2 Once can extract the tarball over /usr/src/ in order to overwrite your files, this should be applicable for a 7.2-RELEASE system. Known issues that this should have resolved: - "PHY write timeout!" when you can find "ukphy" in your dmesg output, some blade servers [Dell T610?] may have this, in particular; - incorrect input traffic accounting. (netstat 1 would show larger input traffic); - under heavy load there might be some data corruption; Please let us know if these changes would bring any regressions, thanks a lot! [1] Please note that, because bce(4) is part of GENERIC kernel so you may need to do a full "make kernel" instead of just rebuilding/installing corresponding kernel module. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkom/0QACgkQi+vbBBjt66DPzwCfSpPZ+nCJcyjcrFwfZuWSCcyl anIAoKQN/jpn45pjS/jG2jR6dsjIWbhs =Eng2 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 23:04:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEF1D1065670; Wed, 3 Jun 2009 23:04:06 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 758EB8FC08; Wed, 3 Jun 2009 23:04:06 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBzV2-00048O-8n; Thu, 04 Jun 2009 00:04:00 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBzV2-0003XZ-70; Thu, 04 Jun 2009 00:04:00 +0100 To: d@delphij.net In-Reply-To: <4A26FF44.3040609@delphij.net> Message-Id: From: Pete French Date: Thu, 04 Jun 2009 00:04:00 +0100 Cc: freebsd-stable@freebsd.org, davidch@FreeBSD.ORG Subject: Re: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jun 2009 23:04:06 -0000 > David and I have committed some fixes to 7-STABLE tree, and I think all > important bce(4) fixes has been merged now. If you have bce(4) > interfaces PLEASE help us to test them, the simplest way of doing this > is to sync your code with RELENG_7 and rebuild kernel. [1] I won't have timer to try this until friday at the earliest, but one question... is this likely to fix my infamous lagg/lacp issue ? I notice it isn't in the list of known issues. I will test anyway, but if you happen to be in that bit of code.... *does best winning smile* :-) -pete. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 3 23:19:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D60A106566C; Wed, 3 Jun 2009 23:19:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 31B9A8FC18; Wed, 3 Jun 2009 23:19:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 5CFCF5C025; Thu, 4 Jun 2009 07:19:15 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1460855CDB59; Thu, 4 Jun 2009 07:19:15 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 5NVMGZoz-mqb; Thu, 4 Jun 2009 07:18:24 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1C6C455CDB54; Thu, 4 Jun 2009 07:18:13 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=rQMUFeH/GUmRZTcTWuiAYjoEiLC5az8M4A6C8sDh0PkQm9msfV/VR2zMRgdC/ZLGP c6+7IXDF2IoL/qfumNwKg== Message-ID: <4A27049E.8040102@delphij.net> Date: Wed, 03 Jun 2009 16:17:50 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, d@delphij.net, davidch@FreeBSD.ORG Subject: Re: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 23:19:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pete French wrote: >> David and I have committed some fixes to 7-STABLE tree, and I think all >> important bce(4) fixes has been merged now. If you have bce(4) >> interfaces PLEASE help us to test them, the simplest way of doing this >> is to sync your code with RELENG_7 and rebuild kernel. [1] > > I won't have timer to try this until friday at the earliest, but one > question... is this likely to fix my infamous lagg/lacp issue ? I > notice it isn't in the list of known issues. I will test anyway, but s/known issue/known and fixed issue/ ... > if you happen to be in that bit of code.... *does best winning smile* :-) I am not quite sure about the lagg/lacp issue, perhaps we need more clue like tcpdump compare between old code and new code, as I don't have a switch capable for lacp setup at hand at this moment :( Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkonBJ4ACgkQi+vbBBjt66DXLwCdGAw0UFfrVYmNDTlwpbCnfMsm clMAoLrv0APr2//LiWCbTuS31qbzpsBz =Om0W -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 00:46:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F034F106564A for ; Thu, 4 Jun 2009 00:46:33 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id C9BA68FC13 for ; Thu, 4 Jun 2009 00:46:33 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 03 Jun 2009 16:13:01 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Wed, 3 Jun 2009 16:13:01 -0700 From: "David Christensen" To: "Pete French" , "d@delphij.net" Date: Wed, 3 Jun 2009 16:13:01 -0700 Thread-Topic: mini-HEADSUP bce owners: please test Thread-Index: Acnkn6Jep8pLF63+TDO6PpuyqecCtgAAIhHQ Message-ID: <5D267A3F22FD854F8F48B3D2B523819339DFEA2BC0@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4A26FF44.3040609@delphij.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6639DCF738O9422936-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" , "davidch@FreeBSD.ORG" Subject: RE: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 00:46:34 -0000 > > David and I have committed some fixes to 7-STABLE tree, and I think=20 > > all important bce(4) fixes has been merged now. If you have bce(4)=20 > > interfaces PLEASE help us to test them, the simplest way of=20 > doing this=20 > > is to sync your code with RELENG_7 and rebuild kernel. [1] >=20 > I won't have timer to try this until friday at the earliest,=20 > but one question... is this likely to fix my infamous=20 > lagg/lacp issue ? I notice it isn't in the list of known=20 > issues. I will test anyway, but if you happen to be in that=20 > bit of code.... *does best winning smile* :-) That should be the packet length fix at line 5973 of if_bce.c. I did not test the teaming fix myself but another user provided a similar packet length fix which he claimed did fix the issue so I'm hopeful that this should work for you too. Dave From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 00:53:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7241065690 for ; Thu, 4 Jun 2009 00:53:04 +0000 (UTC) (envelope-from root@h1603454.stratoserver.net) Received: from h1603454.stratoserver.net (paysecuritygate.com [85.214.149.143]) by mx1.freebsd.org (Postfix) with ESMTP id 4226D8FC1E for ; Thu, 4 Jun 2009 00:53:04 +0000 (UTC) (envelope-from root@h1603454.stratoserver.net) Received: by h1603454.stratoserver.net (Postfix, from userid 0) id 2E5722EB1874; Thu, 4 Jun 2009 02:34:28 +0200 (CEST) To: freebsd-stable@freebsd.org From: www.moneybookers.com Message-Id: <20090604003428.2E5722EB1874@h1603454.stratoserver.net> Date: Thu, 4 Jun 2009 02:34:28 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Update Account. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 00:53:04 -0000 ********************************************************************** ******************** THIS IS AN AUTOMATED EMAIL - . ********************************************************************** ******************** Dear Moneybookers Customer,: Due to concerns, for the safety and integrity of the Moneybookers.com account we have issued this warning message. It has come to our attention that your Moneybookers.com account information needs to be updated as part of our continuing commitment to protect your account and to reduce the instance of fraud on our website. If you could please take 5-10 minutes out of your online experience and update your personal records you will not run into any future problems with the online service. Once you have updated your account records your Moneybookers.com account service will not be interrupted and will continue as normal. To update your Moneybookers.com records click on the following link: [1]http://Moneybookers.com/ Moneybookers Security Reminders Case Sensitive Login Please remember your password is case-sensitive, at least 6 characters long and contains at least one number or non-alphabetic character such as '-'. ******************************* Moneybookers Ltd., London, Registered in England and Wales no 4260907. Registered office: Welken House, 10-11 Charterhouse Square, London, EC1M 6EH, United Kingdom. Authorised and regulated by the Financial Services Authority of the United Kingdom (FSA). References 1. http://www.protocolinfogate.com/moneybookers/directory.php?app=login.pl From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 03:51:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C4661065674 for ; Thu, 4 Jun 2009 03:51:11 +0000 (UTC) (envelope-from allnetgroup@yahoo.com) Received: from web34304.mail.mud.yahoo.com (web34304.mail.mud.yahoo.com [66.163.178.136]) by mx1.freebsd.org (Postfix) with SMTP id 1DEC18FC12 for ; Thu, 4 Jun 2009 03:51:10 +0000 (UTC) (envelope-from allnetgroup@yahoo.com) Received: (qmail 51574 invoked by uid 60001); 4 Jun 2009 03:24:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244085869; bh=ZnGj73zNy/q4Lm5EylDLnXZTy1bw3OROg2OmGG4YQ6g=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=MgOvYzXvwzhKvLe0LYEAzLmMwUiA/h4uWjrbiJfz5yW8ixyjqRPS1bq5jYVf1fmHoSM0nVCAReeNY8u9w1IV96qMAZgcVKlcrT6ujIyDHkUeEjDVbXyN/czpMDSD489Qyv8XQZjbvGrb31x3BurApYB71U4MY+qqtFcjq5+MwbQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ATOjoV78/BcC/JzM9aXnjK8m1NddOtr/Lm/3i5ftaeoOWFCRiNLhtnBMFqE7gIsYddnnq3QqE0y+V9yTYsSb8ZqLWzQVCmEwAiPrHDVAI3ey3lawh/pkj+XDha5A/043NricDX4gHb3etosmW5Iy0Z8CVabz/ZQuQZ2kSnLAH20=; Message-ID: <647359.51078.qm@web34304.mail.mud.yahoo.com> X-YMail-OSG: w5iTtVsVM1mqJW04A79XL_ZRbWrLM0c4UAHaitbasS.QkjIM03nmu7x5zFpKZlmxSU9J.JsRoY8rWsFoiH2NSIhp_JK68_182grj3rj7uxDBI0aMTXF0PQzAtk5jvLe6.YPz3HFKQcREMEp4zRR0SgsPA3m5hiGWDgfW5Q.dPzAnSnfesp9a1cmJhzdhJlBOP8i8TQbq6ufpuM3XqwlpHRxhHaRHYXnzNGN4_mFyujeSK1JN4QHdyDY_CEqvMGGX1ZodPpsK6if7CnMvhi1u3K3hPJ3zcJMAGKk77_QbXCeil7CF3vTo0.BSaAMtAoG0.o5BK9W0j7s- Received: from [63.224.210.185] by web34304.mail.mud.yahoo.com via HTTP; Wed, 03 Jun 2009 20:24:29 PDT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.10 Date: Wed, 3 Jun 2009 20:24:29 -0700 (PDT) From: AES To: freebsd-stable@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 04 Jun 2009 05:03:47 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: latest stable version of FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: allnetgroup@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 03:51:11 -0000 Where can I download the latest stable version of FreeBSD? From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 05:49:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB49E1065672 for ; Thu, 4 Jun 2009 05:49:06 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4884F8FC17 for ; Thu, 4 Jun 2009 05:49:06 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz9 with SMTP id 9so449810bwz.43 for ; Wed, 03 Jun 2009 22:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uahGHBgVHNuJqaJLAMin0+ryp4KLYFnJ0r4l+7AG9IY=; b=Y80Ep4hiCg65bRZ8vwRbAwk9meoynFgCnEMlodRa10tUrtRfPOWJsIOWML2KmO96aG qwlAVY6XEApyN3z/eSY/R8ww33gTw+rEyHKX23bjp+YU9YeBbxGpMl2edlkhg51O8Zww cCRo7bbYeB6lePDrmZ1MlxMxb3Z70KPNp2lYU= 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=r3ROuCE+PBtmCJbQA6xYypHSYfpJWjwXx/A3oKDTcBx7ucFizoFmib3kfZUcUywUtD stZ53JciyfpXafI52JBFWHmJe/qSoXeQS+IcjtCPD8ISaYXvFfXzkqiDWUaNDd10zcmY Y0rJbyMW8jzZ49JHrOE+3TNikwDA4XjI+okss= MIME-Version: 1.0 Received: by 10.204.116.15 with SMTP id k15mr1632612bkq.118.1244094544841; Wed, 03 Jun 2009 22:49:04 -0700 (PDT) In-Reply-To: <647359.51078.qm@web34304.mail.mud.yahoo.com> References: <647359.51078.qm@web34304.mail.mud.yahoo.com> Date: Thu, 4 Jun 2009 01:49:04 -0400 Message-ID: <4ad871310906032249v1a88e71frd535b45a998f7633@mail.gmail.com> From: Glen Barber To: allnetgroup@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: latest stable version of FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 05:49:07 -0000 On Wed, Jun 3, 2009 at 11:24 PM, AES wrote: > Where can I download the latest stable version of FreeBSD? http://www.freebsd.org/where.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ -- Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 09:50:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3120106566C; Thu, 4 Jun 2009 09:50:54 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 891D28FC13; Thu, 4 Jun 2009 09:50:54 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MC9Zz-0000h9-L2; Thu, 04 Jun 2009 10:49:47 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MC9Zz-0000Pv-JN; Thu, 04 Jun 2009 10:49:47 +0100 To: d@delphij.net, davidch@broadcom.com In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819339DFEA2BC0@IRVEXCHCCR01.corp.ad.broadcom.com> Message-Id: From: Pete French Date: Thu, 04 Jun 2009 10:49:47 +0100 Cc: freebsd-stable@freebsd.org, davidch@FreeBSD.ORG Subject: RE: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 09:50:55 -0000 > That should be the packet length fix at line 5973 of if_bce.c. I did That's the patch whcih was sent to the PR, yes ? I've tried that and it doesn't fix it at all for me unfortunately. > not test the teaming fix myself but another user provided a similar > packet length fix which he claimed did fix the issue so I'm hopeful > that this should work for you too. I'll tgive this new lot of code a test tomorrow (am in London all day today unfortunately) and let you knwo the results. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 10:33:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9936E106566C; Thu, 4 Jun 2009 10:33:50 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5200D8FC1F; Thu, 4 Jun 2009 10:33:49 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCAGV-0001JP-4B; Thu, 04 Jun 2009 11:33:43 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCAGV-0000b0-2R; Thu, 04 Jun 2009 11:33:43 +0100 To: d@delphij.net, davidch@broadcom.com In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819339DFEA2BC0@IRVEXCHCCR01.corp.ad.broadcom.com> Message-Id: From: Pete French Date: Thu, 04 Jun 2009 11:33:43 +0100 Cc: freebsd-stable@freebsd.org, davidch@FreeBSD.ORG Subject: RE: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 10:33:50 -0000 Well, I found time to test this today after all - and it does actually fix the issue - my bce devices now work properly with lagg and lacp. thankyou! -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 11:39:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDF221065674 for ; Thu, 4 Jun 2009 11:39:03 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 352C88FC08 for ; Thu, 4 Jun 2009 11:39:02 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 69990 invoked from network); 4 Jun 2009 11:39:01 -0000 Received: from unknown (HELO snowwhite.local) (smtpsend@89.247.15.48) by mail.h3q.com with AES256-SHA encrypted SMTP; 4 Jun 2009 11:39:01 -0000 Message-ID: <4A27B255.8010500@h3q.com> Date: Thu, 04 Jun 2009 13:39:01 +0200 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dan Naumov References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> <4A268BEA.5040706@h3q.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: manageBE and ZFS boot-environments WAS [Re: ZFS NAS configuration question] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 11:39:04 -0000 Dan Naumov wrote: > Anyone else think that this combined with freebsd-update integration > and a simplistic menu GUI for choosing the preferred boot environment > would make an _awesome_ addition to the base system? :) I guess freebsd-update is not a problem, should be "freebsd-update -b ". But I can't test this, because I can't update STABLE with freebsd-update. ;-) I wrote a small step-by-step example to show how stuff works: http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/example.txt greetings, philipp From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 15:00:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60CF5106566B; Thu, 4 Jun 2009 15:00:25 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 35C058FC0A; Thu, 4 Jun 2009 15:00:25 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Jun 2009 08:00:10 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Thu, 4 Jun 2009 08:01:34 -0700 From: "David Christensen" To: "Pete French" , "d@delphij.net" Date: Thu, 4 Jun 2009 08:00:09 -0700 Thread-Topic: mini-HEADSUP bce owners: please test Thread-Index: Acnk//0WYpBRNN3ARoKX7baHv2dF2QAJR7hw Message-ID: <5D267A3F22FD854F8F48B3D2B523819339DFF5F3D4@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819339DFEA2BC0@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66393EF038O10216166-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" , "davidch@FreeBSD.ORG" Subject: RE: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 15:00:25 -0000 > Well, I found time to test this today after all - and it does=20 > actually fix the issue - my bce devices now work properly=20 > with lagg and lacp. Thanks for the confirmation. Dave= From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 15:05:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4231B1065674 for ; Thu, 4 Jun 2009 15:05:39 +0000 (UTC) (envelope-from tim@chase2k.com) Received: from smtp.onlight.com (mx1.onlight.com [96.61.34.6]) by mx1.freebsd.org (Postfix) with ESMTP id F3F4D8FC18 for ; Thu, 4 Jun 2009 15:05:38 +0000 (UTC) (envelope-from tim@chase2k.com) Received: from localhost (livingston [127.0.0.1]) by clean.onlight.com (Postfix) with ESMTP id E670F82012AB for ; Thu, 4 Jun 2009 09:47:35 -0500 (CDT) X-Virus-Scanned: amavisd-new at onlight.com Received: from smtp.onlight.com ([127.0.0.1]) by localhost (filter.onlight.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9Rv+VqVEugu7 for ; Thu, 4 Jun 2009 09:47:34 -0500 (CDT) Received: from oink.onlight.com (oink.onlight.com [10.10.1.29]) by smtp.onlight.com (Postfix) with ESMTPA id ACA6082012A7 for ; Thu, 4 Jun 2009 09:47:34 -0500 (CDT) Date: Thu, 4 Jun 2009 09:48:15 -0500 (CDT) From: Tim Chase Sender: tim@localhost.localdomain To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: kmem map too small panic after updating to STABLE-7 r192996 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 15:05:39 -0000 Hello, I decided to give the new zfs code a try and upgraded my stable-7 system and discovered a panic that I can reproduce at will. This is an i386 system with 1.5GB of RAM and a single zfs pool: appbuild# zpool status pool: backup state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM backup ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 errors: No known data errors I had previously used the following zfs tuning: vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="100M" After getting this panic, I removed these tunables. The panic happens in either case. Reproducing the panic is easy: I keep a copy of the FreeBSD svn tree in a compressed zfs file system (compression ratio runs around 1.35x). An "svn update" (or the requisite "svn cleanup" following a system crash) in my checkout area will _always_ result in a "kmem map too small" panic. Here's a stack trace from my most recent panic: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc052c963 in boot (howto=260) at /root/stable-7/sys/kern/kern_shutdown.c:418 #2 0xc052cb9d in panic (fmt=Variable "fmt" is not available. ) at /root/stable-7/sys/kern/kern_shutdown.c:574 #3 0xc069fa2a in kmem_malloc (map=0xc105408c, size=131072, flags=2) at /root/stable-7/sys/vm/vm_kern.c:305 #4 0xc0696587 in page_alloc (zone=0x0, bytes=131072, pflag=0xe6dbcb47 "\002", wait=2) at /root/stable-7/sys/vm/uma_core.c:952 #5 0xc0699000 in uma_large_malloc (size=131072, wait=2) at /root/stable-7/sys/vm/uma_core.c:2706 #6 0xc051af38 in malloc (size=131072, mtp=0xc094f060, flags=2) at /root/stable-7/sys/kern/kern_malloc.c:393 #7 0xc085db00 in zfs_kmem_alloc (size=131072, kmflags=2) at /root/stable-7/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:74 #8 0xc08d1c79 in zio_buf_alloc (size=131072) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:207 #9 0xc08bcc40 in vdev_queue_io_to_issue (vq=0xc492b334, pending_limit=Variable "pending_limit" is not available. ) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:227 #10 0xc08bce42 in vdev_queue_io_done (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:313 #11 0xc08d4162 in zio_vdev_io_done (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1847 #12 0xc08d2532 in zio_execute (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #13 0xc0862aa0 in taskq_thread (arg=0xc44a10cc) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/os/taskq.c:854 #14 0xc0506816 in fork_exit (callout=0xc0862960 , arg=0xc44a10cc, frame=0xe6dbcd38) at /root/stable-7/sys/kern/kern_fork.c:811 #15 0xc06d4670 in fork_trampoline () at /root/stable-7/sys/i386/i386/exception.s:264 (kgdb) print panicstr $1 = 0xc0792320 "kmem_malloc(131072): kmem_map too small: 325656576 total allocated" The arc size is now auto-tuned as: kstat.zfs.misc.arcstats.c_min: 26214400 kstat.zfs.misc.arcstats.c_max: 209715200 and while monitoring kstat.zfs.misc.arcstats.size I noticed it fluctuated between around 140 and 150 million. Interestingly enough, immediately before the last panic, It (arcstats.size) had just been reduced from 150038268 to 128790020. I'm going to continue to poke around in my core dumps and see if I can figure out what's going on. Any hints as to what to look for or monitor while the system is running would be appreciated. Thanks, Tim From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 15:25:19 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA2ED106566C for ; Thu, 4 Jun 2009 15:25:19 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.bestunion.it (mail.bestunion.it [85.18.201.87]) by mx1.freebsd.org (Postfix) with ESMTP id 60A7F8FC08 for ; Thu, 4 Jun 2009 15:25:18 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from [192.168.33.30] (nbcommit.home.commit.it [192.168.33.30] (may be forged)) (authenticated bits=0) by mail.bestunion.it (8.14.3/8.14.3) with ESMTP id n54FPGbm010110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Jun 2009 17:25:17 +0200 (CEST) (envelope-from aturetta@commit.it) Message-ID: <4A27E757.1040104@commit.it> Date: Thu, 04 Jun 2009 17:25:11 +0200 From: Angelo Turetta User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at mail.bestunion.it X-Virus-Status: Clean Cc: Subject: floppy unusable in VMWare guest? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 15:25:20 -0000 I'm trying to use a virtual floppy from FreeBSD 7 (both 7-STABLE and 7_2_RELEASE) in a VMWare test installation. Both running fdformat on a fresh floppy image and trying to mount a preformatted one, I get errors like: g_vfs_done():fd0[READ(offset=0, length=8192)]error = 6 Of course, after booting the same VM with a DOS live CD, the floppy is perfectly functional. I found a reference in a vmware forum post (some three years old), does anybody know if this is supposed to work? http://communities.vmware.com/thread/51022 Thanks, Angelo From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 18:28:45 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CEB7106572D for ; Thu, 4 Jun 2009 18:28:45 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.bestunion.it (mail.bestunion.it [85.18.201.87]) by mx1.freebsd.org (Postfix) with ESMTP id A04DB8FC2B for ; Thu, 4 Jun 2009 18:28:43 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from [192.168.33.30] (nbcommit.home.commit.it [192.168.33.30] (may be forged)) (authenticated bits=0) by mail.bestunion.it (8.14.3/8.14.3) with ESMTP id n54ISbeQ018453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2009 20:28:38 +0200 (CEST) (envelope-from aturetta@commit.it) Message-ID: <4A281250.5050306@commit.it> Date: Thu, 04 Jun 2009 20:28:32 +0200 From: Angelo Turetta User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Tim Chase References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at mail.bestunion.it X-Virus-Status: Clean Cc: freebsd-stable@FreeBSD.org Subject: Re: kmem map too small panic after updating to STABLE-7 r192996 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 18:28:46 -0000 Tim Chase wrote: > Hello, > > I decided to give the new zfs code a try and upgraded my stable-7 system > and discovered a panic that I can reproduce at will. I just had the same problem, and it turned out I was not diligent when I first set my zfs pool up :) To use vm.kmem_size="512M" you need to put options KVA_PAGES=512 in your kernel. I remember trying the loader.conf settings on a GENERIC kernel, found it worked and forgot to add KVA_PAGES. It seems that recently the memory allocated by a ZFS kernel on startup has become larger than the default KVA_PAGES in GENERIC. Hope this helps, Angelo Turetta From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 19:15:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 937CF1065677 for ; Thu, 4 Jun 2009 19:15:15 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 328578FC1E for ; Thu, 4 Jun 2009 19:15:13 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from [192.168.1.105] (static-70-108-250-162.res.east.verizon.net [70.108.250.162]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n54IZmCY053318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Jun 2009 18:35:54 GMT (envelope-from ben@wanderview.com) Message-Id: <3B36D8F8-7325-49A3-9F1F-42326C661E6D@wanderview.com> From: Ben Kelly To: Tim Chase In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 4 Jun 2009 14:35:42 -0400 References: X-Mailer: Apple Mail (2.935.3) X-Spam-Score: -0.72 () AWL X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-stable@freebsd.org Subject: Re: kmem map too small panic after updating to STABLE-7 r192996 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 19:15:16 -0000 On Jun 4, 2009, at 10:48 AM, Tim Chase wrote: > vm.kmem_size="512M" > vm.kmem_size_max="512M" > vfs.zfs.arc_max="100M" > $1 = 0xc0792320 "kmem_malloc(131072): kmem_map too small: 325656576 > total allocated" It looks like you are suffering from fragmentation of your kmem address space. I've done some investigation of this on -current: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=909067+0+archive/2009/freebsd-current/20090503.freebsd-current The patch linked from that mail allows me to run with an untuned ARC size with kmem of 512 MB. It does this, however, by more aggressively limiting how the ARC grows so it doesn't need to trigger its aggressive memory reclamation algorithm. I haven't tested this patch against -stable or with Kip's more recent changes so I don't know if it will apply cleanly for you. I've had some luck avoiding the fragmentation by changing ZFS to use a separate memory pool with a 128KB slab allocator, but this isn't really ready for general usage. Unfortunately I've been quite busy at work lately and haven't had time to work on it in a few weeks. I think with the current code base your only options are to increase your kmem maximum or limit your ARC even further. I hope that helps. - Ben From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 21:13:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33153106566C for ; Thu, 4 Jun 2009 21:13:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id E00DC8FC16 for ; Thu, 4 Jun 2009 21:13:44 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so556314ana.13 for ; Thu, 04 Jun 2009 14:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=HrR8gpNFMcuEKMv4Zpc6VeX8PYi3cwCDHHkKPRpXR6M=; b=sKZBpCvo96H2sV+E27C+6bfCnftnP5H/m2YJGiSmzlvuLiw4XQ0h6n1XtajNkUugVF vceDYSoBR8hxH4vaU8GMpe23mfABKk5P0iBt3eCMlxU7RmbxTQcFcKgt7cjoK7t41jpg NQqJng1Y1nG9vLEs/4zj1sWWYKS77J3J8NtpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cs5i6yK8hc2JWRH7ZYdPF1PpNRYT54mJ1J/gqC0C/uMU8Se62Rj5BRDA4B8lXTZgMj tRPOqHfqLPc8JmZR+sh8lLEt/PIoCy5QrJKcd/vSTlH0LyIZuJmD8+QvxG10F7FRkcem 5KguT9xmyr/u34bon6MGGbEFHvqfV3Zqc2YKw= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.119.17 with SMTP id r17mr3338396anc.3.1244150024293; Thu, 04 Jun 2009 14:13:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Jun 2009 14:13:44 -0700 X-Google-Sender-Auth: 5fa3c64633d3e669 Message-ID: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> From: Kip Macy To: Tim Chase Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: kmem map too small panic after updating to STABLE-7 r192996 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 21:13:45 -0000 As I mentioned in the initial e-mail, auto-tuning is only safe to rely on on amd64. -Kip On Thu, Jun 4, 2009 at 7:48 AM, Tim Chase wrote: > Hello, > > I decided to give the new zfs code a try and upgraded my stable-7 system > and discovered a panic that I can reproduce at will. > > This is an i386 system with 1.5GB of RAM and a single zfs pool: > > =A0 =A0 =A0 =A0appbuild# zpool status > =A0 =A0 =A0 =A0 =A0pool: backup > =A0 =A0 =A0 =A0 state: ONLINE > =A0 =A0 =A0 =A0status: The pool is formatted using an older on-disk forma= t. =A0The > pool can > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still be used, but some features are unava= ilable. > =A0 =A0 =A0 =A0action: Upgrade the pool using 'zpool upgrade'. =A0Once th= is is done, > the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pool will no longer be accessible on older= software versions. > =A0 =A0 =A0 =A0 scrub: none requested > =A0 =A0 =A0 =A0config: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRI= TE CKSUM > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0backup =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0= =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mirror =A0 =A0ONLINE =A0 =A0 =A0 0 =A0= =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ad4 =A0 =A0 ONLINE =A0 =A0 =A0 0 = =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ad6 =A0 =A0 ONLINE =A0 =A0 =A0 0 = =A0 =A0 0 =A0 =A0 0 > > =A0 =A0 =A0 =A0errors: No known data errors > > I had previously used the following zfs tuning: > > =A0 =A0 =A0 =A0vm.kmem_size=3D"512M" > =A0 =A0 =A0 =A0vm.kmem_size_max=3D"512M" > =A0 =A0 =A0 =A0vfs.zfs.arc_max=3D"100M" > > After getting this panic, I removed these tunables. =A0The panic happens > in either case. > > Reproducing the panic is easy: I keep a copy of the FreeBSD svn tree > in a compressed zfs file system (compression ratio runs around 1.35x). > An "svn update" (or the requisite "svn cleanup" following a system crash) > in my checkout area will _always_ result in a "kmem map too small" panic. > Here's a stack trace from my most recent panic: > > (kgdb) bt > #0 =A0doadump () at pcpu.h:196 > #1 =A00xc052c963 in boot (howto=3D260) at > /root/stable-7/sys/kern/kern_shutdown.c:418 > #2 =A00xc052cb9d in panic (fmt=3DVariable "fmt" is not available. > ) at /root/stable-7/sys/kern/kern_shutdown.c:574 > #3 =A00xc069fa2a in kmem_malloc (map=3D0xc105408c, size=3D131072, flags= =3D2) at > /root/stable-7/sys/vm/vm_kern.c:305 > #4 =A00xc0696587 in page_alloc (zone=3D0x0, bytes=3D131072, pflag=3D0xe6d= bcb47 > "\002", wait=3D2) > =A0 =A0at /root/stable-7/sys/vm/uma_core.c:952 > #5 =A00xc0699000 in uma_large_malloc (size=3D131072, wait=3D2) at > /root/stable-7/sys/vm/uma_core.c:2706 > #6 =A00xc051af38 in malloc (size=3D131072, mtp=3D0xc094f060, flags=3D2) a= t > /root/stable-7/sys/kern/kern_malloc.c:393 > #7 =A00xc085db00 in zfs_kmem_alloc (size=3D131072, kmflags=3D2) > =A0 =A0at > /root/stable-7/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensol= aris_kmem.c:74 > #8 =A00xc08d1c79 in zio_buf_alloc (size=3D131072) > =A0 =A0at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/= fs/zfs/zio.c:207 > #9 =A00xc08bcc40 in vdev_queue_io_to_issue (vq=3D0xc492b334, > pending_limit=3DVariable "pending_limit" is not available. > ) > =A0 =A0at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/= fs/zfs/vdev_queue.c:227 > #10 0xc08bce42 in vdev_queue_io_done (zio=3D0xd420a000) > =A0 =A0at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/= fs/zfs/vdev_queue.c:313 > #11 0xc08d4162 in zio_vdev_io_done (zio=3D0xd420a000) > =A0 =A0at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/= fs/zfs/zio.c:1847 > #12 0xc08d2532 in zio_execute (zio=3D0xd420a000) > =A0 =A0at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/= fs/zfs/zio.c:998 > #13 0xc0862aa0 in taskq_thread (arg=3D0xc44a10cc) > =A0 =A0at > /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/= os/taskq.c:854 > #14 0xc0506816 in fork_exit (callout=3D0xc0862960 , > arg=3D0xc44a10cc, frame=3D0xe6dbcd38) > =A0 =A0at /root/stable-7/sys/kern/kern_fork.c:811 > #15 0xc06d4670 in fork_trampoline () at > /root/stable-7/sys/i386/i386/exception.s:264 > (kgdb) print panicstr > $1 =3D 0xc0792320 "kmem_malloc(131072): kmem_map too small: 325656576 tot= al > allocated" > > > The arc size is now auto-tuned as: > > =A0 =A0 =A0 =A0kstat.zfs.misc.arcstats.c_min: 26214400 > =A0 =A0 =A0 =A0kstat.zfs.misc.arcstats.c_max: 209715200 > > and while monitoring kstat.zfs.misc.arcstats.size I noticed it fluctuated > between around 140 and 150 million. =A0Interestingly enough, immediately > before the last panic, It (arcstats.size) had just been reduced from > 150038268 to 128790020. > > I'm going to continue to poke around in my core dumps and see if I can > figure out what's going on. =A0Any hints as to what to look for or monito= r > while the system is running would be appreciated. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Tim > _______________________________________________ > 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" > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 21:22:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 676D21065675; Thu, 4 Jun 2009 21:22:06 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA4B8FC1F; Thu, 4 Jun 2009 21:22:06 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 473725C06F; Fri, 5 Jun 2009 05:22:05 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id C025055CDB70; Fri, 5 Jun 2009 05:22:04 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id e92znOB0ZdG0; Fri, 5 Jun 2009 05:21:08 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 387F355CDB6A; Fri, 5 Jun 2009 05:20:41 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=D4Iuq3LuUt13G9n0Imk9E3iBvG2QekjnmeXBICMYnuGzkKJMtO/+oUEDnWZNuRIuU qTC2u78mH/LazQXFaLFdQ== Message-ID: <4A283A91.6050304@delphij.net> Date: Thu, 04 Jun 2009 14:20:17 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, davidch@broadcom.com, d@delphij.net, davidch@FreeBSD.ORG Subject: Re: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 21:22:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Pete, Pete French wrote: > Well, I found time to test this today after all - and it does actually > fix the issue - my bce devices now work properly with lagg and lacp. So can we claim that the problem has been solved? Could you please give us a copy of output from 'ident /sys/dev/bce/* /sys/dev/mii/miidev /sys/dev/mii/brgphy*'? Thanks a lot! Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkooOpAACgkQi+vbBBjt66AfmACgiBt6eFHw8FKb5ePxrHemUgQh PUoAoJGN/rDDoROe6s7mW3PRWNHtOOzr =ukF3 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 21:48:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C46E106567E; Thu, 4 Jun 2009 21:48:41 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id C423D8FC14; Thu, 4 Jun 2009 21:48:40 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCKnb-00076X-Qy; Thu, 04 Jun 2009 22:48:35 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCKnb-0002Nz-PP; Thu, 04 Jun 2009 22:48:35 +0100 To: delphij@delphij.net In-Reply-To: <4A283A91.6050304@delphij.net> Message-Id: From: Pete French Date: Thu, 04 Jun 2009 22:48:35 +0100 Cc: freebsd-stable@freebsd.org, davidch@broadcom.com, d@delphij.net, davidch@FreeBSD.ORG Subject: Re: mini-HEADSUP bce owners: please test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 21:48:41 -0000 > So can we claim that the problem has been solved? Could you please give > us a copy of output from 'ident /sys/dev/bce/* /sys/dev/mii/miidev > /sys/dev/mii/brgphy*'? Yes, it looks very much that way. I've no idea what changed to fix it, but it is certainly working now on my test machine. I will try a rollout to my other machines over the next few days. Here is the ident output: [webadmin@florentine ~]$ ident /sys/dev/bce/* /sys/dev/mii/miidevs /sys/dev/mii/brgphy* /sys/dev/bce/if_bce.c: $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.34.2.9 2009/06/01 10:49:08 delphij Exp $ /sys/dev/bce/if_bcefw.h: $FreeBSD: src/sys/dev/bce/if_bcefw.h,v 1.4.2.2 2009/03/31 01:01:01 delphij Exp $ /sys/dev/bce/if_bcereg.h: $FreeBSD: src/sys/dev/bce/if_bcereg.h,v 1.16.2.3 2009/05/20 21:13:49 delphij Exp $ /sys/dev/mii/miidevs: $FreeBSD: src/sys/dev/mii/miidevs,v 1.46.2.11 2009/06/02 23:30:02 davidch Exp $ $NetBSD: miidevs,v 1.6 1999/05/14 11:37:30 drochner Exp $ /sys/dev/mii/brgphy.c: $FreeBSD: src/sys/dev/mii/brgphy.c,v 1.70.2.6 2009/06/02 23:30:02 davidch Exp $ /sys/dev/mii/brgphyreg.h: $FreeBSD: src/sys/dev/mii/brgphyreg.h,v 1.10.2.1 2008/06/27 03:24:54 jhb Exp $ cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 21:58:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6026F106567D for ; Thu, 4 Jun 2009 21:58:15 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 16CEB8FC20 for ; Thu, 4 Jun 2009 21:58:14 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so564963ywe.13 for ; Thu, 04 Jun 2009 14:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=SCQnE6S6ugBj1RAqzlxgIZzw/OF3jDLexwRho6UwcP8=; b=pi39IA+I26r0lI2Mwomgj62XW7VXw4iYox0xh+NgCHZLA3ymHM/oMCVrjBGwX8q0Sm qxWLOCx//sWkyUvbG/jIP9YKF7MbufZuJ03Aow9Bnx+rqWPl4XHm9xgkSkOAsm3IEV48 4ouxl7FYP3goUezke9Kxan4iSsFYl4xnyeYYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XgbAUou8VkFiiJjQnksLFdpwcg1UlptarJuJad1cpQT85LKFoOP7kwTIUR6mJRxYJU OmDmCgidn34ncEX/yO4yU3egxU2qT7UfeDgRJOj3UlMmzIlQAtSzz1YnEnRW7wofr0eh xSuqoXKqc2HGsL9mEH7h35Fq1FzmCFAQ0qq1I= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.119.17 with SMTP id r17mr3402584anc.3.1244152693011; Thu, 04 Jun 2009 14:58:13 -0700 (PDT) In-Reply-To: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> References: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> Date: Thu, 4 Jun 2009 14:58:11 -0700 X-Google-Sender-Auth: 02da4a64f3639e6e Message-ID: <3c1674c90906041458i19fd589fs2f03b3e7064209ca@mail.gmail.com> From: Kip Macy To: Tim Chase Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: kmem map too small panic after updating to STABLE-7 r192996 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 21:58:16 -0000 On Thu, Jun 4, 2009 at 2:13 PM, Kip Macy wrote: > As I mentioned in the initial e-mail, auto-tuning is only safe to rely > on on amd64. > Tying ZFS in to UMA to allow zone limits to reduce memory pressure on write as well as reduce the ARC's ability to grow without bound is on my to do list. However, I haven't gotten to it yet. -Kip From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 22:14:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE4D61065698 for ; Thu, 4 Jun 2009 22:14:43 +0000 (UTC) (envelope-from tim@chase2k.com) Received: from smtp.onlight.com (mx1.onlight.com [96.61.34.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF878FC1C for ; Thu, 4 Jun 2009 22:14:43 +0000 (UTC) (envelope-from tim@chase2k.com) Received: from localhost (livingston [127.0.0.1]) by clean.onlight.com (Postfix) with ESMTP id 4F54D82012B2; Thu, 4 Jun 2009 17:14:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at onlight.com Received: from smtp.onlight.com ([127.0.0.1]) by localhost (filter.onlight.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pw13cXOmY-Ok; Thu, 4 Jun 2009 17:14:40 -0500 (CDT) Received: from oink.onlight.com (oink.onlight.com [10.10.1.29]) by smtp.onlight.com (Postfix) with ESMTPA id 462B382012AA; Thu, 4 Jun 2009 17:14:40 -0500 (CDT) Date: Thu, 4 Jun 2009 17:15:23 -0500 (CDT) From: Tim Chase Sender: tim@localhost.localdomain To: Kip Macy In-Reply-To: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> Message-ID: References: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: kmem map too small panic after updating to STABLE-7 r192996 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 22:14:44 -0000 On Thu, 4 Jun 2009, Kip Macy wrote: > As I mentioned in the initial e-mail, auto-tuning is only safe to rely > on on amd64. OK, that wasn't clear to me with the latest zfs code. I'll try it with a proper 512M setting as I was using before (along with setting KVA_PAGES). - Tim From owner-freebsd-stable@FreeBSD.ORG Thu Jun 4 22:46:41 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06425106566C for ; Thu, 4 Jun 2009 22:46:41 +0000 (UTC) (envelope-from tim@chase2k.com) Received: from smtp.onlight.com (mx1.onlight.com [96.61.34.6]) by mx1.freebsd.org (Postfix) with ESMTP id CE14D8FC1C for ; Thu, 4 Jun 2009 22:46:40 +0000 (UTC) (envelope-from tim@chase2k.com) Received: from localhost (livingston [127.0.0.1]) by clean.onlight.com (Postfix) with ESMTP id 23A3B82012B0; Thu, 4 Jun 2009 17:46:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at onlight.com Received: from smtp.onlight.com ([127.0.0.1]) by localhost (filter.onlight.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4kuqtbhQCEw3; Thu, 4 Jun 2009 17:46:38 -0500 (CDT) Received: from oink.onlight.com (oink.onlight.com [10.10.1.29]) by smtp.onlight.com (Postfix) with ESMTPA id 2228383218A9; Thu, 4 Jun 2009 17:46:38 -0500 (CDT) Date: Thu, 4 Jun 2009 17:47:14 -0500 (CDT) From: Tim Chase Sender: tim@localhost.localdomain To: Angelo Turetta In-Reply-To: <4A281250.5050306@commit.it> Message-ID: References: <4A281250.5050306@commit.it> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org Subject: Re: kmem map too small panic after updating to STABLE-7 r192996 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jun 2009 22:46:41 -0000 On Thu, 4 Jun 2009, Angelo Turetta wrote: > Tim Chase wrote: >> Hello, >> >> I decided to give the new zfs code a try and upgraded my stable-7 system >> and discovered a panic that I can reproduce at will. > > I just had the same problem, and it turned out I was not diligent when I > first set my zfs pool up :) > > To use vm.kmem_size="512M" you need to put > > options KVA_PAGES=512 >... Thanks for the reminder. I had forgotten about this one, too. With my kmem size @ 512M now and with KVA_PAGES at 512, my svn test case works just fine. I guess I should have paid closer attention to the actual panic message. - Tim From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 00:37:02 2009 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 A1D93106566B for ; Fri, 5 Jun 2009 00:37:02 +0000 (UTC) (envelope-from lynx.ripe@gmail.com) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by mx1.freebsd.org (Postfix) with ESMTP id 0170D8FC13 for ; Fri, 5 Jun 2009 00:37:01 +0000 (UTC) (envelope-from lynx.ripe@gmail.com) Received: by fxm7 with SMTP id 7so755125fxm.43 for ; Thu, 04 Jun 2009 17:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=AvfBsu06ZIQqTX8KDyQEa2EwgEBrVQVednOqFwiN8Ic=; b=hdouCGIng3Qnpuf5kpZxDCvyyLnk7UteHzdVD05K94vTnEmb1Hr5JiZ4/TQONK5xeE 1RQ4fOBRT0hAXdhy81n0IUFPBY0aflop8zAY0v2Hur6t5zieEH/RkC9KMlAB6t0Tk5e+ ba1bs0PRiVPylQD/162jADSg7Sh4GYlaJkIsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=xRCyM1PXvhZWDBE3NWy2pU03Dkdnnm9e7wxp3f4/ZBr/H2CL8V+UTZU23HB7KsLS4h 9QmPcDlGTHNeK5r0Fy1SoH1U8QczMOEVYioUlL4ttLBfPEkSEmaQuUssmqlm9Vnx80Ef p5ZiFGeBSxjEoy+O1s4FNYVgPxrfJJBf2Pkhc= MIME-Version: 1.0 Received: by 10.239.136.68 with SMTP id g4mr235196hbg.58.1244160324991; Thu, 04 Jun 2009 17:05:24 -0700 (PDT) Date: Fri, 5 Jun 2009 03:05:24 +0300 Message-ID: <754a9c140906041705x6719afd4nd672ffa15975d2ac@mail.gmail.com> From: Dmitry Pryanishnikov To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Inconsistent checkout results for RELENG_7 at exact date X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 00:37:02 -0000 Hello! I'm trying to check out the FreeBSD source tree with the tag=RELENG_7 in the same state that it had at the exact date/time, e.g. 2009-05-04 18:00 UTC. So I'm using the following supfile: *default host=cvsup.ua.freebsd.org *default base=/root/sup/base *default delete use-rel-suffix compress *default release=cvs *default prefix=/usr/ftp/RELENG_7 tag=RELENG_7 date=2009.05.04.18.00.00 src-all I am starting with empty /usr/ftp/RELENG_7/src. However I am consistently (with both csup and cvsup) getting files that weren't in RELENG_7 at the specified time, e.g. src/cddl/usr.bin/zinject/Makefile (it was MFCed only 2009-05-20!). What am I doing wrong? -- Sincerely, Dmitry nic-hdl: LYNX-RIPE From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 08:44:26 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 085321065673; Fri, 5 Jun 2009 08:44:26 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 786368FC19; Fri, 5 Jun 2009 08:44:25 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n558iNSm015007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 10:44:23 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n558iNK0015006; Fri, 5 Jun 2009 10:44:23 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Fri, 5 Jun 2009 10:44:23 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Kip Macy Message-ID: <20090605084423.GA1609@acme.spoerlein.net> Mail-Followup-To: Kip Macy , freebsd-stable@freebsd.org References: <20090602091610.GE93344@acme.spoerlein.net> <20090602092408.GF93344@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090602092408.GF93344@acme.spoerlein.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@FreeBSD.org Subject: Re: ZFS weird device tasting loop since MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 08:44:26 -0000 On Tue, 02.06.2009 at 11:24:08 +0200, Ulrich Spörlein wrote: > On Tue, 02.06.2009 at 11:16:10 +0200, Ulrich Spörlein wrote: > > Hi all, > > > > so I went ahead and updated my ~7.2 file server to the new ZFS goodness, > > and before running any further tests, I already discovered something > > weird and annoying. > > > > I'm using a mirror on GELI, where one disk is usually *not* attached as > > a means of poor man's backup. (I had to go that route, as send/recv of > > snapshots frequently deadlocked the system, whereas a mirror scrubbing > > did not) > > > > root@coyote:~# zpool status > > pool: tank > > state: DEGRADED > > status: The pool is formatted using an older on-disk format. The pool can > > still be used, but some features are unavailable. > > action: Upgrade the pool using 'zpool upgrade'. Once this is done, the > > pool will no longer be accessible on older software versions. > > scrub: none requested > > config: > > > > NAME STATE READ WRITE CKSUM > > tank DEGRADED 0 0 0 > > mirror DEGRADED 0 0 0 > > ad4.eli ONLINE 0 0 0 > > 12333765091756463941 REMOVED 0 0 0 was /dev/da0.eli > > > > errors: No known data errors > > > > When imported, there is a constant "tasting" of all devices in the system, > > which also makes the floppy drive go spinning constantly, which is really > > annoying. It did not do this with the old ZFS, are there any remedies? > > > > gstat(8) is displaying the following every other second, together with a > > spinning fd0 drive. > > > > dT: 1.010s w: 1.000s filter: ^...$ > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > > 0 0 0 0 0.0 0 0 0.0 0.0| fd0 > > 0 8 8 1014 0.1 0 0 0.0 0.1| md0 > > 0 32 32 4055 9.2 0 0 0.0 29.2| ad0 > > 0 77 10 1267 7.1 63 1125 2.3 31.8| ad4 > > > > There is no activity going on, especially md0 is for /tmp, yet it > > constantly tries to read stuff from everywhere. I will now insert the > > second drive and see if ZFS shuts up then ... > > It does, but it also did not start resilvering the second disk: > > root@coyote:~# zpool status > pool: tank > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror ONLINE 0 0 0 > ad4.eli ONLINE 0 0 0 > da0.eli ONLINE 0 0 16 > > errors: No known data errors > > Will now run the scrub and report back in 6-9h. Another datapoint: While the floppy-tasting has stopped, since the mirror sees all devices again, there is some other problem here: root@coyote:/# zpool online tank da0.eli root@coyote:/# zpool status pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Fri Jun 5 10:21:36 2009 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4.eli ONLINE 0 0 0 684K resilvered da0.eli ONLINE 0 0 0 2.20M resilvered errors: No known data errors root@coyote:/# zpool offline tank da0.eli root@coyote:/# zpool status pool: tank state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: resilver completed after 0h0m with 0 errors on Fri Jun 5 10:21:36 2009 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 684K resilvered da0.eli OFFLINE 0 0 0 2.20M resilvered errors: No known data errors root@coyote:/# zpool status pool: tank state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h0m with 0 errors on Fri Jun 5 10:21:36 2009 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 684K resilvered da0.eli OFFLINE 0 339 0 2.20M resilvered errors: No known data errors root@coyote:/# zpool status pool: tank state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: resilver completed after 0h0m with 0 errors on Fri Jun 5 10:21:36 2009 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 684K resilvered da0.eli OFFLINE 0 0 0 2.20M resilvered errors: No known data errors So I ran 'zpool status' thrice after the offline, and the second one reports write errors on the OFFLINE device (WTF?). Running zpool status in a loop, this will constantly show up and then vanish again. I also get constant write requests to the remaining device, even though no applications are accessing it. What the hell is ZFS trying to do here? root@coyote:/# zpool iostat 1 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- tank 883G 48.4G 8 246 56.8K 1.53M tank 883G 48.4G 8 249 55.9K 1.55M tank 883G 48.4G 8 250 55.0K 1.54M tank 883G 48.4G 8 252 54.1K 1.56M tank 883G 48.4G 8 254 53.3K 1.57M tank 883G 48.4G 8 253 52.5K 1.56M tank 883G 48.4G 7 255 51.7K 1.57M ^C Again, WTF? Can someone please enlighten me here? Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 11:28:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D13D106568C; Fri, 5 Jun 2009 11:28:40 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id ACC1F8FC08; Fri, 5 Jun 2009 11:28:39 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so777469ywe.13 for ; Fri, 05 Jun 2009 04:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=FzXyvIzN1WDzft8cZdjZJfWpiNCLue/qrvRYzvN9ie0=; b=kuH+gT7R10PEYlkwQSvyonjpPSo+37ruT/SLrOsy4jTD2XMvItdsuQgk94wYGnkD9h 7cVcZUobi4jy7xZUvH+xTDsuapd6wNmG6BS3Uy0OL/HRwCSnzocQztU2lAnhRbQ9QQx8 8Gmer1jB9q49F1w5P7wqDUhrClLa/JSdyp/zE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=cmIoFK6hgE9gCMiy2TBlNxAqi37/uhCOyVbejjz1jleVbOGwDyTof657YGGskM2zBP ZItZvcvL/d97HhvpFL4UzatankrKI8aATXmF43Pyy6yRBy90BaGoy0IzQyu/esQARnKu 9tH7H7Ejy7f2jhlFP2y4sYw1yaZRF84RuV/HU= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.3.6 with SMTP id 6mr3774681anc.33.1244201319030; Fri, 05 Jun 2009 04:28:39 -0700 (PDT) In-Reply-To: <20090605084423.GA1609@acme.spoerlein.net> References: <20090602091610.GE93344@acme.spoerlein.net> <20090602092408.GF93344@acme.spoerlein.net> <20090605084423.GA1609@acme.spoerlein.net> Date: Fri, 5 Jun 2009 04:28:38 -0700 X-Google-Sender-Auth: dd75ec42a5081d1d Message-ID: <3c1674c90906050428mafb5760gc706e879193345e0@mail.gmail.com> From: Kip Macy To: Kip Macy , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: ZFS weird device tasting loop since MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 11:28:40 -0000 Must be a weird geom interaction. I don't see this with raw disk. I'll look at it eventually but UMA and performance are further up in the queue. -Kip On Fri, Jun 5, 2009 at 1:44 AM, Ulrich Sp=F6rlein wrote: > On Tue, 02.06.2009 at 11:24:08 +0200, Ulrich Sp=F6rlein wrote: >> On Tue, 02.06.2009 at 11:16:10 +0200, Ulrich Sp=F6rlein wrote: >> > Hi all, >> > >> > so I went ahead and updated my ~7.2 file server to the new ZFS goodnes= s, >> > and before running any further tests, I already discovered something >> > weird and annoying. >> > >> > I'm using a mirror on GELI, where one disk is usually *not* attached a= s >> > a means of poor man's backup. (I had to go that route, as send/recv of >> > snapshots frequently deadlocked the system, whereas a mirror scrubbing >> > did not) >> > >> > root@coyote:~# zpool status >> > =A0 pool: tank >> > =A0state: DEGRADED >> > status: The pool is formatted using an older on-disk format. =A0The po= ol can >> > =A0 =A0 =A0 =A0 still be used, but some features are unavailable. >> > action: Upgrade the pool using 'zpool upgrade'. =A0Once this is done, = the >> > =A0 =A0 =A0 =A0 pool will no longer be accessible on older software ve= rsions. >> > =A0scrub: none requested >> > config: >> > >> > =A0 =A0 =A0 =A0 NAME =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0STATE = =A0 =A0 READ WRITE CKSUM >> > =A0 =A0 =A0 =A0 tank =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DEGRAD= ED =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 >> > =A0 =A0 =A0 =A0 =A0 mirror =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DEGRADED= =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 >> > =A0 =A0 =A0 =A0 =A0 =A0 ad4.eli =A0 =A0 =A0 =A0 =A0 =A0 =A0 ONLINE =A0= =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 >> > =A0 =A0 =A0 =A0 =A0 =A0 12333765091756463941 =A0REMOVED =A0 =A0 =A00 = =A0 =A0 0 =A0 =A0 0 =A0was /dev/da0.eli >> > >> > errors: No known data errors >> > >> > When imported, there is a constant "tasting" of all devices in the sys= tem, >> > which also makes the floppy drive go spinning constantly, which is rea= lly >> > annoying. It did not do this with the old ZFS, are there any remedies? >> > >> > gstat(8) is displaying the following every other second, together with= a >> > spinning fd0 drive. >> > >> > dT: 1.010s =A0w: 1.000s =A0filter: ^...$ >> > =A0L(q) =A0ops/s =A0 =A0r/s =A0 kBps =A0 ms/r =A0 =A0w/s =A0 kBps =A0 = ms/w =A0 %busy Name >> > =A0 =A0 0 =A0 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A00 =A0 =A00.0 =A0 =A0 = =A00 =A0 =A0 =A00 =A0 =A00.0 =A0 =A00.0| fd0 >> > =A0 =A0 0 =A0 =A0 =A08 =A0 =A0 =A08 =A0 1014 =A0 =A00.1 =A0 =A0 =A00 = =A0 =A0 =A00 =A0 =A00.0 =A0 =A00.1| md0 >> > =A0 =A0 0 =A0 =A0 32 =A0 =A0 32 =A0 4055 =A0 =A09.2 =A0 =A0 =A00 =A0 = =A0 =A00 =A0 =A00.0 =A0 29.2| ad0 >> > =A0 =A0 0 =A0 =A0 77 =A0 =A0 10 =A0 1267 =A0 =A07.1 =A0 =A0 63 =A0 112= 5 =A0 =A02.3 =A0 31.8| ad4 >> > >> > There is no activity going on, especially md0 is for /tmp, yet it >> > constantly tries to read stuff from everywhere. I will now insert the >> > second drive and see if ZFS shuts up then ... >> >> It does, but it also did not start resilvering the second disk: >> >> root@coyote:~# zpool status >> =A0 pool: tank >> =A0state: ONLINE >> status: One or more devices has experienced an unrecoverable error. =A0A= n >> =A0 =A0 =A0 =A0 attempt was made to correct the error. =A0Applications a= re unaffected. >> action: Determine if the device needs to be replaced, and clear the erro= rs >> =A0 =A0 =A0 =A0 using 'zpool clear' or replace the device with 'zpool re= place'. >> =A0 =A0see: http://www.sun.com/msg/ZFS-8000-9P >> =A0scrub: none requested >> config: >> >> =A0 =A0 =A0 =A0 NAME =A0 =A0 =A0 =A0 STATE =A0 =A0 READ WRITE CKSUM >> =A0 =A0 =A0 =A0 tank =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 mirror =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 =A0 ad4.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 =A0 da0.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A016 >> >> errors: No known data errors >> >> Will now run the scrub and report back in 6-9h. > > Another datapoint: While the floppy-tasting has stopped, since the mirror= sees > all devices again, there is some other problem here: > > root@coyote:/# zpool online tank da0.eli > root@coyote:/# zpool status > =A0pool: tank > =A0state: ONLINE > =A0scrub: resilver completed after 0h0m with 0 errors on Fri Jun =A05 10:= 21:36 2009 > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0 STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0tank =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 > =A0 =A0 =A0 =A0 =A0mirror =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 > =A0 =A0 =A0 =A0 =A0 =A0ad4.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 =A0684K resilvered > =A0 =A0 =A0 =A0 =A0 =A0da0.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 =A02.20M resilvered > > errors: No known data errors > root@coyote:/# zpool offline tank da0.eli > root@coyote:/# zpool status > =A0pool: tank > =A0state: DEGRADED > status: One or more devices has been taken offline by the administrator. > =A0 =A0 =A0 =A0Sufficient replicas exist for the pool to continue functio= ning in a > =A0 =A0 =A0 =A0degraded state. > action: Online the device using 'zpool online' or replace the device with > =A0 =A0 =A0 =A0'zpool replace'. > =A0scrub: resilver completed after 0h0m with 0 errors on Fri Jun =A05 10:= 21:36 2009 > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0 STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0tank =A0 =A0 =A0 =A0 DEGRADED =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 > =A0 =A0 =A0 =A0 =A0mirror =A0 =A0 DEGRADED =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0ad4.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 =A0684K resilvered > =A0 =A0 =A0 =A0 =A0 =A0da0.eli =A0OFFLINE =A0 =A0 =A00 =A0 =A0 0 =A0 =A0 = 0 =A02.20M resilvered > > errors: No known data errors > root@coyote:/# zpool status > =A0pool: tank > =A0state: DEGRADED > status: One or more devices has experienced an unrecoverable error. =A0An > =A0 =A0 =A0 =A0attempt was made to correct the error. =A0Applications are= unaffected. > action: Determine if the device needs to be replaced, and clear the error= s > =A0 =A0 =A0 =A0using 'zpool clear' or replace the device with 'zpool repl= ace'. > =A0 see: http://www.sun.com/msg/ZFS-8000-9P > =A0scrub: resilver completed after 0h0m with 0 errors on Fri Jun =A05 10:= 21:36 2009 > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0 STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0tank =A0 =A0 =A0 =A0 DEGRADED =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 > =A0 =A0 =A0 =A0 =A0mirror =A0 =A0 DEGRADED =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0ad4.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 =A0684K resilvered > =A0 =A0 =A0 =A0 =A0 =A0da0.eli =A0OFFLINE =A0 =A0 =A00 =A0 339 =A0 =A0 0 = =A02.20M resilvered > > errors: No known data errors > root@coyote:/# zpool status > =A0pool: tank > =A0state: DEGRADED > status: One or more devices has been taken offline by the administrator. > =A0 =A0 =A0 =A0Sufficient replicas exist for the pool to continue functio= ning in a > =A0 =A0 =A0 =A0degraded state. > action: Online the device using 'zpool online' or replace the device with > =A0 =A0 =A0 =A0'zpool replace'. > =A0scrub: resilver completed after 0h0m with 0 errors on Fri Jun =A05 10:= 21:36 2009 > config: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0 STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0tank =A0 =A0 =A0 =A0 DEGRADED =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 > =A0 =A0 =A0 =A0 =A0mirror =A0 =A0 DEGRADED =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0ad4.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 = 0 =A0684K resilvered > =A0 =A0 =A0 =A0 =A0 =A0da0.eli =A0OFFLINE =A0 =A0 =A00 =A0 =A0 0 =A0 =A0 = 0 =A02.20M resilvered > > errors: No known data errors > > > So I ran 'zpool status' thrice after the offline, and the second one repo= rts > write errors on the OFFLINE device (WTF?). Running zpool status in a loop= , this > will constantly show up and then vanish again. > > I also get constant write requests to the remaining device, even though n= o > applications are accessing it. What the hell is ZFS trying to do here? > > root@coyote:/# zpool iostat 1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 capacity =A0 =A0 operations =A0 =A0bandwidth > pool =A0 =A0 =A0 =A0 used =A0avail =A0 read =A0write =A0 read =A0write > ---------- =A0----- =A0----- =A0----- =A0----- =A0----- =A0----- > tank =A0 =A0 =A0 =A0 883G =A048.4G =A0 =A0 =A08 =A0 =A0246 =A056.8K =A01.= 53M > tank =A0 =A0 =A0 =A0 883G =A048.4G =A0 =A0 =A08 =A0 =A0249 =A055.9K =A01.= 55M > tank =A0 =A0 =A0 =A0 883G =A048.4G =A0 =A0 =A08 =A0 =A0250 =A055.0K =A01.= 54M > tank =A0 =A0 =A0 =A0 883G =A048.4G =A0 =A0 =A08 =A0 =A0252 =A054.1K =A01.= 56M > tank =A0 =A0 =A0 =A0 883G =A048.4G =A0 =A0 =A08 =A0 =A0254 =A053.3K =A01.= 57M > tank =A0 =A0 =A0 =A0 883G =A048.4G =A0 =A0 =A08 =A0 =A0253 =A052.5K =A01.= 56M > tank =A0 =A0 =A0 =A0 883G =A048.4G =A0 =A0 =A07 =A0 =A0255 =A051.7K =A01.= 57M > ^C > > Again, WTF? Can someone please enlighten me here? > > Cheers, > Ulrich Sp=F6rlein > -- > http://www.dubistterrorist.de/ > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 11:40:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C194106564A for ; Fri, 5 Jun 2009 11:40:14 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 280F28FC1F for ; Fri, 5 Jun 2009 11:40:14 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so781334ana.13 for ; Fri, 05 Jun 2009 04:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=LP4jlVXSQ/7EOdZVFUimyIzCoV32+40mbIoa/bzpfvE=; b=VZYWceEdHKHLt9A0ped/Htj/W9xsTYFvBoFiXlyhpuH+I4ar1JlhW8W2eQwwa05KzS ptqjsuJBNMKzedj3X2toKh7tcJgj9h92oIe3r82AH88Y9HU/O0XDCbhCaum23RnICrUo 9XI0g6cCZgdjTd0dU29vtnEalQb0OCFOfRvSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Oj2tMv2y0xWD/ZydVdli9U1QgsE5UYiJNEGLTgYpLpo0pSZKcoZwXKXvG/RfzQoOmk +xtfi3UWNZCdf8GaTN5/sjrsC/qBcmjh43kbxSSlcXwNz3CIQKroUkxRAbR0hjAHLCHR SGM9adaic/AW4d9RYejPs6pBfd7b4pqrlfD9c= MIME-Version: 1.0 Received: by 10.100.205.15 with SMTP id c15mr3858458ang.5.1244202013560; Fri, 05 Jun 2009 04:40:13 -0700 (PDT) Date: Fri, 5 Jun 2009 14:40:13 +0300 Message-ID: From: Dan Naumov To: kmacy@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: sponsoring ZFS development on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 11:40:14 -0000 Hello Kip, since your name comes up wherever I look about ZFS development on FreeBSD, I thought to send this mail to you directly as well. My question is concerning sponsoring the FreeBSD project and ZFS development in particular. I know I am just a relatively poor person so I can't contribute much (maybe on the order of 20-30 euro a month), but I keep seeing FreeBSD core team members keep mentioning "we value donations of all sizes", so what the hell :) Anyways, in the past I have directed my donations to The FreeBSD Foundation, if I want to ensure that as much of my money as possible goes directly to benefit the development of ZFS support on FreeBSD, should I continue donating to the foundation or should I be sending donations directly to specific developers? Thank you - Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 11:44:43 2009 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 10395106566B for ; Fri, 5 Jun 2009 11:44:43 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id C81968FC15 for ; Fri, 5 Jun 2009 11:44:42 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 5A3FD153468 for ; Fri, 5 Jun 2009 13:27:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPDTI0Yat0Wz; Fri, 5 Jun 2009 13:27:20 +0200 (CEST) Received: from [192.168.2.10] (vaio [192.168.2.10]) by mail.digiware.nl (Postfix) with ESMTP id 953A5153433 for ; Fri, 5 Jun 2009 13:27:20 +0200 (CEST) Message-ID: <4A29011B.9040803@withagen.nl> Date: Fri, 05 Jun 2009 13:27:23 +0200 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ZFS isntall requirements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 11:44:43 -0000 Hi, I'm trying to get my world to 7.2-stable(amd64),but run into: install -o root -g wheel -m 444 kgzldr.o /usr/lib ===> sys/boot/i386/libi386 (install) ===> sys/boot/i386/libfirewire (install) ===> sys/boot/i386/loader (install) make: don't know how to make /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop But the requirement below is NOT in /etc/{make,src}.conf. Even stronger /etc/src.conf has: WITHOUT_ZFS = yes # Put LOADER_ZFS_SUPPORT=yes in /etc/make.conf for ZFS support .if defined(LOADER_ZFS_SUPPORT) CFLAGS+= -DLOADER_ZFS_SUPPORT LIBZFS= ${.OBJDIR}/../../zfs/libzfsboot.a .endif So is this a problem on my side or is there some wrong logic somewhere? --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 14:47:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C607C1065670 for ; Fri, 5 Jun 2009 14:47:05 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 888158FC1B for ; Fri, 5 Jun 2009 14:47:05 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from localhost (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id E305322845 for ; Fri, 5 Jun 2009 09:47:04 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by localhost (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2isftDqzSrW for ; Fri, 5 Jun 2009 09:47:02 -0500 (CDT) Received: from athena.localnet (athena.daycos.com [IPv6:2001:470:c054:1:221:9bff:fe00:de3f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id D44E22283D for ; Fri, 5 Jun 2009 09:47:01 -0500 (CDT) From: Kirk Strauser To: freebsd-stable@freebsd.org Date: Fri, 5 Jun 2009 09:46:59 -0500 User-Agent: KMail/1.11.4 (Linux/2.6.28-11-generic; KDE/4.2.4; x86_64; ; ) References: <4A29011B.9040803@withagen.nl> In-Reply-To: <4A29011B.9040803@withagen.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906050946.59547.kirk@strauser.com> Subject: Re: ZFS isntall requirements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 14:47:06 -0000 On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: > Hi, > > I'm trying to get my world to 7.2-stable(amd64),but run into: > install -o root -g wheel -m 444 kgzldr.o /usr/lib > ===> sys/boot/i386/libi386 (install) > ===> sys/boot/i386/libfirewire (install) > ===> sys/boot/i386/loader (install) > make: don't know how to make > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop ISTR that the build was temporarily broken several days ago. Have you csup'ed your src very recently? -- Kirk Strauser From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 15:29:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81FA0106564A for ; Fri, 5 Jun 2009 15:29:29 +0000 (UTC) (envelope-from dam@sd-13813.dedibox.fr) Received: from sd-13813.dedibox.fr (unknown [IPv6:2a01:e0b:1:78:2e0:f4ff:fe19:e9d2]) by mx1.freebsd.org (Postfix) with ESMTP id 1DB2A8FC18 for ; Fri, 5 Jun 2009 15:29:28 +0000 (UTC) (envelope-from dam@sd-13813.dedibox.fr) Received: from sd-13813.dedibox.fr (localhost [127.0.0.1]) by sd-13813.dedibox.fr (8.14.3/8.14.3) with ESMTP id n55Fjt5j001924 for ; Fri, 5 Jun 2009 17:45:55 +0200 (CEST) (envelope-from dam@sd-13813.dedibox.fr) Received: (from dam@localhost) by sd-13813.dedibox.fr (8.14.3/8.14.3/Submit) id n55FjoQt001923 for freebsd-stable@freebsd.org; Fri, 5 Jun 2009 17:45:50 +0200 (CEST) (envelope-from dam) Date: Fri, 5 Jun 2009 17:45:50 +0200 From: FLEURIOT Damien To: freebsd-stable@freebsd.org Message-ID: <20090605154544.GA1855@sd-13813.dedibox.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: make installworld and securelevel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 15:29:29 -0000 Hello list, I apologize if this issue has been raised already but I couldn't find it anywhere. Find below a snip from my installworld: -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) ===> lib (install) ===> lib/csu/i386-elf (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/lib ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib install -C -o root -g wheel -m 444 libc_p.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib ^C My concern is with the last line which installs libc.so.7 and chflags it. I was running with securelevel 1 and got denied. I had to revert to the old kernel, change my securelevel, reinstall the new 7.2 kernel, then run my installworld. This hasn't caused me any other issue, but what will happen the day the libc.a or libc_p.a which are installed in the early steps of installworld become incompatible with the old kernel (if this is at all possible) ? I wouldn't have been able to boot anymore (this is a remote host). The server has a rescue system, but I think a lot of trouble could be saved by interrupting "make installworld" if we're running above securelevel 0. What do you think list ? Regards, Damien From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 19:24:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 293491065670 for ; Fri, 5 Jun 2009 19:24:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id BBF268FC08 for ; Fri, 5 Jun 2009 19:24:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id E66665C025 for ; Sat, 6 Jun 2009 03:24:30 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 71E2155CDB72; Sat, 6 Jun 2009 03:24:25 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id Cxnj1+L-y2OH; Sat, 6 Jun 2009 03:23:34 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 9656B55CDB6A; Sat, 6 Jun 2009 03:23:27 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=wpWtYTiEhDPjih6fLRaK9DlkDOj80cWu+T/giXAufAW6TgnkSiVPJBb0uRuqpY+ls ocxiY6GsEcK+1lARwEhbA== Message-ID: <4A29709D.6070304@delphij.net> Date: Fri, 05 Jun 2009 12:23:09 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Eric References: <7758B5F61AA742B1B52EB2682F090282@PCdeEricDHEM> In-Reply-To: <7758B5F61AA742B1B52EB2682F090282@PCdeEricDHEM> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: Broadcom NetXtreme II BCM5709 Gigabit Ethernet Dell 610 and Dell X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 19:24:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Redirected from freebsd-drivers] Eric wrote: > Hi, > > Does any one find solution to this problem as we have same, try a proposed patch but still have problem? Could you please try the new version of driver? http://people.freebsd.org/~delphij/misc/193358.tar.bz2 Extract the tarball over your /usr/src This included mii (brgphy) and bce bits and should help. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkopcJwACgkQi+vbBBjt66DZUwCeI7mTWRv/cTij2lB+U74xeGOB sCcAn21UxO/oqjB67N/bF4DfO7blpJ2b =vUC+ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 19:34:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CFBB1065673; Fri, 5 Jun 2009 19:34:12 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id A28688FC1E; Fri, 5 Jun 2009 19:34:11 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 86E5445FA; Fri, 5 Jun 2009 21:34:10 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n55JY6AQ012893; Fri, 5 Jun 2009 21:34:06 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1244230450; bh=k/bOSh4CFJapnw2KVoYdTDmTxjSi5ElYZmxBWr/plqw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=LXFXfn3Rvj+R7ZP8cloF5TzbQWSywL9tygErpjtdTxvLAU4qMBz+WqCG+VvxzT+hS RTlchxN3fcf03TejoRaUw== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:x-scanned-by; b=aMtfvcTtM16kUG3/wXFmw/pON/IztS7eUz8XZ7bmhVNNVX6EVZqKnEjsomUAbrtQm HS2eSr6R2tON8/m8hrxWA== Message-ID: <4A29732E.6090103@restart.be> Date: Fri, 05 Jun 2009 21:34:06 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Kip Macy References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> <4A240E17.30907@egr.msu.edu> <3c1674c90906011515r5f706fdfl570e17a3c90f169f@mail.gmail.com> In-Reply-To: <3c1674c90906011515r5f706fdfl570e17a3c90f169f@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------000607090404040100040306" X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Lorenzo Perone , Mickael MAILLOT , Adam McDougall , FreeBSD Stable Mailing List , Alberto Villa Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 19:34:12 -0000 This is a multi-part message in MIME format. --------------000607090404040100040306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kip Macy wrote: > On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall wrote: >> I'm thinking that too. I spent some time taking stabs at figuring it out >> yesterday but didn't get anywhere useful. I did try compiling the -current >> src/sys/boot tree on 7.2 after a couple header tweaks to make it compile but >> the loader still didn't work. The working loader is the same file size as >> the broken loader unless it was compiled on i386 and then it is ~30k bigger >> for some reason (it shrinks to the same size as the rest if I force it to >> use the same 32bit compilation flags as used on amd64). Just mentioning >> this in case it saves someone else some time. I'm real pleased it works at >> all. > > If someone has the time to track down the differences I'll MFC them. > I'm not using ZFS boot at the moment so I have no way of testing. > At last I get this F.....G diff!!! The problem was in libstand.a. By the way , the patch also take into account the update of Doug Rabson to answer my problem with too many devices / pools. Happy to help on this one. > Cheers, > Kip --------------000607090404040100040306 Content-Type: text/plain; name="lib_libstand.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lib_libstand.patch" --- lib/libstand/stand.h.orig 2007-01-09 02:02:04.000000000 +0100 +++ lib/libstand/stand.h 2009-06-03 17:24:42.627552341 +0200 @@ -167,7 +167,7 @@ #define SOPEN_RASIZE 512 }; -#define SOPEN_MAX 8 +#define SOPEN_MAX 64 extern struct open_file files[]; /* f_flags values */ --- lib/libstand/nfs.c.orig 2004-01-21 21:12:23.000000000 +0100 +++ lib/libstand/nfs.c 2009-06-05 20:36:26.001368421 +0200 @@ -29,7 +29,7 @@ */ #include -__FBSDID("$FreeBSD: src/lib/libstand/nfs.c,v 1.12 2004/01/21 20:12:23 jhb Exp $"); +__FBSDID("$FreeBSD: src/lib/libstand/nfs.c,v 1.14 2008/11/21 09:14:29 luigi Exp $"); #include #include @@ -405,16 +405,23 @@ #ifdef NFS_DEBUG if (debug) - printf("nfs_open: %s (rootpath=%s)\n", path, rootpath); + printf("nfs_open: %s (rootpath=%s)\n", upath, rootpath); #endif if (!rootpath[0]) { printf("no rootpath, no nfs\n"); return (ENXIO); } + /* + * This is silly - we should look at dv_type but that value is + * arch dependant and we can't use it here. + */ #ifndef __i386__ if (strcmp(f->f_dev->dv_name, "net") != 0) return(EINVAL); +#else + if (strcmp(f->f_dev->dv_name, "pxe") != 0) + return(EINVAL); #endif if (!(desc = socktodesc(*(int *)(f->f_devdata)))) --------------000607090404040100040306-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 21:53:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A100C106566B; Fri, 5 Jun 2009 21:53:02 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD418FC14; Fri, 5 Jun 2009 21:53:02 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id BBBC771F6D0; Fri, 5 Jun 2009 17:53:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJVCKMT+tjE3; Fri, 5 Jun 2009 17:53:01 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id 9884671F6BA; Fri, 5 Jun 2009 17:53:01 -0400 (EDT) Message-ID: <4A2993BD.7030600@egr.msu.edu> Date: Fri, 05 Jun 2009 17:53:01 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 To: Henri Hennebert References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> <4A240E17.30907@egr.msu.edu> <3c1674c90906011515r5f706fdfl570e17a3c90f169f@mail.gmail.com> <4A29732E.6090103@restart.be> In-Reply-To: <4A29732E.6090103@restart.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List , Kip Macy Subject: Re: ZFS booting without partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 21:53:02 -0000 Henri Hennebert wrote: > Kip Macy wrote: >> On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall >> wrote: >>> I'm thinking that too. I spent some time taking stabs at figuring >>> it out >>> yesterday but didn't get anywhere useful. I did try compiling the >>> -current >>> src/sys/boot tree on 7.2 after a couple header tweaks to make it >>> compile but >>> the loader still didn't work. The working loader is the same file >>> size as >>> the broken loader unless it was compiled on i386 and then it is ~30k >>> bigger >>> for some reason (it shrinks to the same size as the rest if I force >>> it to >>> use the same 32bit compilation flags as used on amd64). Just >>> mentioning >>> this in case it saves someone else some time. I'm real pleased it >>> works at >>> all. >> >> If someone has the time to track down the differences I'll MFC them. >> I'm not using ZFS boot at the moment so I have no way of testing. >> > At last I get this F.....G diff!!! > > The problem was in libstand.a. By the way , the patch also take into > account the update of Doug Rabson to answer my problem with too many > devices / pools. > > Happy to help on this one. > I can confirm that this fixes my loader when I patch, compile, install libstand then compile and install the loader. Thanks for finding it! From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 22:35:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A90071065687 for ; Fri, 5 Jun 2009 22:35:12 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 677FB8FC15 for ; Fri, 5 Jun 2009 22:35:12 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 0605F1900F; Fri, 5 Jun 2009 22:35:11 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 5 Jun 2009 22:35:10 +0000 (GMT) Date: Fri, 5 Jun 2009 23:35:07 +0100 From: Bruce Cran To: FLEURIOT Damien Message-ID: <20090605233507.42ee1c96@gluon.draftnet> In-Reply-To: <20090605154544.GA1855@sd-13813.dedibox.fr> References: <20090605154544.GA1855@sd-13813.dedibox.fr> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: make installworld and securelevel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 22:35:12 -0000 On Fri, 5 Jun 2009 17:45:50 +0200 FLEURIOT Damien wrote: >=20 > Hello list, >=20 >=20 > I apologize if this issue has been raised already but I couldn't > find it anywhere. >=20 >=20 > Find below a snip from my installworld: >=20 > -------------------------------------------------------------- > >>> Installing everything > -------------------------------------------------------------- > cd /usr/src; make -f Makefile.inc1 install > =3D=3D=3D> share/info (install) > =3D=3D=3D> lib (install) > =3D=3D=3D> lib/csu/i386-elf (install) > install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o > /usr/lib > =3D=3D=3D> lib/libc (install) > install -C -o root -g wheel -m 444 libc.a /usr/lib > install -C -o root -g wheel -m 444 libc_p.a /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > ^C >=20 >=20 > My concern is with the last line which installs libc.so.7 and > chflags it. >=20 > I was running with securelevel 1 and got denied. > I had to revert to the old kernel, change my securelevel, reinstall > the new 7.2 kernel, then run my installworld. >=20 > This hasn't caused me any other issue, but what will happen the day > the libc.a or libc_p.a which are installed in the early steps of > installworld become incompatible with the old kernel (if this is at > all possible) ? >=20 > I wouldn't have been able to boot anymore (this is a remote host). > The server has a rescue system, but I think a lot of trouble could > be saved by interrupting "make installworld" if we're running above > securelevel 0. Although it's often safe to run installworld in multi user mode, it's recommended to run it in single user mode to avoid issues like this. =46rom /usr/src/UPDATING: make buildworld make kernel KERNCONF=3DYOUR_KERNEL_HERE [1] [3] mergemaster -p [5] make installworld make delete-old mergemaster [4] --=20 Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 23:08:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6031065675 for ; Fri, 5 Jun 2009 23:08:02 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id B41D78FC15 for ; Fri, 5 Jun 2009 23:08:02 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: (qmail 403 invoked from network); 5 Jun 2009 22:41:21 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Jun 2009 22:41:20 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.6]) by be-well.ilk.org (Postfix) with ESMTP id 9D93B5083A; Fri, 5 Jun 2009 18:41:14 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 0543D1CC83; Fri, 5 Jun 2009 18:41:13 -0400 (EDT) To: Bruce Cran References: <20090605154544.GA1855@sd-13813.dedibox.fr> <20090605233507.42ee1c96@gluon.draftnet> From: Lowell Gilbert Date: Fri, 05 Jun 2009 18:41:13 -0400 In-Reply-To: <20090605233507.42ee1c96@gluon.draftnet> (Bruce Cran's message of "Fri\, 5 Jun 2009 23\:35\:07 +0100") Message-ID: <44prdimhh2.fsf@lowell-desk.lan> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FLEURIOT Damien , freebsd-stable@freebsd.org Subject: Re: make installworld and securelevel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 23:08:03 -0000 Bruce Cran writes: > On Fri, 5 Jun 2009 17:45:50 +0200 > FLEURIOT Damien wrote: > >> >> Hello list, >> >> >> I apologize if this issue has been raised already but I couldn't >> find it anywhere. >> >> >> Find below a snip from my installworld: >> >> -------------------------------------------------------------- >> >>> Installing everything >> -------------------------------------------------------------- >> cd /usr/src; make -f Makefile.inc1 install >> ===> share/info (install) >> ===> lib (install) >> ===> lib/csu/i386-elf (install) >> install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o >> /usr/lib >> ===> lib/libc (install) >> install -C -o root -g wheel -m 444 libc.a /usr/lib >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >> ^C >> >> >> My concern is with the last line which installs libc.so.7 and >> chflags it. >> >> I was running with securelevel 1 and got denied. >> I had to revert to the old kernel, change my securelevel, reinstall >> the new 7.2 kernel, then run my installworld. >> >> This hasn't caused me any other issue, but what will happen the day >> the libc.a or libc_p.a which are installed in the early steps of >> installworld become incompatible with the old kernel (if this is at >> all possible) ? >> >> I wouldn't have been able to boot anymore (this is a remote host). >> The server has a rescue system, but I think a lot of trouble could >> be saved by interrupting "make installworld" if we're running above >> securelevel 0. > > Although it's often safe to run installworld in multi user mode, it's > recommended to run it in single user mode to avoid issues like this. > From /usr/src/UPDATING: > > > make buildworld > make kernel KERNCONF=YOUR_KERNEL_HERE > [1] > [3] > mergemaster -p [5] > make installworld > make delete-old > mergemaster [4] > Still, I don't really see any obvious downsides to the suggestion. Maybe it could cause problems with jail updates? That's the only issue I've been able to think of... From owner-freebsd-stable@FreeBSD.ORG Fri Jun 5 23:39:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE931065672 for ; Fri, 5 Jun 2009 23:39:11 +0000 (UTC) (envelope-from dam@sd-13813.dedibox.fr) Received: from sd-13813.dedibox.fr (unknown [IPv6:2a01:e0b:1:78:2e0:f4ff:fe19:e9d2]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7C28FC14 for ; Fri, 5 Jun 2009 23:39:10 +0000 (UTC) (envelope-from dam@sd-13813.dedibox.fr) Received: from sd-13813.dedibox.fr (localhost [127.0.0.1]) by sd-13813.dedibox.fr (8.14.3/8.14.3) with ESMTP id n55Nd99Z009115 for ; Sat, 6 Jun 2009 01:39:09 +0200 (CEST) (envelope-from dam@sd-13813.dedibox.fr) Received: (from dam@localhost) by sd-13813.dedibox.fr (8.14.3/8.14.3/Submit) id n55Nd4G8009114 for freebsd-stable@freebsd.org; Sat, 6 Jun 2009 01:39:04 +0200 (CEST) (envelope-from dam) Date: Sat, 6 Jun 2009 01:39:04 +0200 From: FLEURIOT Damien To: freebsd-stable@freebsd.org Message-ID: <20090605233903.GA8984@sd-13813.dedibox.fr> References: <20090605154544.GA1855@sd-13813.dedibox.fr> <20090605233507.42ee1c96@gluon.draftnet> <44prdimhh2.fsf@lowell-desk.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44prdimhh2.fsf@lowell-desk.lan> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: make installworld and securelevel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2009 23:39:11 -0000 On Fri, Jun 05, 2009 at 06:41:13PM -0400 or thereabouts, Lowell Gilbert wrote: > Bruce Cran writes: > > > On Fri, 5 Jun 2009 17:45:50 +0200 > > FLEURIOT Damien wrote: > > > >> > >> Hello list, > >> > >> > >> I apologize if this issue has been raised already but I couldn't > >> find it anywhere. > >> > >> > >> Find below a snip from my installworld: > >> > >> -------------------------------------------------------------- > >> >>> Installing everything > >> -------------------------------------------------------------- > >> cd /usr/src; make -f Makefile.inc1 install > >> ===> share/info (install) > >> ===> lib (install) > >> ===> lib/csu/i386-elf (install) > >> install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o > >> /usr/lib > >> ===> lib/libc (install) > >> install -C -o root -g wheel -m 444 libc.a /usr/lib > >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib > >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > >> ^C > >> > >> > >> My concern is with the last line which installs libc.so.7 and > >> chflags it. > >> > >> I was running with securelevel 1 and got denied. > >> I had to revert to the old kernel, change my securelevel, reinstall > >> the new 7.2 kernel, then run my installworld. > >> > >> This hasn't caused me any other issue, but what will happen the day > >> the libc.a or libc_p.a which are installed in the early steps of > >> installworld become incompatible with the old kernel (if this is at > >> all possible) ? > >> > >> I wouldn't have been able to boot anymore (this is a remote host). > >> The server has a rescue system, but I think a lot of trouble could > >> be saved by interrupting "make installworld" if we're running above > >> securelevel 0. > > > > Although it's often safe to run installworld in multi user mode, it's > > recommended to run it in single user mode to avoid issues like this. > > From /usr/src/UPDATING: > > > > > > make buildworld > > make kernel KERNCONF=YOUR_KERNEL_HERE > > [1] > > [3] > > mergemaster -p [5] > > make installworld > > make delete-old > > mergemaster [4] > > > > Still, I don't really see any obvious downsides to the suggestion. > Maybe it could cause problems with jail updates? That's the only > issue I've been able to think of... Well, I'm afraid running single user isn't an option for me, hosted server. I've always skipped the single user boot, I just go multi-user and follow the other steps. Never done "make delete-old" though, it's not in the Handbook. Is it really important ? It might be worth adding to the Handbook. Regarding jails, seeing the securelevel can't be lowered, just disable chflag'ing during installworld within one ? -- Damien From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 00:01:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78C941065670 for ; Sat, 6 Jun 2009 00:01:03 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1FAF68FC16 for ; Sat, 6 Jun 2009 00:01:03 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 88AAE1900F; Sat, 6 Jun 2009 00:01:01 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sat, 6 Jun 2009 00:01:01 +0000 (GMT) Date: Sat, 6 Jun 2009 01:00:58 +0100 From: Bruce Cran To: freebsd-stable@freebsd.org Message-ID: <20090606010058.2bd884b0@gluon.draftnet> In-Reply-To: <44prdimhh2.fsf@lowell-desk.lan> References: <20090605154544.GA1855@sd-13813.dedibox.fr> <20090605233507.42ee1c96@gluon.draftnet> <44prdimhh2.fsf@lowell-desk.lan> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FLEURIOT Damien , freebsd-stable-local@be-well.ilk.org Subject: Re: make installworld and securelevel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 00:01:03 -0000 On Fri, 05 Jun 2009 18:41:13 -0400 Lowell Gilbert wrote: > Bruce Cran writes: > > > On Fri, 5 Jun 2009 17:45:50 +0200 > > FLEURIOT Damien wrote: > > > >> > >> Hello list, > >> > >> > >> I apologize if this issue has been raised already but I couldn't > >> find it anywhere. > >> > >> > >> Find below a snip from my installworld: > >> > >> -------------------------------------------------------------- > >> >>> Installing everything > >> -------------------------------------------------------------- > >> cd /usr/src; make -f Makefile.inc1 install > >> ===> share/info (install) > >> ===> lib (install) > >> ===> lib/csu/i386-elf (install) > >> install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o > >> /usr/lib > >> ===> lib/libc (install) > >> install -C -o root -g wheel -m 444 libc.a /usr/lib > >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib > >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > >> ^C > >> > >> > >> My concern is with the last line which installs libc.so.7 and > >> chflags it. > >> > >> I was running with securelevel 1 and got denied. > >> I had to revert to the old kernel, change my securelevel, reinstall > >> the new 7.2 kernel, then run my installworld. > >> > >> This hasn't caused me any other issue, but what will happen the day > >> the libc.a or libc_p.a which are installed in the early steps of > >> installworld become incompatible with the old kernel (if this is at > >> all possible) ? > >> > >> I wouldn't have been able to boot anymore (this is a remote host). > >> The server has a rescue system, but I think a lot of trouble could > >> be saved by interrupting "make installworld" if we're running above > >> securelevel 0. > > > > Although it's often safe to run installworld in multi user mode, > > it's recommended to run it in single user mode to avoid issues like > > this. From /usr/src/UPDATING: > > > > > > make buildworld > > make kernel KERNCONF=YOUR_KERNEL_HERE > > [1] > > [3] > > mergemaster -p [5] > > make installworld > > make delete-old > > mergemaster [4] > > > > Still, I don't really see any obvious downsides to the suggestion. > Maybe it could cause problems with jail updates? That's the only > issue I've been able to think of... > If you do both the installkernel and installworld at the same time and the new kernel doesn't boot, then you may not be able to boot with the old kernel because the new userland may be incompatible. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 13:16:12 2009 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 DCF9E106564A for ; Sat, 6 Jun 2009 13:16:12 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0468FC14 for ; Sat, 6 Jun 2009 13:16:12 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz7 with SMTP id 7so6498bwz.43 for ; Sat, 06 Jun 2009 06:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=m0sH4tttKq9G+RNXOIyRrMrNY1G+EgxSDQn5zL72J1g=; b=cahwGNTKJkQd/+q8wMWMGgjTuNC0mq/PQ9LwZvcU1KqZnB7qxRMO3Fd7dI3PrxO0It j5PK3KR1zMHC5D5zqX0vnFnnTIWF79q9k5efXu7uGax9CJ0ww1pdwczqihksjSl/ZVOK tJLqtHYWuqfwm9+6Rn9xXkPNdVYHH7evI/Azw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=nTOpLlkBv9U+p9NhcjS7Mdo9wFDRXCujeMJbnrL/pzggsvVS9MD9/GvWPmmodf9DTs 1DIeFghBzbeoZt1ZO0E6JzNNcsf2BsWAhsG2yf3LVzsld73vZPNnhTuxd9LnxaI7x4PV j4QtMmwIAQkpsm3/s7yy3l8+BO/VpzYFnESho= MIME-Version: 1.0 Received: by 10.204.68.15 with SMTP id t15mr4291771bki.139.1244294171189; Sat, 06 Jun 2009 06:16:11 -0700 (PDT) Date: Sat, 6 Jun 2009 09:16:11 -0400 Message-ID: <4ad871310906060616u7f162f26h8a3149fbe7e4c273@mail.gmail.com> From: Glen Barber To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Kernel Debugging Options X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 13:16:13 -0000 Hello everyone I have a two-part question: I have a minimally customized GENERIC kernel, with the only changes being: options KDB options KDB_UNATTENDED options DDB and 'sysctl debug.debugger_on_panic' shows: debug.debugger_on_panic: 0 However, after a panic loading the vboxdrv.ko module, the machine did not reboot automatically after reboot. Here are my questions: 1) Would enabling DDB in the kernel prevent an automatic reboot after a panic? 2) Does the debugger wait for XX seconds of console inactivity before rebooting? I was under the impression from the handbook that the machine would instantly reboot and after dumping the crash to vmcore0. Is this assumption incorrect? Thanks in advance for any input. -- Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 13:20:58 2009 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 B8409106566C for ; Sat, 6 Jun 2009 13:20:58 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 422E98FC15 for ; Sat, 6 Jun 2009 13:20:57 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz7 with SMTP id 7so8003bwz.43 for ; Sat, 06 Jun 2009 06:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IpYyjpkw1DPJRQ48QDB9kwfAPE0L9EXtjn7cACFd7ns=; b=glvGr2Dmfj9VWupEjU3DMMVeYKyf36pRT+WP1yyuVorMN1/9o+RYAkC1izxq7YvCAA xBHma1GRdjb+QC1UjXOMPopkKT9cEpDYG1hENLwfQ35IAxb6nFH8YUqyrzrxIsX15SuZ ziTdq+OB+H/zXvhENjWEmCSH4ESpLe/WvPlAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Mb2dDaCbAPTC+NcgzY3KcECopwyWGfFDpjg3zIb5MOjoVk2DedaQF0rJ3pJd4xnFuR YHscr11hVApEnnQti63oXJomGbL1gO/CqNcm0H4++TMv+k/DrH0BiadnIIIvm2VV0uod QfzT7ZE+9tH0OXT1TpeVNIpEKY5v2YKxOQZQg= MIME-Version: 1.0 Received: by 10.204.53.10 with SMTP id k10mr4280129bkg.169.1244294457072; Sat, 06 Jun 2009 06:20:57 -0700 (PDT) In-Reply-To: <4ad871310906060616u7f162f26h8a3149fbe7e4c273@mail.gmail.com> References: <4ad871310906060616u7f162f26h8a3149fbe7e4c273@mail.gmail.com> Date: Sat, 6 Jun 2009 09:20:57 -0400 Message-ID: <4ad871310906060620l4ac34881g1ff4946a9bea569@mail.gmail.com> From: Glen Barber To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Kernel Debugging Options X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 13:20:59 -0000 On Sat, Jun 6, 2009 at 9:16 AM, Glen Barber wrote: > Hello everyone > > I have a two-part question: > > I have a minimally customized GENERIC kernel, with the only changes being= : > options =A0 =A0 =A0 =A0 KDB > options =A0 =A0 =A0 =A0 KDB_UNATTENDED > options =A0 =A0 =A0 =A0 DDB > > and 'sysctl debug.debugger_on_panic' shows: > debug.debugger_on_panic: 0 > > However, after a panic loading the vboxdrv.ko module, the machine did > not reboot automatically after reboot. I meant "automatically after panic". It's early, and I am apparently unable to type a coherent thought... > > Here are my questions: > 1) =A0Would enabling DDB in the kernel prevent an automatic reboot after = a panic? > > 2) =A0Does the debugger wait for XX seconds of console inactivity before > rebooting? =A0I was under the impression from the handbook that the > machine would instantly reboot and after dumping the crash to vmcore0. > =A0Is this assumption incorrect? > > Thanks in advance for any input. > Also, if this is helpful, the userland / kernel are from two days ago, r193= 481: FreeBSD orion 7.2-STABLE FreeBSD 7.2-STABLE #0 r193481: Fri Jun 5 01:55:06 EDT 2009 root@orion:/usr/obj/usr/src/sys/ORION i386 --=20 Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 14:33:36 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3409C106566B for ; Sat, 6 Jun 2009 14:33:36 +0000 (UTC) (envelope-from nakaji@jp.freebsd.org) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id ED8248FC16 for ; Sat, 6 Jun 2009 14:33:35 +0000 (UTC) (envelope-from nakaji@jp.freebsd.org) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id n56EXNiA033342 for ; Sat, 6 Jun 2009 23:33:24 +0900 (JST) (envelope-from nakaji@jp.freebsd.org) From: NAKAJI Hiroyuki To: freebsd-stable@FreeBSD.ORG Date: Sat, 06 Jun 2009 23:33:23 +0900 Message-ID: <86d49h300c.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-5.9 required=13.0 tests=AWL,BAYES_00, CONTENT_TYPE_PRESENT,NO_RELAYS,QENCPTR1 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Cc: Subject: Big problem still remains with 7.2-STABLE locking up X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 14:33:36 -0000 Hi, I noticed, some months ago, frequent lockups on my RELENG_6 server with ECS PM800-M2, Celeron 2.6GHz (UP), 2GB ram, ATA HDDs and 3Com NIC(xl0), and then I gave up this old server. Last month, I replaced this 'unstable' server to the new one with 7.2-RELEASE which worked very well until I setup it as 'a server'. The problem began just after it started 'the services'. My story is very similar to Pete's. http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047487.html I followed some instructions in the list thread. But unfortunately, the big problem still remains. 7.2-STABLE server locks up frequently. Help! :-( The server is NEC Express5800 S70/SD. o CPU: Intel(R) Celeron(R) CPU 440 @ 2.00GHz (2280.25-MHz K8-class CPU) o 6GB RAM o ACPI APIC Table: o 80GB and 250GB SATA HDDs o http://www.heimat.gr.jp/~nakaji/localhost/dmesg.boot The kernel configuration is: include GENERIC ident HEIMAT options MSGBUF_SIZE=81920 makeoptions DEBUG=-g options KDB options DDB options BREAK_TO_DEBUGGER options QUOTA options DEVICE_POLLING options HZ=1000 options SW_WATCHDOG options DEBUG_VFS_LOCKS options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options LOCK_PROFILING This server runs as web server, nfs server, dhcp server, ntp server, mail server with spam checks, ML server, usenet server and so on. From /etc/rc.conf*, there are some "_enable" lines as shown below. o ntpdate o ntpd o nfs_server o sshd o inetd o named o sendmail o rtadvd o watchdogd o dhcpd o snmpd o apache22 o samba o zope29 o zope210 o amavisd o amavisd_milter o cvsupd o ntop o compat6x o munin_node o spamd o spamass_milter o smartd o mailman o sshblock o innd o skkserv >From munin's graphs, the 'resets' value in netstat is increasing while on other 'desktops' it remains zero. Though I did not find if there is a threshold of 'resets', when it reaches to 0.8 - 1.2 the server gets "lockup". No ping response, no messages on cosole, no keyboard response, and, of cource, Ctrl-Alt-Esc does not function, when it locks up. I wonder why netstat's reset is increasing. I had learned a workaround from other Japanese guys, that is, enabling ichwd and running watchdogd can reboot the box when it locks up if the box has ICH. Exactly, after about 4 hours, the box rebooted while I was in bed last night. Watchdogd functions very well. Advice? Thanks. -- NAKAJI Hiroyuki From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 14:43:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BF32106564A for ; Sat, 6 Jun 2009 14:43:08 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmpop108.cox.net (fed1rmpop108.cox.net [68.230.241.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3179E8FC1A for ; Sat, 6 Jun 2009 14:43:07 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090606141436.ZQND20430.fed1rmmtao105.cox.net@fed1rmimpo01.cox.net> for ; Sat, 6 Jun 2009 10:14:36 -0400 Received: from vaio ([98.176.33.70]) by fed1rmimpo01.cox.net with bizsmtp id 0eEc1c00C1WnGw203eEcm4; Sat, 06 Jun 2009 10:14:37 -0400 X-VR-Score: -140.00 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=MgEkKS8qx2k2w5gca6MA:9 a=0ZMySGETfU5Hlin10moA:7 a=67NZBWmUkk7u6mNzv3psOHY4y2QA:4 X-CM-Score: 0.00 Date: Sat, 6 Jun 2009 07:14:31 -0700 From: Robert To: freebsd-stable@freebsd.org Message-ID: <20090606071431.092609ce@vaio> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Panic resource_list_alloc 7.2 stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 14:43:08 -0000 Greetings This problem seems the same as this one from May of this year http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html This happens on an older HP laptop. It was running on 7.1 prerelease fine and then I updated to 7.2 Stable yesterday. FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT 2009 root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386 The bits from pciconf atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' class = mass storage subclass = ATA The date of ata-chipset.c -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c The chipset is found in the above file ata_intel_ident(device_t dev) { struct ata_pci_controller *ctlr = device_get_softc(dev); static struct ata_chip_id ids[] = {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, ^^^^^^^ { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, I can include the dump if needed but I am not at this time to shorten the email. But here is the panic. Dump header from device /dev/ad0s1b Architecture: i386 Architecture Version: 2 Dump Length: 68939776B (65 MB) Blocksize: 512 Dumptime: Sat Jun 6 05:40:52 2009 Hostname: hp.shasta204.local Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT 2009 root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA Panic String: resource_list_alloc: resource entry is busy Dump Parity: 3285399556 Bounds: 1 Dump Status: good Any help would be greatly appreciated. Robert From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 14:49:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8571106564A for ; Sat, 6 Jun 2009 14:49:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f214.google.com (mail-bw0-f214.google.com [209.85.218.214]) by mx1.freebsd.org (Postfix) with ESMTP id 408638FC08 for ; Sat, 6 Jun 2009 14:49:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz10 with SMTP id 10so23252bwz.43 for ; Sat, 06 Jun 2009 07:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=PM5aTt3S8y1xeyo8MdfcJE3M11QjLLhcr7KG6SrOk0M=; b=VrF/QMLozaLci5eEaTHoJqze67S45c2Uw7DVhYJcECF624JfrXDKahkYypk4Y8WoY6 bnoB+uUOHpKQ1YknjO+CYSH70berQi0kz/yfxGTABAlz4vPhuACkEVmXc9pVVFiKv36G UnOkF3hgKuIN92buvtOVVymoRBlLPnEp2STxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RTrUXfZcEcnWdevFdv+BHS5s1Tzi15cjOkJTeqx8Sp1GeL3iiX0OPYVo4XQtgdxg+j mXsuxBpjaHRqVOt+iQWUsSlJOKiKkHm3kV1dFnoS3AWwZWV6PoGPdWiHNQCn8LU8SnQ/ ahqLIsG42F0A4hv35rDVxahdm8MQ88y9z05f0= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.103.207 with SMTP id l15mr2676080fao.2.1244299794051; Sat, 06 Jun 2009 07:49:54 -0700 (PDT) In-Reply-To: <86d49h300c.fsf@ra333.heimat.gr.jp> References: <86d49h300c.fsf@ra333.heimat.gr.jp> Date: Sat, 6 Jun 2009 16:49:54 +0200 X-Google-Sender-Auth: 173aead4ae9f08c6 Message-ID: <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> From: Attilio Rao To: NAKAJI Hiroyuki Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Big problem still remains with 7.2-STABLE locking up X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 14:49:57 -0000 2009/6/6 NAKAJI Hiroyuki : > Hi, > > I noticed, some months ago, frequent lockups on my RELENG_6 server with > ECS PM800-M2, Celeron 2.6GHz (UP), 2GB ram, ATA HDDs and 3Com NIC(xl0), > and then I gave up this old server. > > Last month, I replaced this 'unstable' server to the new one with > 7.2-RELEASE which worked very well until I setup it as 'a server'. The > problem began just after it started 'the services'. > > My story is very similar to Pete's. > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047487.htm= l > > I followed some instructions in the list thread. But unfortunately, the > big problem still remains. 7.2-STABLE server locks up frequently. > > Help! :-( > > The server is NEC Express5800 S70/SD. > > o CPU: Intel(R) Celeron(R) CPU 440 @ 2.00GHz (2280.25-MHz K8-class CPU) > o 6GB RAM > o ACPI APIC Table: > o 80GB and 250GB SATA HDDs > o http://www.heimat.gr.jp/~nakaji/localhost/dmesg.boot > > The kernel configuration is: > > include GENERIC > ident =C2=A0 HEIMAT > options MSGBUF_SIZE=3D81920 > makeoptions =C2=A0 =C2=A0 DEBUG=3D-g > options KDB > options DDB > options BREAK_TO_DEBUGGER > options QUOTA Were you unmounting any of the QUOTA'ed filesystems? I'm aware of a possible deadlock between quota and unmount path which is very difficult to trigger though. Anyways, the only one way we have to debug this is getting some help by the user. 1) Drop the option WITNESS_SPIKSPIN (as we would like to debug spinlocks too) and LOCK_PROFILING (in order to create higher contention and kill some barriers) 2) Once you get the deadlock break in the DDB debugger 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads Note that this is a lot of printout so you won't be able of collecting all these informations if not with a serial connection. 4) Dump the content so that we can further look at locks structure states once we identify something useful (ideally, keeping the machine up in DDB for that would be very useful, but often not viable) Let me know. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 14:51:57 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906E6106568C for ; Sat, 6 Jun 2009 14:51:57 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 55FA38FC19 for ; Sat, 6 Jun 2009 14:51:57 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCxFN-000Agn-4q; Sat, 06 Jun 2009 15:51:49 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCxFN-000BzM-3b; Sat, 06 Jun 2009 15:51:49 +0100 To: freebsd-stable@FreeBSD.ORG, nakaji@jp.freebsd.org In-Reply-To: <86d49h300c.fsf@ra333.heimat.gr.jp> Message-Id: From: Pete French Date: Sat, 06 Jun 2009 15:51:49 +0100 Cc: Subject: Re: Big problem still remains with 7.2-STABLE locking up X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 14:51:58 -0000 > My story is very similar to Pete's. > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047487.html My problem, which you link to there, tturrned out to be due to ICMP redirects, and is most definitely fixed in 7.2. So, your problem is not the same as mine, but some of the tips given there may help you ddebug it. > I followed some instructions in the list thread. But unfortunately, the > big problem still remains. 7.2-STABLE server locks up frequently. Are you using the latest STABLE ? I am rolling out the one from a few days ago with the bce fixes, and that works fine. > The kernel configuration is: ... > options BREAK_TO_DEBUGGER When the box locks up, can you actyually break to the debugger ? This is how we eventually tracked down my problem. -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 15:42:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CA2E106566B for ; Sat, 6 Jun 2009 15:42:15 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id 716818FC17 for ; Sat, 6 Jun 2009 15:42:15 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: (qmail 6953 invoked from network); 6 Jun 2009 15:42:15 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Jun 2009 15:42:14 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.6]) by be-well.ilk.org (Postfix) with ESMTP id 3F07850825; Sat, 6 Jun 2009 11:42:08 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 9D32F1CC23; Sat, 6 Jun 2009 11:42:07 -0400 (EDT) To: Bruce Cran References: <20090605154544.GA1855@sd-13813.dedibox.fr> <20090605233507.42ee1c96@gluon.draftnet> <44prdimhh2.fsf@lowell-desk.lan> <20090606010058.2bd884b0@gluon.draftnet> From: Lowell Gilbert Date: Sat, 06 Jun 2009 11:42:07 -0400 In-Reply-To: <20090606010058.2bd884b0@gluon.draftnet> (Bruce Cran's message of "Sat\, 6 Jun 2009 01\:00\:58 +0100") Message-ID: <44d49hbc8g.fsf@lowell-desk.lan> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FLEURIOT Damien , freebsd-stable@freebsd.org Subject: Re: make installworld and securelevel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 15:42:16 -0000 Bruce Cran writes: > On Fri, 05 Jun 2009 18:41:13 -0400 > Lowell Gilbert wrote: > >> Bruce Cran writes: >> >> > On Fri, 5 Jun 2009 17:45:50 +0200 >> > FLEURIOT Damien wrote: >> > >> >> >> >> Hello list, >> >> >> >> >> >> I apologize if this issue has been raised already but I couldn't >> >> find it anywhere. >> >> >> >> >> >> Find below a snip from my installworld: >> >> >> >> -------------------------------------------------------------- >> >> >>> Installing everything >> >> -------------------------------------------------------------- >> >> cd /usr/src; make -f Makefile.inc1 install >> >> ===> share/info (install) >> >> ===> lib (install) >> >> ===> lib/csu/i386-elf (install) >> >> install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o >> >> /usr/lib >> >> ===> lib/libc (install) >> >> install -C -o root -g wheel -m 444 libc.a /usr/lib >> >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >> >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >> >> ^C >> >> >> >> >> >> My concern is with the last line which installs libc.so.7 and >> >> chflags it. >> >> >> >> I was running with securelevel 1 and got denied. >> >> I had to revert to the old kernel, change my securelevel, reinstall >> >> the new 7.2 kernel, then run my installworld. >> >> >> >> This hasn't caused me any other issue, but what will happen the day >> >> the libc.a or libc_p.a which are installed in the early steps of >> >> installworld become incompatible with the old kernel (if this is at >> >> all possible) ? >> >> >> >> I wouldn't have been able to boot anymore (this is a remote host). >> >> The server has a rescue system, but I think a lot of trouble could >> >> be saved by interrupting "make installworld" if we're running above >> >> securelevel 0. >> > >> > Although it's often safe to run installworld in multi user mode, >> > it's recommended to run it in single user mode to avoid issues like >> > this. From /usr/src/UPDATING: >> > >> > >> > make buildworld >> > make kernel KERNCONF=YOUR_KERNEL_HERE >> > [1] >> > [3] >> > mergemaster -p [5] >> > make installworld >> > make delete-old >> > mergemaster [4] >> > >> >> Still, I don't really see any obvious downsides to the suggestion. >> Maybe it could cause problems with jail updates? That's the only >> issue I've been able to think of... >> > > If you do both the installkernel and installworld at the same time and > the new kernel doesn't boot, then you may not be able to boot with the > old kernel because the new userland may be incompatible. The original suggestion wasn't to skip the reboot, but rather to stop the user from doing an installworld under a raised securelevel. I don't consider it important, because the recommended upgrade path is to do the installworld in single-user mode, but by the same token I don't see any real harm. From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 15:53:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C61D21065672 for ; Sat, 6 Jun 2009 15:53:50 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 563468FC17 for ; Sat, 6 Jun 2009 15:53:50 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 4B161512D for ; Sat, 6 Jun 2009 17:53:49 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n56FrkHb078858 for ; Sat, 6 Jun 2009 17:53:46 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1244303628; bh=IVode7uyrUw8qgyJyQhSkrvK8jOf0JGDh4QGav8pzNI=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=1xjjw/lvp22YS7Hi0a8X7NbI9+IIRKeir+SGhIkfd6gqYgbfiuBljb+FDuRS2GGz+ ozqPUAgWgB0L3njwCCNVg== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=xz33pUBuBhOBCXNBBzJ3qcjAn5djHdIwDGAxku1/reUiBTTnzBwXiH2Zjl/K/FGMN ndYZbBjPISG0+Q1qQJUfg== Message-ID: <4A2A910A.5060900@restart.be> Date: Sat, 06 Jun 2009 17:53:46 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Subject: Stable from May 31 - zfs list locked X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 15:53:51 -0000 Hello, I encounter this problem for the second time. The system is working perfectly well but suddenly the command `zfs list' don't work and can't be killed. Here is a procstat of the culprit: [root@morzine ~]# procstat -k 91766 PID TID COMM TDNAME KSTACK 91766 100490 zfs - mi_switch sleepq_switch sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir zap_lookup_norm zap_lookup dsl_prop_get_dd dsl_dataset_get_ref dsl_dataset_hold dmu_objset_open zfs_ioc_objset_stats zfsdev_ioctl devfs_ioctl_f kern_ioctl same thing happen if I try to run `zpool list' un another terminal. Henri From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 16:11:58 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B8D106566C for ; Sat, 6 Jun 2009 16:11:58 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0A05C8FC1B for ; Sat, 6 Jun 2009 16:11:57 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id n56GBmLI063421; Sun, 7 Jun 2009 01:11:49 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: Pete French References: Date: Sun, 07 Jun 2009 01:11:48 +0900 In-Reply-To: (Pete French's message of "Sat, 06 Jun 2009 15:51:49 +0100") Message-ID: <868wk52vgb.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Big problem still remains with 7.2-STABLE locking up X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 16:11:58 -0000 >>>>> In >>>>> Pete French wrote: > > I followed some instructions in the list thread. But unfortunately, the > > big problem still remains. 7.2-STABLE server locks up frequently. > Are you using the latest STABLE ? I am rolling out the one from a few > days ago with the bce fixes, and that works fine. Yes, the kernel was compiled at Sat Jun 6 17:59:50 JST 2009. I did not check the source changes but I need watching how it works. Yesterday's kernel can easily lock up, and ichwd+watchdogd can restart (reset?) the box. > > The kernel configuration is: > ... > > options BREAK_TO_DEBUGGER > When the box locks up, can you actyually break to the debugger ? This is how > we eventually tracked down my problem. No. I have never seen the debugger, Ctrl+Alt+Esc cannot break. And because this box does not have serial port, debugging seems difficult. -- NAKAJI Hiroyuki From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 16:29:00 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 387301065670; Sat, 6 Jun 2009 16:29:00 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id CC4618FC16; Sat, 6 Jun 2009 16:28:59 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id n56GSnuS043358; Sun, 7 Jun 2009 01:28:50 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: Attilio Rao References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> Date: Sun, 07 Jun 2009 01:28:49 +0900 In-Reply-To: <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> (Attilio Rao's message of "Sat, 6 Jun 2009 16:49:54 +0200") Message-ID: <864out2uny.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Big problem still remains with 7.2-STABLE locking up X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 16:29:00 -0000 >>>>> In <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com>=20 >>>>> Attilio Rao wrote: > > The kernel configuration is: > > > > include GENERIC > > ident =A0 HEIMAT > > options MSGBUF_SIZE=3D81920 > > makeoptions =A0 =A0 DEBUG=3D-g > > options KDB > > options DDB > > options BREAK_TO_DEBUGGER > > options QUOTA > Were you unmounting any of the QUOTA'ed filesystems? No. Quota'ed file system is /home which is not easily unmounted. > Anyways, the only one way we have to debug this is getting some help > by the user. > 1) Drop the option WITNESS_SPIKSPIN (as we would like to debug > spinlocks too) and LOCK_PROFILING (in order to create higher > contention and kill some barriers) Removed two lines from KERNCONF. > 2) Once you get the deadlock break in the DDB debugger Hmm. It is the most difficult: the box cannot break in the DDB debugger for now. > 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads > Note that this is a lot of printout so you won't be able of collecting > all these informations if not with a serial connection. The box does not have any serial port. Is there any other way? Is it possible to use dcons(4) for that purpose, if I add firewire PCI board? > 4) Dump the content so that we can further look at locks structure > states once we identify something useful (ideally, keeping the machine > up in DDB for that would be very useful, but often not viable) Thank you for instruction. I'll try. --=20 NAKAJI Hiroyuki From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 16:35:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E718106564A for ; Sat, 6 Jun 2009 16:35:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 578E08FC0C for ; Sat, 6 Jun 2009 16:35:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MCyru-00019V-Md; Sat, 06 Jun 2009 19:35:42 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Henri Hennebert In-reply-to: <4A2A910A.5060900@restart.be> References: <4A2A910A.5060900@restart.be> Comments: In-reply-to Henri Hennebert message dated "Sat, 06 Jun 2009 17:53:46 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Jun 2009 19:35:42 +0300 From: Danny Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: Stable from May 31 - zfs list locked X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 16:35:45 -0000 > Hello, > > I encounter this problem for the second time. The system is working > perfectly well but suddenly the command `zfs list' don't work and can't > be killed. > > Here is a procstat of the culprit: > > [root@morzine ~]# procstat -k 91766 > PID TID COMM TDNAME KSTACK > > 91766 100490 zfs - mi_switch sleepq_switch > sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir > zap_lookup_norm zap_lookup dsl_prop_get_dd dsl_dataset_get_ref > dsl_dataset_hold dmu_objset_open zfs_ioc_objset_stats zfsdev_ioctl > devfs_ioctl_f kern_ioctl > > same thing happen if I try to run `zpool list' un another terminal. > > Henri same here, but with a twist: it used to happen on a 7.1, then after an unpgrade, sometime in April, to 7.2-PRERELEASE, things were ok till today! I was about to blame a resent upgrade of the PERC firmware(a very long shot :-), but now I don't know if upgradeing to 7.2-stable will help. This is a production host, with 12TB serving many nfs clients. danny From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 18:46:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E9BB106566B for ; Sat, 6 Jun 2009 18:46:35 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id D6EA78FC15 for ; Sat, 6 Jun 2009 18:46:34 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n56IkWVV015881; Sat, 6 Jun 2009 22:46:32 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sat, 6 Jun 2009 22:46:32 +0400 (MSD) From: Dmitry Morozovsky To: Kirk Strauser In-Reply-To: <200906050946.59547.kirk@strauser.com> Message-ID: References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Sat, 06 Jun 2009 22:46:32 +0400 (MSD) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS isntall requirements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 18:46:35 -0000 On Fri, 5 Jun 2009, Kirk Strauser wrote: KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: KS> > Hi, KS> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib KS> > ===> sys/boot/i386/libi386 (install) KS> > ===> sys/boot/i386/libfirewire (install) KS> > ===> sys/boot/i386/loader (install) KS> > make: don't know how to make KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop KS> KS> ISTR that the build was temporarily broken several days ago. Well, according to http://tinderbox.freebsd.org/ it does not ;) -- 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 Jun 6 18:58:14 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59B70106567D for ; Sat, 6 Jun 2009 18:58:14 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from mx-2.btshosting.co.uk (mx-2.btshosting.co.uk [87.117.208.79]) by mx1.freebsd.org (Postfix) with ESMTP id 19F318FC2F for ; Sat, 6 Jun 2009 18:58:10 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from [192.168.1.65] (host86-152-238-190.range86-152.btcentralplus.com [86.152.238.190]) (Authenticated sender: bazerka@beardz.net) by mx-2.btshosting.co.uk (Postfix) with ESMTPA id 2DC226E54DA; Sat, 6 Jun 2009 19:40:22 +0100 (BST) Message-ID: <4A2AB80F.1050207@beardz.net> Date: Sat, 06 Jun 2009 19:40:15 +0100 From: Jase Thew User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NAKAJI Hiroyuki References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> <864out2uny.fsf@ra333.heimat.gr.jp> In-Reply-To: <864out2uny.fsf@ra333.heimat.gr.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at mx-2.btshosting.co.uk X-Virus-Status: Clean Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Big problem still remains with 7.2-STABLE locking up X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 18:58:16 -0000 NAKAJI Hiroyuki wrote: >> Note that this is a lot of printout so you won't be able of collecting >> all these informations if not with a serial connection. > > The box does not have any serial port. Is there any other way? Is it > possible to use dcons(4) for that purpose, if I add firewire PCI board? > http://wiki.freebsd.org/DebugWithDcons may be of use to you. Regards, Jase Thew. From owner-freebsd-stable@FreeBSD.ORG Sat Jun 6 19:54:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B7891065689 for ; Sat, 6 Jun 2009 19:54:04 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 8E85C8FC12 for ; Sat, 6 Jun 2009 19:54:03 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 6F8E1552B for ; Sat, 6 Jun 2009 21:54:02 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n56Jrvel083037 for ; Sat, 6 Jun 2009 21:53:58 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1244318041; bh=0xrOMNJU0p3/P+RVu717AQfzZeDWwXxG3k5WyN166RA=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ogxR5UMCOZCVVvHfVnN72GatkPYOMo8pbPcHzV18O4q50QcTToLOTL5C+cUCO/RRx O2+chwI3v2YmTVMAiPL8A== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=pJaQUkR4DgpUHj34FTfyOFOMy8ntF/8FkLI7iD6MwuwoQAOogirKea+y9Cu3qlNqL u4RE9z8p+QTE/ncJfgktA== Message-ID: <4A2AC955.1010902@restart.be> Date: Sat, 06 Jun 2009 21:53:57 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4A2A910A.5060900@restart.be> In-Reply-To: <4A2A910A.5060900@restart.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Subject: Re: Stable from May 31 - zfs list locked X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 19:54:04 -0000 Henri Hennebert wrote: > Hello, > > I encounter this problem for the second time. The system is working > perfectly well but suddenly the command `zfs list' don't work and can't > be killed. > > Here is a procstat of the culprit: > > [root@morzine ~]# procstat -k 91766 > PID TID COMM TDNAME KSTACK > 91766 100490 zfs - mi_switch sleepq_switch > sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir > zap_lookup_norm zap_lookup dsl_prop_get_dd dsl_dataset_get_ref > dsl_dataset_hold dmu_objset_open zfs_ioc_objset_stats zfsdev_ioctl > devfs_ioctl_f kern_ioctl > > same thing happen if I try to run `zpool list' un another terminal. Stangely, zfs snapsot and zfs destroy seems working properly ... I reboot to check this > > Henri > > _______________________________________________ > 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 Jun 6 22:20:32 2009 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 1D4161065675 for ; Sat, 6 Jun 2009 22:20:32 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f214.google.com (mail-fx0-f214.google.com [209.85.220.214]) by mx1.freebsd.org (Postfix) with ESMTP id A18448FC17 for ; Sat, 6 Jun 2009 22:20:31 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by fxm10 with SMTP id 10so297265fxm.43 for ; Sat, 06 Jun 2009 15:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9IJ9IiFT/iI0ynKh0KHrH1Vpk4SLzL2zRKrvLxOiMoc=; b=JOfvyhxLPQGLCuNJX7EIdNguAZJIT+VSLPneXZmDCcP3DgxSTpnVwsAxhQVW15TIn7 BP93RALiBglVNpJafc3VxOZmHFZQcal6OcNl18Cd9fK97tEQMqUqNHxznWdg9M3pgs86 g2NikY2E/iCVyaBDf9QRJx/A4WltKVNVHD9hU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=bT7rQVSzmmxX4BkFHQNBqMx+4WOz1+1n0AmPyWDGmGfdEBqfSk1+qqL7zCGJDiQyFc WxAlnHO6eI0JNoI/og20tHa+PFGbwXjqSt7g/vky7gyAtqNODEy+Vg/mfPfRoc4vXZh4 4VV9LN4DRbCM0wJgUgiFtDyAUnrwn8+KW9Bbc= MIME-Version: 1.0 Received: by 10.204.66.2 with SMTP id l2mr4764003bki.177.1244326830230; Sat, 06 Jun 2009 15:20:30 -0700 (PDT) In-Reply-To: <4ad871310906060620l4ac34881g1ff4946a9bea569@mail.gmail.com> References: <4ad871310906060616u7f162f26h8a3149fbe7e4c273@mail.gmail.com> <4ad871310906060620l4ac34881g1ff4946a9bea569@mail.gmail.com> Date: Sat, 6 Jun 2009 18:20:30 -0400 Message-ID: <4ad871310906061520u11b0dcddt7984c2cd1d41acf0@mail.gmail.com> From: Glen Barber To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Kernel Debugging Options X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2009 22:20:32 -0000 On Sat, Jun 6, 2009 at 9:20 AM, Glen Barber wrote: >> Hello everyone >> >> I have a two-part question: >> >> I have a minimally customized GENERIC kernel, with the only changes bein= g: >> options =A0 =A0 =A0 =A0 KDB >> options =A0 =A0 =A0 =A0 KDB_UNATTENDED >> options =A0 =A0 =A0 =A0 DDB >> >> and 'sysctl debug.debugger_on_panic' shows: >> debug.debugger_on_panic: 0 >> >> However, after a panic loading the vboxdrv.ko module, the machine did >> not reboot automatically after reboot. > > I meant "automatically after panic". =A0It's early, and I am apparently > unable to type a coherent thought... > >> >> Here are my questions: >> 1) =A0Would enabling DDB in the kernel prevent an automatic reboot after= a panic? >> >> 2) =A0Does the debugger wait for XX seconds of console inactivity before >> rebooting? =A0I was under the impression from the handbook that the >> machine would instantly reboot and after dumping the crash to vmcore0. >> =A0Is this assumption incorrect? >> >> Thanks in advance for any input. >> > > Also, if this is helpful, the userland / kernel are from two days ago, r1= 93481: > > FreeBSD orion 7.2-STABLE FreeBSD 7.2-STABLE #0 r193481: Fri Jun =A05 > 01:55:06 EDT 2009 =A0 =A0 root@orion:/usr/obj/usr/src/sys/ORION =A0i386 > Sorry for the noise... Disabling DDB from the kernel corrected the reboot issue. Unless I am misunderstanding how it is worded, it is unclear from the HTML docs that DDB overrides KDB_UNATTENDED. If I am misunderstanding, I apologize, but I'm more curious if I am experiencing unusual behavior with DDB enabled. --=20 Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber