From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 00:45:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15796A8A for ; Sun, 23 Dec 2012 00:45:47 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by mx1.freebsd.org (Postfix) with ESMTP id BDA378FC0C for ; Sun, 23 Dec 2012 00:45:46 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id cr7so4270713qab.16 for ; Sat, 22 Dec 2012 16:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R861vO3pyKrO0DsbDxIMxMf8JpagZcvfzjluk5BWSzk=; b=KisKs0jdQ4kuQcyfZQuWEv7QEMEG5EGghvFEeK+518g+m8ZM3fopefr8CywLYa8x92 6mQItsU9OGHzr9pyvMARUk7MshIj6NermETMUoou8/ivTzs9xVBdqRjpykxgG4F5xNEr +EEL1IwnRgA57acVNJve+vDSNy7rn/oF5t1ylAJ9j/1CVRl/WMt6k7bPlEgGkm4WGec5 ebxrVY+YfJdpCemhFVzYACQoDqu9OfCrc4UdP1DuX39kl4rozjDE19LrW5I1Fn0ZEbCT 1fkxaEjJYzwDW7+EV8C5Wt4PiOCe+RdJjP2k1K/u8+F1A8ESA5PSqTCJjgTEXfXdAAf+ 2n9w== MIME-Version: 1.0 Received: by 10.224.184.143 with SMTP id ck15mr9025148qab.67.1356223539897; Sat, 22 Dec 2012 16:45:39 -0800 (PST) Received: by 10.229.78.96 with HTTP; Sat, 22 Dec 2012 16:45:39 -0800 (PST) In-Reply-To: <50D644E5.9070801@martenvijn.nl> References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> Date: Sun, 23 Dec 2012 03:45:39 +0300 Message-ID: Subject: Re: 9.1 minimal ram requirements From: Sergey Kandaurov To: Marten Vijn , jakub_lach@mailplus.pl Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 00:45:47 -0000 On 23 December 2012 03:40, Marten Vijn wrote: > On 12/23/2012 12:27 AM, Jakub Lach wrote: >> >> Guys, I've heard about some absurd RAM requirements >> for 9.1, has anybody tested it? >> >> e.g. >> >> http://forums.freebsd.org/showthread.php?t=36314 > > > jup, I can comfirm this with nanobsd (cross) compiled > for my soekris net4501 which has 64 MB mem: > > from dmesg: real memory = 67108864 (64 MB) > > while the same config compiled against a 9.0 tree still works... > This (i.e. the "kmem_map too small" message seen with kernel memory shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is quite a big kernel memory consumer. Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. A longer term workaround could be to postpone those memory allocations until the first call to CTL. # cam ctl init allocates roughly 35 MB of kernel memory at once # three memory pools, somewhat under M_DEVBUF, and memory disk # devbuf takes 1022K with kern.cam.ctl.disable=1 Type InUse MemUse HighUse Requests Size(s) devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 ctlmem 5062 10113K - 5062 64,2048 ctlblk 200 800K - 200 4096 ramdisk 1 4096K - 1 ctlpool 532 138K - 532 16,512 -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 06:00:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E285592C for ; Sun, 23 Dec 2012 06:00:24 +0000 (UTC) (envelope-from zoran@uranus.mtveurope.org) Received: from jazz.linuxshell.org (jazz.as199071.net [193.189.137.24]) by mx1.freebsd.org (Postfix) with ESMTP id 987DA8FC15 for ; Sun, 23 Dec 2012 06:00:23 +0000 (UTC) Received: from zoran by jazz.linuxshell.org with local (Exim 4.80) (envelope-from ) id 1TmeIt-0007tQ-48 for freebsd-stable@freebsd.org; Sun, 23 Dec 2012 06:40:51 +0100 Date: Sun, 23 Dec 2012 06:40:50 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: 9.1 minimal ram requirement Message-ID: <20121223054050.GA29845@uranus.mtveurope.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 06:00:24 -0000 > Guys, I've heard about some absurd RAM requirements > for 9.1, has anybody tested it? I prepared old laptop for something else and tried live cd image out. It took some time to load and I was surprised how slowly it went. Laptop has 128 mb or ram and might be a bit old to compare. I removed hdd and dmesg has shown nothing special. Once booted, it often touched cd drive. I didn't pay attention to ctl device. What could happen if it is moved from kernel? Btw, I write this from another account, since freebsd.org made service unavailable: (reason: 550-5.7.1 Service unavailable; client [89.216.2.35] blocked using b +.barracudacentral.org Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 06:22:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 214B0AB1 for ; Sun, 23 Dec 2012 06:22:37 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9608FC13 for ; Sun, 23 Dec 2012 06:22:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id qBN6MODF077928; Sun, 23 Dec 2012 17:22:25 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 23 Dec 2012 17:22:24 +1100 (EST) From: Ian Smith To: Sergey Kandaurov Subject: Re: 9.1 minimal ram requirements In-Reply-To: Message-ID: <20121223150954.B81991@sola.nimnet.asn.au> References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Marten Vijn , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 06:22:37 -0000 On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote: > On 23 December 2012 03:40, Marten Vijn wrote: > > On 12/23/2012 12:27 AM, Jakub Lach wrote: > >> > >> Guys, I've heard about some absurd RAM requirements > >> for 9.1, has anybody tested it? > >> > >> e.g. > >> > >> http://forums.freebsd.org/showthread.php?t=36314 > > > > > > jup, I can comfirm this with nanobsd (cross) compiled > > for my soekris net4501 which has 64 MB mem: > > > > from dmesg: real memory = 67108864 (64 MB) > > > > while the same config compiled against a 9.0 tree still works... Same as the first message in that forum thread, I tried installing from i386 9.1-RC3 memstick on a PIII-M with 128MB RAM (Thinkpad T23) and it panics just a few percent into extracting base.txz, much to my surprise. I had a 256MB stick and was going to try that instead, but was in a bit of a hurry so just added it for 384MB and have had no further trouble, but haven't done anything much with it yet, no X or other packages. However the same forum user 'Zav' later reports the same panic at 2.5d uptime with 320MB, after earlier panics with 192MB post-installation when 'trying to do something', so I'm wondering if even 256MB is enough for 9.1? .. scratch my ambition to upgrade an older maxed-out 160MB laptop that runs fine on 5.5 w/X, KDE and all, albeit using some swap. > This (i.e. the "kmem_map too small" message seen with kernel memory > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > quite a big kernel memory consumer. > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. I've just added that, thanks Sergey, but it's sadly not an option for installation. I guess it's too late for the release notes - which at RC3 made no mention of CAM CTL at all - but it's not yet clear to me whether even 256MB is enough to boot, install and run 9.1 GENERIC? > A longer term workaround could be to postpone those memory allocations > until the first call to CTL. Under what circumstances is CAM CTL needed? What would leaving it out of GENERIC cost, and whom? Is it loadable? dmesg.boot reports loading, but I don't see a module, nor can I find much information about CTL in cam(3|4) or /sys/conf/NOTES. apropos found ctladm and ctlstat, but I'm little the wiser as to when it may be needed, beyond CAM/SCSI debugging? > # cam ctl init allocates roughly 35 MB of kernel memory at once > # three memory pools, somewhat under M_DEVBUF, and memory disk > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > Type InUse MemUse HighUse Requests Size(s) > devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 > ctlmem 5062 10113K - 5062 64,2048 > ctlblk 200 800K - 200 4096 > ramdisk 1 4096K - 1 > ctlpool 532 138K - 532 16,512 > > -- > wbr, > pluknet cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 06:32:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6474EE53; Sun, 23 Dec 2012 06:32:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C08848FC13; Sun, 23 Dec 2012 06:32:14 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so2836500wey.41 for ; Sat, 22 Dec 2012 22:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DaqLI4I0tkW/VQOQcaXwdkFHrK82oLC0T6cAekAf7Ug=; b=VeKXwlzrG5DKWFNFow+Uc1thfBrZmsLqawfmYbV3znGQRTohq+iuL2c1R3AaRscIA0 /SvIj2J+GD0/dBgKWRFG6SPbqpDj75uPux790Zav2lnpDn7iRzCTucfeZzHXJUDclUUu fvs2Ik/TDZW28wJu7CIPJOH3gdKBlciZAeBTAqvZaDXsQ87mtJlFMas/WA628GttXBtV 03wRDEAbvORyMjDGgMwB87OrJQEoqXodn53Q3ycKh/7DPFJBzYPo7w6gW/aG6Wk8aEPS IhtXS9w/Ig7S/ZA4sosgQ0vTlLnlCWvoBjIWpBqGv6jCAxEqIH5350KDR/pEBmvo6Xs8 frtg== MIME-Version: 1.0 Received: by 10.194.93.40 with SMTP id cr8mr30865883wjb.16.1356244327872; Sat, 22 Dec 2012 22:32:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 22 Dec 2012 22:32:07 -0800 (PST) In-Reply-To: References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> Date: Sat, 22 Dec 2012 22:32:07 -0800 X-Google-Sender-Auth: ghsBar_5nEAYnDp3h5p4e58gaBI Message-ID: Subject: Re: 9.1 minimal ram requirements From: Adrian Chadd To: Sergey Kandaurov , ken@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Marten Vijn , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 06:32:15 -0000 Ken, Does CAM CTL really need to pre-allocate 35MB of RAM at startup? Adrian On 22 December 2012 16:45, Sergey Kandaurov wrote: > On 23 December 2012 03:40, Marten Vijn wrote: >> On 12/23/2012 12:27 AM, Jakub Lach wrote: >>> >>> Guys, I've heard about some absurd RAM requirements >>> for 9.1, has anybody tested it? >>> >>> e.g. >>> >>> http://forums.freebsd.org/showthread.php?t=36314 >> >> >> jup, I can comfirm this with nanobsd (cross) compiled >> for my soekris net4501 which has 64 MB mem: >> >> from dmesg: real memory = 67108864 (64 MB) >> >> while the same config compiled against a 9.0 tree still works... >> > > This (i.e. the "kmem_map too small" message seen with kernel memory > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > quite a big kernel memory consumer. > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. > A longer term workaround could be to postpone those memory allocations > until the first call to CTL. > > # cam ctl init allocates roughly 35 MB of kernel memory at once > # three memory pools, somewhat under M_DEVBUF, and memory disk > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > Type InUse MemUse HighUse Requests Size(s) > devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 > ctlmem 5062 10113K - 5062 64,2048 > ctlblk 200 800K - 200 4096 > ramdisk 1 4096K - 1 > ctlpool 532 138K - 532 16,512 > > -- > wbr, > pluknet > _______________________________________________ > 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 Dec 23 06:39:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1650F8E for ; Sun, 23 Dec 2012 06:39:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3B9938FC13 for ; Sun, 23 Dec 2012 06:39:51 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id o1so5828556wic.17 for ; Sat, 22 Dec 2012 22:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hospbQTy7+w/YBqBGYkCPSifZ4d/B4ITkdaD4YDE0ic=; b=WtdjzUKPGldiFHh1ag/7Vyl8yCcjtnKWrwjWrirsDxI2YwjyoME9GdiCNrbLeaLFz9 GVxSCNfmtxmgFZSaCoiinNI6qq+Gfmd2sJnSc/Q9th7KhSpD0BJzI4kjf0QXk7WyZnSw hJPGH9AT/xvEtq55uWZIEKTPMcwFXv7819wIOOiRcNRmn9BciF7lmfRYe/xrRwMdou+4 QObjlwEBO8N9VwNnsY2eY+5AvxoEA5cemqIFEeeATZLBQGo9gXDrzpEHtKvMgR7s/aTx Eo4SqLC8O3uaoMpMHqd+ckOY7EycBUpLqo76dr4FNziETvhW+8RMiIyENHlXO6ztROy/ 5MTw== MIME-Version: 1.0 Received: by 10.180.72.146 with SMTP id d18mr22206626wiv.33.1356244791028; Sat, 22 Dec 2012 22:39:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 22 Dec 2012 22:39:50 -0800 (PST) In-Reply-To: References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> Date: Sat, 22 Dec 2012 22:39:50 -0800 X-Google-Sender-Auth: yz59VUVe-RfdWJlZlMvvYInhy1I Message-ID: Subject: Re: 9.1 minimal ram requirements From: Adrian Chadd To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Cc: Marten Vijn , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 06:39:52 -0000 Hi guys, Would someone please file a PR for this? This is a huge unused allocation of memory for something that honestly likely shouldn't have been included by default in GENERIC. I've cc'ed ken on a reply to this. Hopefully after the holidays he can chime in and figure out what's going on. Maybe just disabling it in GENERIC moving forward is enough - chances are it'll be fine being just a module. Thanks, Adrian On 22 December 2012 16:45, Sergey Kandaurov wrote: > On 23 December 2012 03:40, Marten Vijn wrote: >> On 12/23/2012 12:27 AM, Jakub Lach wrote: >>> >>> Guys, I've heard about some absurd RAM requirements >>> for 9.1, has anybody tested it? >>> >>> e.g. >>> >>> http://forums.freebsd.org/showthread.php?t=36314 >> >> >> jup, I can comfirm this with nanobsd (cross) compiled >> for my soekris net4501 which has 64 MB mem: >> >> from dmesg: real memory = 67108864 (64 MB) >> >> while the same config compiled against a 9.0 tree still works... >> > > This (i.e. the "kmem_map too small" message seen with kernel memory > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > quite a big kernel memory consumer. > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. > A longer term workaround could be to postpone those memory allocations > until the first call to CTL. > > # cam ctl init allocates roughly 35 MB of kernel memory at once > # three memory pools, somewhat under M_DEVBUF, and memory disk > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > Type InUse MemUse HighUse Requests Size(s) > devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 > ctlmem 5062 10113K - 5062 64,2048 > ctlblk 200 800K - 200 4096 > ramdisk 1 4096K - 1 > ctlpool 532 138K - 532 16,512 > > -- > wbr, > pluknet > _______________________________________________ > 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 Dec 23 06:52:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90A7815E for ; Sun, 23 Dec 2012 06:52:17 +0000 (UTC) (envelope-from smkelly@flightaware.com) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by mx1.freebsd.org (Postfix) with ESMTP id 708C68FC12 for ; Sun, 23 Dec 2012 06:52:17 +0000 (UTC) Received: from MBX021-W3-CA-5.exch021.domain.local ([10.254.4.81]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.02.0318.001; Sat, 22 Dec 2012 22:44:04 -0800 From: Sean Kelly To: "freebsd-stable@freebsd.org" Subject: RELENG_9 panic with PERC 6/i (mfi) Thread-Topic: RELENG_9 panic with PERC 6/i (mfi) Thread-Index: Ac3g2LcDw2Pue//oQCOF7Nen9MVYag== Date: Sun, 23 Dec 2012 06:44:05 +0000 Message-ID: <13D4274FB3603545B1811E6390085F3D0C18FD61@MBX021-W3-CA-5.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.13.80.6] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 06:52:17 -0000 Greetings. I have a Dell R710 with a mfi device (PERC 6/i Integrated) that panics almo= st immediately on FreeBSD 9. It works fine on FreeBSD 8.2-RELEASE, but I've= now had it panic in FreeBSD 9.0-STABLE and 9.1-RELEASE. Output of mfiutil show adapter and panic backtrace below. Anybody seen this= or have any ideas? # mfiutil show adapter: mfi0 Adapter: Product Name: PERC 6/i Integrated Serial Number: Firmware: 6.3.1-0003 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 256M Minimum Stripe: 8K Maximum Stripe: 1M # kgdb -n 5 panic: kmem_malloc(-8192): kmem_map too small: 82677760 total allocated cpuid =3D 2 KDB: stack backtrace: #0 0xffffffff809208a6 at kdb_backtrace+0x66 #1 0xffffffff808ea8be at panic+0x1ce #2 0xffffffff80b44930 at vm_map_locked+0 #3 0xffffffff80b3b41a at uma_large_malloc+0x4a #4 0xffffffff808d5a69 at malloc+0xd9 #5 0xffffffff805b2985 at mfi_user_command+0x35 #6 0xffffffff805b2f2d at mfi_ioctl+0x2fd #7 0xffffffff807db28b at devfs_ioctl_f+0x7b #8 0xffffffff80932325 at kern_ioctl+0x115 #9 0xffffffff8093255d at sys_ioctl+0xfd #10 0xffffffff80bd7ae6 at amd64_syscall+0x546 #11 0xffffffff80bc3447 at Xfast_syscall+0xf7 Uptime: 35s Dumping 2032 out of 49122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..= 91% (kgdb) lis *0xffffffff805b2985 0xffffffff805b2985 is in mfi_user_command (/usr/src/sys/dev/mfi/mfi.c:2836)= . 2831 int error =3D 0, locked; 2832 2833 2834 if (ioc->buf_size > 0) { 2835 ioc_buf =3D malloc(ioc->buf_size, M_MFIBUF, M_WAITOK); 2836 if (ioc_buf =3D=3D NULL) { 2837 return (ENOMEM); 2838 } 2839 error =3D copyin(ioc->buf, ioc_buf, ioc->buf_size); 2840 if (error) { From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 07:35:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0532B48C for ; Sun, 23 Dec 2012 07:35:50 +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 9FCB28FC0C for ; Sun, 23 Dec 2012 07:35:49 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Tmg60-000OI3-3Z; Sun, 23 Dec 2012 09:35:40 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Sean Kelly Subject: Re: RELENG_9 panic with PERC 6/i (mfi) In-reply-to: <13D4274FB3603545B1811E6390085F3D0C18FD61@MBX021-W3-CA-5.exch021.domain.local> References: <13D4274FB3603545B1811E6390085F3D0C18FD61@MBX021-W3-CA-5.exch021.domain.local> Comments: In-reply-to Sean Kelly message dated "Sun, 23 Dec 2012 06:44:05 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Dec 2012 09:35:40 +0200 From: Daniel Braniss Message-ID: Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 07:35:50 -0000 > Greetings. > > I have a Dell R710 with a mfi device (PERC 6/i Integrated) that panics almost immediately on FreeBSD 9. It works fine on FreeBSD 8.2-RELEASE, but I've now had it panic in FreeBSD 9.0-STABLE and 9.1-RELEASE. > > Output of mfiutil show adapter and panic backtrace below. Anybody seen this or have any ideas? > > # mfiutil show adapter: > mfi0 Adapter: > Product Name: PERC 6/i Integrated > Serial Number: > Firmware: 6.3.1-0003 > RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 > Battery Backup: present > NVRAM: 32K > Onboard Memory: 256M > Minimum Stripe: 8K > Maximum Stripe: 1M > > # kgdb -n 5 > panic: kmem_malloc(-8192): kmem_map too small: 82677760 total allocated > cpuid = 2 > KDB: stack backtrace: > #0 0xffffffff809208a6 at kdb_backtrace+0x66 > #1 0xffffffff808ea8be at panic+0x1ce > #2 0xffffffff80b44930 at vm_map_locked+0 > #3 0xffffffff80b3b41a at uma_large_malloc+0x4a > #4 0xffffffff808d5a69 at malloc+0xd9 > #5 0xffffffff805b2985 at mfi_user_command+0x35 > #6 0xffffffff805b2f2d at mfi_ioctl+0x2fd > #7 0xffffffff807db28b at devfs_ioctl_f+0x7b > #8 0xffffffff80932325 at kern_ioctl+0x115 > #9 0xffffffff8093255d at sys_ioctl+0xfd > #10 0xffffffff80bd7ae6 at amd64_syscall+0x546 > #11 0xffffffff80bc3447 at Xfast_syscall+0xf7 > Uptime: 35s > Dumping 2032 out of 49122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > (kgdb) lis *0xffffffff805b2985 > 0xffffffff805b2985 is in mfi_user_command (/usr/src/sys/dev/mfi/mfi.c:2836). > 2831 int error = 0, locked; > 2832 > 2833 > 2834 if (ioc->buf_size > 0) { > 2835 ioc_buf = malloc(ioc->buf_size, M_MFIBUF, M_WAITOK); > 2836 if (ioc_buf == NULL) { > 2837 return (ENOMEM); > 2838 } > 2839 error = copyin(ioc->buf, ioc_buf, ioc->buf_size); > 2840 if (error) { > I just upgraded such a box to 9.1-PRERELEASE, can you tell me how to panicit, because so far all seems ok: store-02> uname -aFreeBSD store-02 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #27: Fri Dec 21 09:11:51 IST 2012 danny@rnd:/home/obj/rnd/r+d/stable/9/sys/HUJI amd64 store-02> mfiutil -u 1 show adapter mfi1 Adapter: Product Name: PERC 6/E Adapter Serial Number: 1122334455667788 Firmware: 6.3.1-0003 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8k Maximum Stripe: 1M store-02> gpart show => 34 29297213373 mfid0 GPT (13T) 34 128 1 freebsd-boot (64k) 162 4194304 2 freebsd-ufs [bootme] (2.0G) 4194466 100663296 3 freebsd-swap (48G) 104857762 29192355645 4 freebsd-zfs (13T) store-02> zpool status pool: h state: ONLINE status: The pool is formatted using a legacy 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 software that does not support feature flags. scan: scrub repaired 0 in 7h21m with 0 errors on Wed Oct 24 22:57:31 2012 config: NAME STATE READ WRITE CKSUM h ONLINE 0 0 0 gptid/1ef2d5a2-daef-11e1-944e-d067e5e8228e ONLINE 0 0 0 errors: No known data errors From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 10:31:48 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12B8D6BF; Sun, 23 Dec 2012 10:31:48 +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 2B8D98FC14; Sun, 23 Dec 2012 10:31:46 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA23609; Sun, 23 Dec 2012 12:31:44 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmiqO-000FQP-JS; Sun, 23 Dec 2012 12:31:44 +0200 Message-ID: <50D6DD90.1070705@FreeBSD.org> Date: Sun, 23 Dec 2012 12:31:44 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: [HEADSUP] zfs root pool mounting References: <50B6598B.20200@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 10:31:48 -0000 on 20/12/2012 00:34 Kimmo Paasiala said the following: > What is the status of the MFC process to 9-STABLE? I'm on 9-STABLE > r244407, should I be able to boot from this ZFS pool without > zpool.cache? I haven't MFC-ed the change as of now. After I eventually MFC it you should be able to boot from any pool from which you can boot now unless you have the condition described in the original message. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 12:21:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 189992A5 for ; Sun, 23 Dec 2012 12:21:31 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by mx1.freebsd.org (Postfix) with ESMTP id BEEE88FC0A for ; Sun, 23 Dec 2012 12:21:30 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id v28so3312171qcm.39 for ; Sun, 23 Dec 2012 04:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MRJaSNBdhiBsl3GRSOIyZLzvF2jSzIoCLMD1AfTQawA=; b=vMeAry3UuLPc2u8k/OGx3SozzanINvBR4drsx/tLNFXaNiAQkokPKNvr4JDB84uSnw xl8FY2PqYYTmWFVNATXhgHul/e/waAAC1GX1jZ9T4XGJvkgC7b1ONwhQNB/YC2o7kaEW WciS4QYusdizX1IDP4D4W+eMsdPHyrzfRhSU42zMZwy96xSKbpCbQ+mI1y7CHaKRRRKX Sm6HXNQmfeBl3ulZMCcpomKHkicx+4K3G+6i9XW1cAd9LHNxfLRAsIbhvp7m8YTLhE/z +iT4HNBKVcQqU9qV6XtBS6Sv8yqaEey969ldx2JqK/kkARQomCW4WxmVdmuRj7D7xmAz JRlg== MIME-Version: 1.0 Received: by 10.49.127.199 with SMTP id ni7mr10933824qeb.17.1356265283744; Sun, 23 Dec 2012 04:21:23 -0800 (PST) Received: by 10.229.78.96 with HTTP; Sun, 23 Dec 2012 04:21:23 -0800 (PST) In-Reply-To: <20121223150954.B81991@sola.nimnet.asn.au> References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> <20121223150954.B81991@sola.nimnet.asn.au> Date: Sun, 23 Dec 2012 15:21:23 +0300 Message-ID: Subject: Re: 9.1 minimal ram requirements From: Sergey Kandaurov To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: Marten Vijn , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 12:21:31 -0000 On 23 December 2012 10:22, Ian Smith wrote: > On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote: > > This (i.e. the "kmem_map too small" message seen with kernel memory > > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > > quite a big kernel memory consumer. > > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. > > I've just added that, thanks Sergey, but it's sadly not an option for > installation. I guess it's too late for the release notes - which at > RC3 made no mention of CAM CTL at all - but it's not yet clear to me > whether even 256MB is enough to boot, install and run 9.1 GENERIC? If you perform clean installation (e.g. from ISO), you can escape to the loader prompt and set the tunable there w/o the need for /boot/loader.conf. I experimented with Vbox and AFAIK 256MB was enough even with CAM CTL. > > A longer term workaround could be to postpone those memory allocations > > until the first call to CTL. > > Under what circumstances is CAM CTL needed? What would leaving it out > of GENERIC cost, and whom? Is it loadable? dmesg.boot reports loading, > but I don't see a module, nor can I find much information about CTL in > cam(3|4) or /sys/conf/NOTES. apropos found ctladm and ctlstat, but I'm > little the wiser as to when it may be needed, beyond CAM/SCSI debugging? The purpose and current status are well documented in the initial commit message (r229997) and the supplied README.ctl.txt. To my modest knowledge, it should be safe to just comment out 'device ctl' in GENERIC. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 12:28:59 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5087C435 for ; Sun, 23 Dec 2012 12:28:59 +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 95DC28FC12 for ; Sun, 23 Dec 2012 12:28:58 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA24135 for ; Sun, 23 Dec 2012 14:28:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tmkfi-000FZM-HY for freebsd-stable@freebsd.org; Sun, 23 Dec 2012 14:28:50 +0200 Message-ID: <50D6F901.7050206@FreeBSD.org> Date: Sun, 23 Dec 2012 14:28:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: [HEADSUP] zfs root pool mounting References: <50B6598B.20200@FreeBSD.org> In-Reply-To: <50B6598B.20200@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 12:28:59 -0000 I have MFCed the following change, so please double-check if you might be affected. Preferably before upgrading :-) on 28/11/2012 20:35 Andriy Gapon said the following: > > Recently some changes were made to how a root pool is opened for root filesystem > mounting. Previously the root pool had to be present in zpool.cache. Now it is > automatically discovered by probing available GEOM providers. > The new scheme is believed to be more flexible. For example, it allows to prepare > a new root pool at one system, then export it and then boot from it on a new > system without doing any extra/magical steps with zpool.cache. It could also be > convenient after zpool split and in some other situations. > > The change was introduced via multiple commits, the latest relevant revision in > head is r243502. The changes are partially MFC-ed, the remaining parts are > scheduled to be MFC-ed soon. > > I have received a report that the change caused a problem with booting on at least > one system. The problem has been identified as an issue in local environment and > has been fixed. Please read on to see if you might be affected when you upgrade, > so that you can avoid any unnecessary surprises. > > You might be affected if you ever had a pool named the same as your current root > pool. And you still have any disks connected to your system that belonged to that > pool (in whole or via some partitions). And that pool was never properly > destroyed using zpool destroy, but merely abandoned (its disks > re-purposed/re-partitioned/reused). > > If all of the above are true, then I recommend that you run 'zdb -l ' for > all suspect disks and their partitions (or just all disks and partitions). If > this command reports at least one valid ZFS label for a disk or a partition that > do not belong to any current pool, then the problem may affect you. > > The best course is to remove the offending labels. > > If you are affected, please follow up to this email. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 12:34:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BE99551; Sun, 23 Dec 2012 12:34:25 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mx1.freebsd.org (Postfix) with ESMTP id E96A88FC0C; Sun, 23 Dec 2012 12:34:24 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm2so3616855wib.4 for ; Sun, 23 Dec 2012 04:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UggCWsIs2m8pF4EIO+Dc8nU5nZaGdeLjZvH5ilCD5m0=; b=O5RJPoopr4ihcFdqTjv2WsoT6yYn8lhRaAUZqXXNLRG5OTOwJRMgI8jj2ZTimfASu5 huAaeSjk/jfbTQcN1ktcJZB20zSWlNW35hxxlJ894E1uEZD3m2wC7lndEzxg98nUNdO0 VmO3yKj04biZt9+QegLmwj1E9iFK4KkWZTfTb4IG02ZJxnaXnKEWL7pECf7qi1ai99D6 NQL7cH/9SpQelcxHX2x/KsWlw7SErZ2d8ljx83J+LQqLNtK5T7cZYZJsqT0Mvk5+1eto /gCORjuYLLFo+yu4QZXHTBzRefmCHmEBYFZKPwyzjArBaWfBV0UT9RcBfVjCibn9Ehom t0qA== MIME-Version: 1.0 Received: by 10.194.23.37 with SMTP id j5mr31542260wjf.28.1356266058160; Sun, 23 Dec 2012 04:34:18 -0800 (PST) Received: by 10.216.172.197 with HTTP; Sun, 23 Dec 2012 04:34:17 -0800 (PST) In-Reply-To: <50D6F901.7050206@FreeBSD.org> References: <50B6598B.20200@FreeBSD.org> <50D6F901.7050206@FreeBSD.org> Date: Sun, 23 Dec 2012 14:34:17 +0200 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Kimmo Paasiala To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 12:34:25 -0000 On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon wrote: > > I have MFCed the following change, so please double-check if you might be > affected. Preferably before upgrading :-) > > on 28/11/2012 20:35 Andriy Gapon said the following: >> >> Recently some changes were made to how a root pool is opened for root filesystem >> mounting. Previously the root pool had to be present in zpool.cache. Now it is >> automatically discovered by probing available GEOM providers. >> The new scheme is believed to be more flexible. For example, it allows to prepare >> a new root pool at one system, then export it and then boot from it on a new >> system without doing any extra/magical steps with zpool.cache. It could also be >> convenient after zpool split and in some other situations. >> >> The change was introduced via multiple commits, the latest relevant revision in >> head is r243502. The changes are partially MFC-ed, the remaining parts are >> scheduled to be MFC-ed soon. >> >> I have received a report that the change caused a problem with booting on at least >> one system. The problem has been identified as an issue in local environment and >> has been fixed. Please read on to see if you might be affected when you upgrade, >> so that you can avoid any unnecessary surprises. >> >> You might be affected if you ever had a pool named the same as your current root >> pool. And you still have any disks connected to your system that belonged to that >> pool (in whole or via some partitions). And that pool was never properly >> destroyed using zpool destroy, but merely abandoned (its disks >> re-purposed/re-partitioned/reused). >> >> If all of the above are true, then I recommend that you run 'zdb -l ' for >> all suspect disks and their partitions (or just all disks and partitions). If >> this command reports at least one valid ZFS label for a disk or a partition that >> do not belong to any current pool, then the problem may affect you. >> >> The best course is to remove the offending labels. >> >> If you are affected, please follow up to this email. > > -- > Andriy Gapon Much appreciated! I have verified that my system is not affected. One question, do I have to rewrite the zfs gpt boot loader (/boot/gptzfsboot) onto the freebsd-boot partition to make use of this change? -Kimmo From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 12:35:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3979564C; Sun, 23 Dec 2012 12:35:13 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8004F8FC18; Sun, 23 Dec 2012 12:35:12 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id jk13so2997120bkc.4 for ; Sun, 23 Dec 2012 04:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=85lGcjuONd9sHhbhlwcxZOQ+z4ncPJd5rLYh4gWo2TE=; b=0VR9wTHBd2q9pRGkEvvgcQXEUsuoSwRDHIiZ/7ZlxCsUs/DT8vrIMQ+jbqZrSU/Y1U xvMVcDRI3Asmm3neSOGfXstpD873IYUMwjkbGV25R41RoBUu0HjywvHWVFbGdIHLXrA5 JFK9zssekUzgUpEaRJISb0D4i8FB/NLYTSbIOrzg0RSQGFWBaNU8OgYnxkjl0iGVvWn/ gQC1elK9SWO1g683yYm/ZOsn+kO/IFCKgFziZ4t1f4a+lOizKJ6JUNHE+A08gd6luNG1 aS6bHxeQZ0nJS8/lsgkh+0LewRkB9ov+ArS7oeyF7h8M0teGYJ9+ZBB5hbdJXkEhR2St TMQg== MIME-Version: 1.0 Received: by 10.204.150.137 with SMTP id y9mr8996290bkv.103.1356266111211; Sun, 23 Dec 2012 04:35:11 -0800 (PST) Received: by 10.204.167.71 with HTTP; Sun, 23 Dec 2012 04:35:11 -0800 (PST) Received: by 10.204.167.71 with HTTP; Sun, 23 Dec 2012 04:35:11 -0800 (PST) In-Reply-To: References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> Date: Sun, 23 Dec 2012 12:35:11 +0000 Message-ID: Subject: Re: 9.1 minimal ram requirements From: Chris Rees To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Marten Vijn , Sergey Kandaurov , FreeBSD , jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 12:35:13 -0000 On 23 Dec 2012 06:40, "Adrian Chadd" wrote: > > Hi guys, > > Would someone please file a PR for this? This is a huge unused > allocation of memory for something that honestly likely shouldn't have > been included by default in GENERIC. > > I've cc'ed ken on a reply to this. Hopefully after the holidays he can > chime in and figure out what's going on. > > Maybe just disabling it in GENERIC moving forward is enough - chances > are it'll be fine being just a module. Oh gods... Please let's just make it an erratum notice at this stage! Chris From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 12:49:05 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53DE3B1F for ; Sun, 23 Dec 2012 12:49:05 +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 7CBE38FC0C for ; Sun, 23 Dec 2012 12:49:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA24209; Sun, 23 Dec 2012 14:49:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmkzF-000Fal-OL; Sun, 23 Dec 2012 14:49:01 +0200 Message-ID: <50D6FDBD.6000401@FreeBSD.org> Date: Sun, 23 Dec 2012 14:49:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: [HEADSUP] zfs root pool mounting References: <50B6598B.20200@FreeBSD.org> <50D6F901.7050206@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 12:49:05 -0000 on 23/12/2012 14:34 Kimmo Paasiala said the following: > On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon wrote: >> >> I have MFCed the following change, so please double-check if you might be >> affected. Preferably before upgrading :-) >> >> on 28/11/2012 20:35 Andriy Gapon said the following: >>> >>> Recently some changes were made to how a root pool is opened for root filesystem >>> mounting. Previously the root pool had to be present in zpool.cache. Now it is >>> automatically discovered by probing available GEOM providers. >>> The new scheme is believed to be more flexible. For example, it allows to prepare >>> a new root pool at one system, then export it and then boot from it on a new >>> system without doing any extra/magical steps with zpool.cache. It could also be >>> convenient after zpool split and in some other situations. >>> >>> The change was introduced via multiple commits, the latest relevant revision in >>> head is r243502. The changes are partially MFC-ed, the remaining parts are >>> scheduled to be MFC-ed soon. >>> >>> I have received a report that the change caused a problem with booting on at least >>> one system. The problem has been identified as an issue in local environment and >>> has been fixed. Please read on to see if you might be affected when you upgrade, >>> so that you can avoid any unnecessary surprises. >>> >>> You might be affected if you ever had a pool named the same as your current root >>> pool. And you still have any disks connected to your system that belonged to that >>> pool (in whole or via some partitions). And that pool was never properly >>> destroyed using zpool destroy, but merely abandoned (its disks >>> re-purposed/re-partitioned/reused). >>> >>> If all of the above are true, then I recommend that you run 'zdb -l ' for >>> all suspect disks and their partitions (or just all disks and partitions). If >>> this command reports at least one valid ZFS label for a disk or a partition that >>> do not belong to any current pool, then the problem may affect you. >>> >>> The best course is to remove the offending labels. >>> >>> If you are affected, please follow up to this email. > > Much appreciated! > > I have verified that my system is not affected. > > One question, do I have to rewrite the zfs gpt boot loader > (/boot/gptzfsboot) onto the freebsd-boot partition to make use of this > change? This change is kernel-level only. There is no interaction with boot blocks. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 13:46:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 452D2BC; Sun, 23 Dec 2012 13:46:40 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8909D8FC0A; Sun, 23 Dec 2012 13:46:39 +0000 (UTC) Received: from [192.168.179.22] (vijn.xs4all.nl [80.101.129.129]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id qBNDk0JY013430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Dec 2012 14:46:01 +0100 (CET) (envelope-from info@martenvijn.nl) Message-ID: <50D70B18.5030307@martenvijn.nl> Date: Sun, 23 Dec 2012 14:46:00 +0100 From: Marten Vijn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Chris Rees Subject: Re: 9.1 minimal ram requirements References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Adrian Chadd , Sergey Kandaurov , FreeBSD , jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 13:46:40 -0000 On 12/23/2012 01:35 PM, Chris Rees wrote: > > On 23 Dec 2012 06:40, "Adrian Chadd" > wrote: > > > > Hi guys, > > > > Would someone please file a PR for this? This is a huge unused > > allocation of memory for something that honestly likely shouldn't have > > been included by default in GENERIC. > > > > I've cc'ed ken on a reply to this. Hopefully after the holidays he can > > chime in and figure out what's going on. > > > > Maybe just disabling it in GENERIC moving forward is enough - chances > > are it'll be fine being just a module. > > Oh gods... Please let's just make it an erratum notice at this stage! not sure if it helps, I 'vw setting up my old test env, while i tmp resolved the issue by using 9.0, i am interested im getting 9.1 working too... The old test moved producion now, so i needed some time to get new flashcards (which requierd new bioses etc etc) and some other minor fidling. For this nanobsd image I used/tested svn revisons => 243710 ~ 244139 Marten Copyright (c) 1992-2012 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 9.1-PRERELEASE #0 r244161: Thu Dec 13 08:46:37 CET 2012 root@brie:/usr/obj/nanobsd.full/i386.i386/usr/src/sys/KERNEL i386 CPU: AMD Am5x86 Write-Back (486-class CPU) Origin = "AuthenticAMD" Id = 0x4f4 Family = 0x4 Model = 0xf Stepping = 4 Features=0x1 real memory = 67108864 (64 MB) avail memory = 46436352 (44 MB) kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xc0dce310, 0) error 19 ctl: CAM Target Layer loaded ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. *** WARNING: missing CPU_ELAN -- timekeeping may be wrong pcib0 pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 17.0 on pci0 pci1: on pcib1 sis0: port 0xd000-0xd0ff mem 0xa4000000-0xa4000fff irq 9 at device 0.0 on pci1 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c7:aa:04 sis1: port 0xd100-0xd1ff mem 0xa4001000-0xa4001fff irq 9 at device 1.0 on pci1 sis1: Silicon Revision: DP83816A miibus1: on sis1 nsphyter1: PHY 0 on miibus1 nsphyter1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c7:aa:05 sis2: port 0xd200-0xd2ff mem 0xa4002000-0xa4002fff irq 9 at device 2.0 on pci1 sis2: Silicon Revision: DP83816A miibus2: on sis2 nsphyter2: PHY 0 on miibus2 nsphyter2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c7:aa:06 sis3: port 0xd300-0xd3ff mem 0xa4003000-0xa4003fff irq 9 at device 3.0 on pci1 sis3: Silicon Revision: DP83816A miibus3: on sis3 nsphyter3: PHY 0 on miibus3 nsphyter3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis3: Ethernet address: 00:00:24:c7:aa:07 sis4: port 0xe000-0xe0ff mem 0xa0000000-0xa0000fff irq 10 at device 18.0 on pci0 sis4: Silicon Revision: DP83815D miibus4: on sis4 nsphyter4: PHY 0 on miibus4 nsphyter4: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis4: Ethernet address: 00:00:24:c1:28:a4 sis5: port 0xe100-0xe1ff mem 0xa0001000-0xa0001fff irq 11 at device 19.0 on pci0 sis5: Silicon Revision: DP83815D miibus5: on sis5 nsphyter5: PHY 0 on miibus5 nsphyter5: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis5: Ethernet address: 00:00:24:c1:28:a5 sis6: port 0xe200-0xe2ff mem 0xa0002000-0xa0002fff irq 5 at device 20.0 on pci0 sis6: Silicon Revision: DP83815D miibus6: on sis6 nsphyter6: PHY 0 on miibus6 nsphyter6: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis6: Ethernet address: 00:00:24:c1:28:a6 cpu0 on motherboard isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 ppc0: parallel port not found. uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 panic: kmem_malloc(4194304): kmem_map too small: 24313856 total allocated cpuid = 0 KDB: stack backtrace: #0 0xc0afcf6f at kdb_backtrace+0x4f #1 0xc0ac972f at panic+0x16f #2 0xc0d3788a at kmem_malloc+0x28a #3 0xc0d2b087 at page_alloc+0x27 #4 0xc0d2d720 at uma_large_malloc+0x50 #5 0xc0ab388c at malloc+0x8c #6 0xc04dceb8 at ctl_backend_ramdisk_init+0x78 #7 0xc04d7f94 at ctl_backend_register+0x104 #8 0xc04dce1b at cbr_modevent+0x2b #9 0xc0ab5ee7 at module_register_init+0x107 #10 0xc0a78c3c at mi_startup+0xac #11 0xc0494a25 at begin+0x2c Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... POST: 012345689bcefghipsajklnopqr,,,tvwxy however adding this to /boot/loader.conf (it was not mentioned in /boot/defaults/loader.conf) kern.cam.ctl.disable=1 get me booting. Copyright (c) 1992-2012 The FreeBSD Project.uU��WVS��} Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994�i�7�� The Regents of the University of California. All rights reserved. P��6HFreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-PRERELEASE #0 r244161: Thu Dec 13 08:46:37 CET 2012 root@brie:/usr/obj/nanobsd.full/i386.i386/usr/src/sys/KERNEL i386 CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin = "AuthenticAMD" Id = 0x494 Family = 0x4 Model = 0x9 Stepping = 4 Features=0x1 real memory = 67108864 (64 MB) avail memory = 46436352 (44 MB) kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xc0dce310, 0) error 19 ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. *** WARNING: missing CPU_ELAN -- timekeeping may be wrong pcib0 pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 17.0 on pci0 pci1: on pcib1 sis0: port 0xd000-0xd0ff mem 0xa4000000-0xa4000fff irq 9 at device 0.0 on pci1 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c7:aa:04 sis1: port 0xd100-0xd1ff mem 0xa4001000-0xa4001fff irq 9 at device 1.0 on pci1 sis1: Silicon Revision: DP83816A miibus1: on sis1 nsphyter1: PHY 0 on miibus1 nsphyter1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c7:aa:05 sis2: port 0xd200-0xd2ff mem 0xa4002000-0xa4002fff irq 9 at device 2.0 on pci1 sis2: Silicon Revision: DP83816A miibus2: on sis2 nsphyter2: PHY 0 on miibus2 nsphyter2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c7:aa:06 sis3: port 0xd300-0xd3ff mem 0xa4003000-0xa4003fff irq 9 at device 3.0 on pci1 sis3: Silicon Revision: DP83816A miibus3: on sis3 nsphyter3: PHY 0 on miibus3 nsphyter3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis3: Ethernet address: 00:00:24:c7:aa:07 sis4: port 0xe000-0xe0ff mem 0xa0000000-0xa0000fff irq 10 at device 18.0 on pci0 sis4: Silicon Revision: DP83815D miibus4: on sis4 nsphyter4: PHY 0 on miibus4 nsphyter4: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis4: Ethernet address: 00:00:24:c1:28:a4 sis5: port 0xe100-0xe1ff mem 0xa0001000-0xa0001fff irq 11 at device 19.0 on pci0 sis5: Silicon Revision: DP83815D miibus5: on sis5 nsphyter5: PHY 0 on miibus5 nsphyter5: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis5: Ethernet address: 00:00:24:c1:28:a5 sis6: port 0xe200-0xe2ff mem 0xa0002000-0xa0002fff irq 5 at device 20.0 on pci0 sis6: Silicon Revision: DP83815D miibus6: on sis6 nsphyter6: PHY 0 on miibus6 nsphyter6: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis6: Ethernet address: 00:00:24:c1:28:a6 cpu0 on motherboard isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 ppc0: parallel port not found. uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 Timecounters tick every 1.000 msec ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: CFA-0 device ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 3815MB (7813120 512 byte sectors: 16H 63S/T 7751C) ada0: Previously was known as ad0 Trying to mount root from ufs:/dev/ad0s1a [ro]... Invalid time in real time clock. Check and reset the date immediately! Setting hostuuid: 8f738d8a-4d05-11e2-9c87-000024c7aa04. Setting hostid: 0xe42da3f7. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 218040 free (2768 frags, 26909 blocks, 0.4% fragmentation) /dev/ad0s3: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3: clean, 2829 free (21 frags, 351 blocks, 0.7% fragmentation) Mounting local file systems:. /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Starting Network: lo0 sis0 sis1 sis2 sis3 sis4 sis5 sis6. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe8sis0: link state changed to DOWN 0::1%lo0 prefixlen 64 scopeid 0x8 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 sis0: flagssis1: link state changed to DOWN =8802 metric 0 mtu 1500 options=83808 ether 0sis2: link state changed to DOWN 0:00:24:c7:aa:04 nd6 options=29 media: Ethernet autoselect (none) status: no carriersis3: link state changed to DOWN sis1: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c7:aa:05 nd6 options=29 media: Ethernet autoselect (none) statusis5: link state changed to DOWN s: no carrier sis2: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c7:aa:06 nd6 options=29 media: Ethernet autoselect (none) status: no carrier sis3: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c7:aa:07 nd6 options=29 media: Ethernet autoselect (none) status: no carrier sis4: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c1:28:a4 nd6 options=29 media: Ethernet autoselect (none) status: no carrier sis5: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c1:28:a5 nd6 options=29 media: Ethernet autoselect (none) status: no carrier sis6: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c1:28:a6 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting devd. Starting Network: sis0. sis0: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c7:aa:04 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting Network: sis1. sis1: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c7:aa:05 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting Network: sis2. sis2: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c7:aa:06 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting Network: sis3. sis3: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c7:aa:07 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting Network: sis4. sis4: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c1:28:a4 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting Network: sis5. sis5: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c1:28:a5 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting Network: sis6. sis6: flags=8802 metric 0 mtu 1500 options=83808 ether 00:00:24:c1:28:a6 nd6 options=29 media: Ethernet autoselect (none) status: no carrier add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Generating host.conf. Creating and/or trimming log files. Starting syslogd. ELF ldconfig path: /lib /usr/lib a.out ldconfig path: ldconfig: /var/run/ld.so.hints: No such file or directory Clearing /tmp (X related). Updating motd:. Starting cron. Starting background file system checks in 60 seconds. Sun Dec 23 13:36:57 UTC 2012 FreeBSD/i386 (Amnesiac) (ttyu0) login: > > Chris > From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 15:23:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 214469E2; Sun, 23 Dec 2012 15:23:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id BC7E28FC19; Sun, 23 Dec 2012 15:23:05 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNFN44p082939; Sun, 23 Dec 2012 15:23:04 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNFN4NT082930; Sun, 23 Dec 2012 15:23:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 15:23:04 GMT Message-Id: <201212231523.qBNFN4NT082930@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 15:23:06 -0000 TB --- 2012-12-23 14:31:53 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 14:31:53 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 14:31:53 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2012-12-23 14:31:53 - cleaning the object tree TB --- 2012-12-23 14:31:53 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 14:31:53 - cd /tinderbox/RELENG_8/i386/i386 TB --- 2012-12-23 14:31:53 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 14:32:03 - /usr/local/bin/svn update /src TB --- 2012-12-23 14:32:10 - building world TB --- 2012-12-23 14:32:10 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 14:32:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 14:32:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 14:32:10 - SRCCONF=/dev/null TB --- 2012-12-23 14:32:10 - TARGET=i386 TB --- 2012-12-23 14:32:10 - TARGET_ARCH=i386 TB --- 2012-12-23 14:32:10 - TZ=UTC TB --- 2012-12-23 14:32:10 - __MAKE_CONF=/dev/null TB --- 2012-12-23 14:32:10 - cd /src TB --- 2012-12-23 14:32:10 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 14:32:10 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Dec 23 15:19:19 UTC 2012 TB --- 2012-12-23 15:19:19 - generating LINT kernel config TB --- 2012-12-23 15:19:19 - cd /src/sys/i386/conf TB --- 2012-12-23 15:19:19 - /usr/bin/make -B LINT TB --- 2012-12-23 15:19:19 - cd /src/sys/i386/conf TB --- 2012-12-23 15:19:19 - /usr/sbin/config -m LINT TB --- 2012-12-23 15:19:19 - building LINT kernel TB --- 2012-12-23 15:19:19 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 15:19:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 15:19:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 15:19:19 - SRCCONF=/dev/null TB --- 2012-12-23 15:19:19 - TARGET=i386 TB --- 2012-12-23 15:19:19 - TARGET_ARCH=i386 TB --- 2012-12-23 15:19:19 - TZ=UTC TB --- 2012-12-23 15:19:19 - __MAKE_CONF=/dev/null TB --- 2012-12-23 15:19:19 - cd /src TB --- 2012-12-23 15:19:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 15:19:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/acpica/acpi_cpu.c:420: error: 'cpuset_t' undeclared (first use in this function) /src/sys/dev/acpica/acpi_cpu.c:420: error: (Each undeclared identifier is reported only once /src/sys/dev/acpica/acpi_cpu.c:420: error: for each function it appears in.) /src/sys/dev/acpica/acpi_cpu.c:420: error: expected ';' before 'cpuset' cc1: warnings being treated as errors /src/sys/dev/acpica/acpi_cpu.c:422: warning: implicit declaration of function 'CPU_SETOF' /src/sys/dev/acpica/acpi_cpu.c:422: warning: nested extern declaration of 'CPU_SETOF' /src/sys/dev/acpica/acpi_cpu.c:422: error: 'cpuset' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 15:23:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 15:23:04 - ERROR: failed to build LINT kernel TB --- 2012-12-23 15:23:04 - 2361.93 user 484.39 system 3070.96 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 15:35:43 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01D02F73; Sun, 23 Dec 2012 15:35:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 8858F8FC0C; Sun, 23 Dec 2012 15:35:42 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNFZf5b051727; Sun, 23 Dec 2012 15:35:41 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNFZfsF051720; Sun, 23 Dec 2012 15:35:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 15:35:41 GMT Message-Id: <201212231535.qBNFZfsF051720@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 15:35:43 -0000 TB --- 2012-12-23 14:31:53 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 14:31:53 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 14:31:53 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2012-12-23 14:31:53 - cleaning the object tree TB --- 2012-12-23 14:31:53 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 14:31:53 - cd /tinderbox/RELENG_8/ia64/ia64 TB --- 2012-12-23 14:31:53 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 14:32:03 - /usr/local/bin/svn update /src TB --- 2012-12-23 14:32:10 - building world TB --- 2012-12-23 14:32:10 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 14:32:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 14:32:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 14:32:10 - SRCCONF=/dev/null TB --- 2012-12-23 14:32:10 - TARGET=ia64 TB --- 2012-12-23 14:32:10 - TARGET_ARCH=ia64 TB --- 2012-12-23 14:32:10 - TZ=UTC TB --- 2012-12-23 14:32:10 - __MAKE_CONF=/dev/null TB --- 2012-12-23 14:32:10 - cd /src TB --- 2012-12-23 14:32:10 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 14:32:10 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Dec 23 15:32:30 UTC 2012 TB --- 2012-12-23 15:32:30 - generating LINT kernel config TB --- 2012-12-23 15:32:30 - cd /src/sys/ia64/conf TB --- 2012-12-23 15:32:30 - /usr/bin/make -B LINT TB --- 2012-12-23 15:32:30 - cd /src/sys/ia64/conf TB --- 2012-12-23 15:32:30 - /usr/sbin/config -m LINT TB --- 2012-12-23 15:32:30 - building LINT kernel TB --- 2012-12-23 15:32:30 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 15:32:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 15:32:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 15:32:30 - SRCCONF=/dev/null TB --- 2012-12-23 15:32:30 - TARGET=ia64 TB --- 2012-12-23 15:32:30 - TARGET_ARCH=ia64 TB --- 2012-12-23 15:32:30 - TZ=UTC TB --- 2012-12-23 15:32:30 - __MAKE_CONF=/dev/null TB --- 2012-12-23 15:32:30 - cd /src TB --- 2012-12-23 15:32:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 15:32:30 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/acpica/acpi_cpu.c:420: error: 'cpuset_t' undeclared (first use in this function) /src/sys/dev/acpica/acpi_cpu.c:420: error: (Each undeclared identifier is reported only once /src/sys/dev/acpica/acpi_cpu.c:420: error: for each function it appears in.) /src/sys/dev/acpica/acpi_cpu.c:420: error: expected ';' before 'cpuset' cc1: warnings being treated as errors /src/sys/dev/acpica/acpi_cpu.c:422: warning: implicit declaration of function 'CPU_SETOF' /src/sys/dev/acpica/acpi_cpu.c:422: warning: nested extern declaration of 'CPU_SETOF' /src/sys/dev/acpica/acpi_cpu.c:422: error: 'cpuset' undeclared (first use in this function) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 15:35:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 15:35:41 - ERROR: failed to build LINT kernel TB --- 2012-12-23 15:35:41 - 3113.35 user 502.42 system 3828.86 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 15:36:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A93DD118; Sun, 23 Dec 2012 15:36:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 32E228FC0A; Sun, 23 Dec 2012 15:36:56 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNFatR9075377; Sun, 23 Dec 2012 15:36:55 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNFat5C075365; Sun, 23 Dec 2012 15:36:55 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 15:36:55 GMT Message-Id: <201212231536.qBNFat5C075365@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 15:36:56 -0000 TB --- 2012-12-23 14:31:53 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 14:31:53 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 14:31:53 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2012-12-23 14:31:53 - cleaning the object tree TB --- 2012-12-23 14:31:53 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 14:31:53 - cd /tinderbox/RELENG_8/i386/pc98 TB --- 2012-12-23 14:31:53 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 14:32:03 - /usr/local/bin/svn update /src TB --- 2012-12-23 14:32:10 - building world TB --- 2012-12-23 14:32:10 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 14:32:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 14:32:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 14:32:10 - SRCCONF=/dev/null TB --- 2012-12-23 14:32:10 - TARGET=pc98 TB --- 2012-12-23 14:32:10 - TARGET_ARCH=i386 TB --- 2012-12-23 14:32:10 - TZ=UTC TB --- 2012-12-23 14:32:10 - __MAKE_CONF=/dev/null TB --- 2012-12-23 14:32:10 - cd /src TB --- 2012-12-23 14:32:10 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 14:32:10 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Dec 23 15:18:50 UTC 2012 TB --- 2012-12-23 15:18:50 - generating LINT kernel config TB --- 2012-12-23 15:18:50 - cd /src/sys/pc98/conf TB --- 2012-12-23 15:18:50 - /usr/bin/make -B LINT TB --- 2012-12-23 15:18:50 - cd /src/sys/pc98/conf TB --- 2012-12-23 15:18:50 - /usr/sbin/config -m LINT TB --- 2012-12-23 15:18:50 - building LINT kernel TB --- 2012-12-23 15:18:50 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 15:18:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 15:18:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 15:18:50 - SRCCONF=/dev/null TB --- 2012-12-23 15:18:50 - TARGET=pc98 TB --- 2012-12-23 15:18:50 - TARGET_ARCH=i386 TB --- 2012-12-23 15:18:50 - TZ=UTC TB --- 2012-12-23 15:18:50 - __MAKE_CONF=/dev/null TB --- 2012-12-23 15:18:50 - cd /src TB --- 2012-12-23 15:18:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 15:18:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sha256.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: In function 'spa_generate_rootconf': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: 'KM_ZERO' undeclared (first use in this function) /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: (Each undeclared identifier is reported only once /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 15:36:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 15:36:55 - ERROR: failed to build LINT kernel TB --- 2012-12-23 15:36:55 - 3079.47 user 574.71 system 3902.62 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 15:43:30 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A680C25B; Sun, 23 Dec 2012 15:43:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC7E8FC13; Sun, 23 Dec 2012 15:43:30 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNFhTES069494; Sun, 23 Dec 2012 15:43:29 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNFhTOw069492; Sun, 23 Dec 2012 15:43:29 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 15:43:29 GMT Message-Id: <201212231543.qBNFhTOw069492@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 15:43:30 -0000 TB --- 2012-12-23 14:31:53 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 14:31:53 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 14:31:53 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2012-12-23 14:31:53 - cleaning the object tree TB --- 2012-12-23 14:31:53 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 14:31:53 - cd /tinderbox/RELENG_8/amd64/amd64 TB --- 2012-12-23 14:31:53 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 14:32:03 - /usr/local/bin/svn update /src TB --- 2012-12-23 14:32:10 - building world TB --- 2012-12-23 14:32:10 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 14:32:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 14:32:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 14:32:10 - SRCCONF=/dev/null TB --- 2012-12-23 14:32:10 - TARGET=amd64 TB --- 2012-12-23 14:32:10 - TARGET_ARCH=amd64 TB --- 2012-12-23 14:32:10 - TZ=UTC TB --- 2012-12-23 14:32:10 - __MAKE_CONF=/dev/null TB --- 2012-12-23 14:32:10 - cd /src TB --- 2012-12-23 14:32:10 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 14:32:10 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Dec 23 15:40:32 UTC 2012 TB --- 2012-12-23 15:40:32 - generating LINT kernel config TB --- 2012-12-23 15:40:32 - cd /src/sys/amd64/conf TB --- 2012-12-23 15:40:32 - /usr/bin/make -B LINT TB --- 2012-12-23 15:40:32 - cd /src/sys/amd64/conf TB --- 2012-12-23 15:40:32 - /usr/sbin/config -m LINT TB --- 2012-12-23 15:40:32 - building LINT kernel TB --- 2012-12-23 15:40:32 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 15:40:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 15:40:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 15:40:32 - SRCCONF=/dev/null TB --- 2012-12-23 15:40:32 - TARGET=amd64 TB --- 2012-12-23 15:40:32 - TARGET_ARCH=amd64 TB --- 2012-12-23 15:40:32 - TZ=UTC TB --- 2012-12-23 15:40:32 - __MAKE_CONF=/dev/null TB --- 2012-12-23 15:40:32 - cd /src TB --- 2012-12-23 15:40:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 15:40:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/acpica/acpi_cpu.c:420: error: 'cpuset_t' undeclared (first use in this function) /src/sys/dev/acpica/acpi_cpu.c:420: error: (Each undeclared identifier is reported only once /src/sys/dev/acpica/acpi_cpu.c:420: error: for each function it appears in.) /src/sys/dev/acpica/acpi_cpu.c:420: error: expected ';' before 'cpuset' cc1: warnings being treated as errors /src/sys/dev/acpica/acpi_cpu.c:422: warning: implicit declaration of function 'CPU_SETOF' /src/sys/dev/acpica/acpi_cpu.c:422: warning: nested extern declaration of 'CPU_SETOF' /src/sys/dev/acpica/acpi_cpu.c:422: error: 'cpuset' undeclared (first use in this function) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 15:43:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 15:43:29 - ERROR: failed to build LINT kernel TB --- 2012-12-23 15:43:29 - 3317.76 user 698.37 system 4296.64 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 15:51:32 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C104D578; Sun, 23 Dec 2012 15:51:32 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.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 5D8AC8FC13; Sun, 23 Dec 2012 15:51:32 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 23 Dec 2012 10:51:25 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr17.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BVU69832; Sun, 23 Dec 2012 10:51:24 -0500 X-Auth-ID: anat Received: from pool-173-70-92-11.nwrknj.fios.verizon.net (HELO [192.168.1.8]) ([173.70.92.11]) by smtp01.lnh.mail.rcn.net with ESMTP; 23 Dec 2012 10:51:24 -0500 Message-ID: <50D7287C.7020802@aldan.algebra.com> Date: Sun, 23 Dec 2012 10:51:24 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120820 Thunderbird/14.0 MIME-Version: 1.0 To: brooks@freebsd.org Subject: What is "negative group permissions"? (Re: narawntapu security run output) References: <201212230805.qBN850Pj083122@narawntapu.narawntapu> In-Reply-To: <201212230805.qBN850Pj083122@narawntapu.narawntapu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 15:51:32 -0000 On 23.12.2012 03:05, Charlie Root wrote: > Checking negative group permissions: > 8903027 -rw--w-r-- 1 mi www 794277 Oct 23 07:47:45 2007 /home/mi/public_html/syb/order/download.log Hello! The above started to appear in the daily security run output after I upgraded to 9.1. I don't understand, what this check is doing or why the above file is reported -- what's abnormal (warning-worthy) about allowing the web-server to write to, but not read a file? I did it on purpose to keep all files associated with a project together, but without inadvertently serving some of them... The actual script generating this warning (110.neggrpperm) was added in 2010 and meant to be off by default. There is no explicit mention of the knob daily_status_security_neggrpperm_enable in the log for etc/defaults/periodic.conf... I understand, I can explicitly disable it, but I'm curious... Whether it should run by default or not, what is the purpose of it? Thanks, -mi From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 16:26:25 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D65FDE3; Sun, 23 Dec 2012 16:26:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3558FC0A; Sun, 23 Dec 2012 16:26:25 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNGQOqo037854; Sun, 23 Dec 2012 16:26:24 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNGQOVC037853; Sun, 23 Dec 2012 16:26:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 16:26:24 GMT Message-Id: <201212231626.qBNGQOVC037853@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 16:26:25 -0000 TB --- 2012-12-23 15:35:42 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 15:35:42 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 15:35:42 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-12-23 15:35:42 - cleaning the object tree TB --- 2012-12-23 15:35:42 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 15:35:42 - cd /tinderbox/RELENG_8/sparc64/sparc64 TB --- 2012-12-23 15:35:42 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 15:35:49 - /usr/local/bin/svn update /src TB --- 2012-12-23 15:35:55 - building world TB --- 2012-12-23 15:35:55 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 15:35:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 15:35:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 15:35:55 - SRCCONF=/dev/null TB --- 2012-12-23 15:35:55 - TARGET=sparc64 TB --- 2012-12-23 15:35:55 - TARGET_ARCH=sparc64 TB --- 2012-12-23 15:35:55 - TZ=UTC TB --- 2012-12-23 15:35:55 - __MAKE_CONF=/dev/null TB --- 2012-12-23 15:35:55 - cd /src TB --- 2012-12-23 15:35:55 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 15:35:55 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Dec 23 16:12:14 UTC 2012 TB --- 2012-12-23 16:12:14 - generating LINT kernel config TB --- 2012-12-23 16:12:14 - cd /src/sys/sparc64/conf TB --- 2012-12-23 16:12:14 - /usr/bin/make -B LINT TB --- 2012-12-23 16:12:14 - cd /src/sys/sparc64/conf TB --- 2012-12-23 16:12:14 - /usr/sbin/config -m LINT TB --- 2012-12-23 16:12:14 - building LINT kernel TB --- 2012-12-23 16:12:14 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 16:12:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 16:12:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 16:12:14 - SRCCONF=/dev/null TB --- 2012-12-23 16:12:14 - TARGET=sparc64 TB --- 2012-12-23 16:12:14 - TARGET_ARCH=sparc64 TB --- 2012-12-23 16:12:14 - TZ=UTC TB --- 2012-12-23 16:12:14 - __MAKE_CONF=/dev/null TB --- 2012-12-23 16:12:14 - cd /src TB --- 2012-12-23 16:12:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 16:12:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sha256.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: In function 'spa_generate_rootconf': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: 'KM_ZERO' undeclared (first use in this function) /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: (Each undeclared identifier is reported only once /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 16:26:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 16:26:24 - ERROR: failed to build LINT kernel TB --- 2012-12-23 16:26:24 - 2643.78 user 407.08 system 3042.59 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 16:32:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0565D2A6 for ; Sun, 23 Dec 2012 16:32:56 +0000 (UTC) (envelope-from barney@pit.databus.com) Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.61]) by mx1.freebsd.org (Postfix) with ESMTP id CF5CB8FC0A for ; Sun, 23 Dec 2012 16:32:55 +0000 (UTC) X-No-IP: databus.com@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from pit.databus.com (unknown [96.232.165.25]) (Authenticated sender: databus.com@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id 89071400359; Sun, 23 Dec 2012 08:23:34 -0800 (PST) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.14.5/8.14.5) with ESMTP id qBNGNWF8039375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 23 Dec 2012 11:23:32 -0500 (EST) (envelope-from barney@pit.databus.com) DKIM-Filter: OpenDKIM Filter v2.7.1 pit.databus.com qBNGNWF8039375 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=databus.com; s=20091218; t=1356279813; bh=bHxfeOIcsyereu3mHGloI4phLcA4u5k+b8We41OZMG8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=XCn4g22w1trwXjFgcGRLGIJXxkBfI/7Elsy21KetybhJhsEGd7klxbo6h2L+QBW4I dq5O1YE7iYMbfhx0BZTY2bdZXl+a9ijwJKTXnnu8usUxkE1jzwe1RuEZRGwacAIpEN YkQablRZmZbJtG7ItsEQGrgifSJJOqVVc6iXZBZ4= Received: (from barney@localhost) by pit.databus.com (8.14.5/8.14.5/Submit) id qBNGNW7g039374; Sun, 23 Dec 2012 11:23:32 -0500 (EST) (envelope-from barney) Date: Sun, 23 Dec 2012 11:23:32 -0500 From: Barney Wolff To: "Mikhail T." Subject: Re: What is "negative group permissions"? (Re: narawntapu security run output) Message-ID: <20121223162332.GA38788@pit.databus.com> References: <201212230805.qBN850Pj083122@narawntapu.narawntapu> <50D7287C.7020802@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D7287C.7020802@aldan.algebra.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 16:32:56 -0000 The r for other means that you have not accomplished your goal. It makes no sense to have group with less permission that other, so the script is warning of a misconfiguration. On Sun, Dec 23, 2012 at 10:51:24AM -0500, Mikhail T. wrote: > On 23.12.2012 03:05, Charlie Root wrote: > > Checking negative group permissions: > > 8903027 -rw--w-r-- 1 mi www 794277 Oct 23 07:47:45 2007 /home/mi/public_html/syb/order/download.log > Hello! > > The above started to appear in the daily security run output after I > upgraded to 9.1. I don't understand, what this check is doing or why the > above file is reported -- what's abnormal (warning-worthy) about > allowing the web-server to write to, but not read a file? I did it on > purpose to keep all files associated with a project together, but > without inadvertently serving some of them... From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 16:49:26 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD18B4CC for ; Sun, 23 Dec 2012 16:49:26 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6F4398FC0C for ; Sun, 23 Dec 2012 16:49:26 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id c11so8077532ieb.5 for ; Sun, 23 Dec 2012 08:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=WkmWRayekQXpPYVknFG01Cks880Xr1EqK7ZM6qj5dd0=; b=tbCUmRhieotaRGFFVZfbZtpsaf0B2EwGRV2VtYKasJ5mNWp8oeqqNVd0RDtJ0dphFI yEdgFxSc7Afst6HIRUWGpb9mpRHhvPllR/InDmjR3Q62ha9w5+2bqVluPTbTeHSwNlsg aZ+xRajXecdViUrNYNr2KGi2Mvz5w1I7+K8goGU6GTkI2uRKccstPY81khs8+CNgnHfL eUtK5jHs1uTuGADOE4mhQwTIPlEyPW6LgwthhFNf9OdsVNaPTFAqjejwS30AfaxYAENh BJio0iqExvju28sIdcm5yqr7O8alkGx+hkAWVaENL37H1uT6X8F65ZsCvKXzYrEp8cnf QQCw== Received: by 10.50.40.137 with SMTP id x9mr18708701igk.1.1356281360007; Sun, 23 Dec 2012 08:49:20 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.65.132 with HTTP; Sun, 23 Dec 2012 08:48:48 -0800 (PST) In-Reply-To: <20121223162332.GA38788@pit.databus.com> References: <201212230805.qBN850Pj083122@narawntapu.narawntapu> <50D7287C.7020802@aldan.algebra.com> <20121223162332.GA38788@pit.databus.com> From: Chris Rees Date: Sun, 23 Dec 2012 16:48:48 +0000 X-Google-Sender-Auth: tcwph74TcpS2F4FowsbxIylkafE Message-ID: Subject: Re: What is "negative group permissions"? (Re: narawntapu security run output) To: Barney Wolff Content-Type: text/plain; charset=ISO-8859-1 Cc: "Mikhail T." , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 16:49:26 -0000 On 23 December 2012 16:23, Barney Wolff wrote: [moving Barney's top post down] > On Sun, Dec 23, 2012 at 10:51:24AM -0500, Mikhail T. wrote: >> On 23.12.2012 03:05, Charlie Root wrote: >> > Checking negative group permissions: >> > 8903027 -rw--w-r-- 1 mi www 794277 Oct 23 07:47:45 2007 /home/mi/public_html/syb/order/download.log >> Hello! >> >> The above started to appear in the daily security run output after I >> upgraded to 9.1. I don't understand, what this check is doing or why the >> above file is reported -- what's abnormal (warning-worthy) about >> allowing the web-server to write to, but not read a file? I did it on >> purpose to keep all files associated with a project together, but >> without inadvertently serving some of them... > > The r for other means that you have not accomplished your goal. It makes > no sense to have group with less permission that other, so the script is > warning of a misconfiguration. Not at all; anything in www group can't read the file, which is what Mikhail wants to do. If he has thought about the consequences of exactly what this means; i.e. normal users can read-only, www group can write-only, mi can read/write, then he can ignore the warning. Negative group permissions are sometimes useful, that's why they're allowed. >> I understand, I can explicitly disable it, but I'm curious... Whether it >> should run by default or not, what is the purpose of it? They involve a lot of thought to get right, as well as chmod g-w on something where you probably meant chmod go-w is a disastrous but (perhaps) common error. Chris From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 17:50:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4355AC18 for ; Sun, 23 Dec 2012 17:50:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA8D8FC13 for ; Sun, 23 Dec 2012 17:50:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id qBNHoMnB001363; Mon, 24 Dec 2012 04:50:22 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 24 Dec 2012 04:50:22 +1100 (EST) From: Ian Smith To: Sergey Kandaurov Subject: Re: 9.1 minimal ram requirements In-Reply-To: Message-ID: <20121224041301.W83325@sola.nimnet.asn.au> References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> <20121223150954.B81991@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Marten Vijn , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 17:50:26 -0000 On Sun, 23 Dec 2012 15:21:23 +0300, Sergey Kandaurov wrote: > On 23 December 2012 10:22, Ian Smith wrote: > > On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote: > > > This (i.e. the "kmem_map too small" message seen with kernel memory > > > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > > > quite a big kernel memory consumer. > > > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. > > > > I've just added that, thanks Sergey, but it's sadly not an option for > > installation. I guess it's too late for the release notes - which at > > RC3 made no mention of CAM CTL at all - but it's not yet clear to me > > whether even 256MB is enough to boot, install and run 9.1 GENERIC? > > If you perform clean installation (e.g. from ISO), you can escape to the > loader prompt and set the tunable there w/o the need for /boot/loader.conf. > I experimented with Vbox and AFAIK 256MB was enough even with CAM CTL. Ah right; I'd booted and installed from memstick, where escape to loader prompt is not an option. I'll burn a disc1 and try that with the 128MB again, and make sure that 256MB is comfortable - after holiday madness. > > > A longer term workaround could be to postpone those memory allocations > > > until the first call to CTL. That would seem to make sense, while making it a module is still on the todo list. I guess there must be systems that need CAM CTL to boot? > > Under what circumstances is CAM CTL needed? What would leaving it out > > of GENERIC cost, and whom? Is it loadable? dmesg.boot reports loading, > > but I don't see a module, nor can I find much information about CTL in > > cam(3|4) or /sys/conf/NOTES. apropos found ctladm and ctlstat, but I'm > > little the wiser as to when it may be needed, beyond CAM/SCSI debugging? > > The purpose and current status are well documented in the initial commit > message (r229997) and the supplied README.ctl.txt. To my modest knowledge, > it should be safe to just comment out 'device ctl' in GENERIC. Thanks for the reference, seems that I won't be needing it just now; it just wasn't clear to me what if any other subsystems might hang off it. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 18:04:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A51A7347 for ; Sun, 23 Dec 2012 18:04:10 +0000 (UTC) (envelope-from smkelly@flightaware.com) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by mx1.freebsd.org (Postfix) with ESMTP id 8699A8FC0A for ; Sun, 23 Dec 2012 18:04:10 +0000 (UTC) Received: from MBX021-W3-CA-5.exch021.domain.local ([10.254.4.81]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.02.0318.001; Sun, 23 Dec 2012 09:56:04 -0800 From: Sean Kelly To: Daniel Braniss Subject: RE: RELENG_9 panic with PERC 6/i (mfi) Thread-Topic: RELENG_9 panic with PERC 6/i (mfi) Thread-Index: AQHN4OFEw2Pue//oQCOF7Nen9MVYapgmqczz Date: Sun, 23 Dec 2012 17:56:04 +0000 Message-ID: <13D4274FB3603545B1811E6390085F3D0C190360@MBX021-W3-CA-5.exch021.domain.local> References: Your message of Sun, 23 Dec 2012 06:44:05 +0000., In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.13.80.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 18:04:10 -0000 Greetings.=0A= =0A= All I have to do to panic it is boot it. As you can see from the dump, it d= ied after about 30 seconds without me doing anything. I can't provide those= sysctl values easily, as it panics too quickly. I suppose I can convince i= t to drop to DDB and pick them out if that would be helpful.=0A= =0A= Here they are from the working 8.2-R kernel.=0A= vm.kmem_map_free: 49870348288=0A= vm.kmem_map_size: 68964352=0A= =0A= This box, unlike most of our others, doesn't even utilizing ZFS.=0A= root@papa:~# gpart show=0A= =3D> 63 1141899192 mfid0 MBR (545G)=0A= 63 1141884072 1 freebsd [active] (544G)=0A= 1141884135 15120 - free - (7.4M)=0A= =0A= =3D> 0 1141884072 mfid0s1 BSD (544G)=0A= 0 8388608 1 freebsd-ufs (4.0G)=0A= 8388608 16777216 4 freebsd-ufs (8.0G)=0A= 25165824 33554432 5 freebsd-ufs (16G)=0A= 58720256 67108864 2 freebsd-swap (32G)=0A= 125829120 67108864 7 freebsd-swap (32G)=0A= 192937984 67108864 8 freebsd-swap (32G)=0A= 260046848 881837224 6 freebsd-ufs (420G)=0A= =0A= ________________________________________=0A= From: Daniel Braniss [danny@cs.huji.ac.il]=0A= Sent: Sunday, December 23, 2012 1:43 AM=0A= To: Sean Kelly=0A= Subject: Re: RELENG_9 panic with PERC 6/i (mfi)=0A= =0A= btw:=0A= sysctl -a | grep kmem_map=0A= vm.kmem_map_free: 8859570176=0A= vm.kmem_map_size: 6037008384=0A= =0A= =0A= danny=0A= =0A= =0A= From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 19:13:45 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49B33EE2; Sun, 23 Dec 2012 19:13:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id E93C18FC0A; Sun, 23 Dec 2012 19:13:44 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNJDimR066282; Sun, 23 Dec 2012 19:13:44 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNJDiOf066231; Sun, 23 Dec 2012 19:13:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 19:13:44 GMT Message-Id: <201212231913.qBNJDiOf066231@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 19:13:45 -0000 TB --- 2012-12-23 18:07:42 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 18:07:42 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 18:07:42 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2012-12-23 18:07:42 - cleaning the object tree TB --- 2012-12-23 18:08:44 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 18:08:44 - cd /tinderbox/RELENG_8/i386/pc98 TB --- 2012-12-23 18:08:44 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 18:08:58 - /usr/local/bin/svn update /src TB --- 2012-12-23 18:09:02 - building world TB --- 2012-12-23 18:09:02 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 18:09:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 18:09:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 18:09:02 - SRCCONF=/dev/null TB --- 2012-12-23 18:09:02 - TARGET=pc98 TB --- 2012-12-23 18:09:02 - TARGET_ARCH=i386 TB --- 2012-12-23 18:09:02 - TZ=UTC TB --- 2012-12-23 18:09:02 - __MAKE_CONF=/dev/null TB --- 2012-12-23 18:09:02 - cd /src TB --- 2012-12-23 18:09:02 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 18:09:02 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Dec 23 18:55:44 UTC 2012 TB --- 2012-12-23 18:55:44 - generating LINT kernel config TB --- 2012-12-23 18:55:44 - cd /src/sys/pc98/conf TB --- 2012-12-23 18:55:44 - /usr/bin/make -B LINT TB --- 2012-12-23 18:55:44 - cd /src/sys/pc98/conf TB --- 2012-12-23 18:55:44 - /usr/sbin/config -m LINT TB --- 2012-12-23 18:55:44 - building LINT kernel TB --- 2012-12-23 18:55:44 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 18:55:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 18:55:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 18:55:44 - SRCCONF=/dev/null TB --- 2012-12-23 18:55:44 - TARGET=pc98 TB --- 2012-12-23 18:55:44 - TARGET_ARCH=i386 TB --- 2012-12-23 18:55:44 - TZ=UTC TB --- 2012-12-23 18:55:44 - __MAKE_CONF=/dev/null TB --- 2012-12-23 18:55:44 - cd /src TB --- 2012-12-23 18:55:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 18:55:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sha256.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: In function 'spa_generate_rootconf': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: 'KM_ZERO' undeclared (first use in this function) /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: (Each undeclared identifier is reported only once /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 19:13:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 19:13:44 - ERROR: failed to build LINT kernel TB --- 2012-12-23 19:13:44 - 3076.93 user 572.44 system 3962.03 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 19:17:32 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 434B1E3; Sun, 23 Dec 2012 19:17:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id E485F8FC0A; Sun, 23 Dec 2012 19:17:31 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNJHVE9028691; Sun, 23 Dec 2012 19:17:31 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNJHVUc028690; Sun, 23 Dec 2012 19:17:31 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 19:17:31 GMT Message-Id: <201212231917.qBNJHVUc028690@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 19:17:32 -0000 TB --- 2012-12-23 18:07:42 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 18:07:42 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 18:07:42 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2012-12-23 18:07:42 - cleaning the object tree TB --- 2012-12-23 18:08:44 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 18:08:44 - cd /tinderbox/RELENG_8/i386/i386 TB --- 2012-12-23 18:08:44 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 18:08:58 - /usr/local/bin/svn update /src TB --- 2012-12-23 18:09:02 - building world TB --- 2012-12-23 18:09:02 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 18:09:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 18:09:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 18:09:02 - SRCCONF=/dev/null TB --- 2012-12-23 18:09:02 - TARGET=i386 TB --- 2012-12-23 18:09:02 - TARGET_ARCH=i386 TB --- 2012-12-23 18:09:02 - TZ=UTC TB --- 2012-12-23 18:09:02 - __MAKE_CONF=/dev/null TB --- 2012-12-23 18:09:02 - cd /src TB --- 2012-12-23 18:09:02 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 18:09:02 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Dec 23 18:56:14 UTC 2012 TB --- 2012-12-23 18:56:14 - generating LINT kernel config TB --- 2012-12-23 18:56:14 - cd /src/sys/i386/conf TB --- 2012-12-23 18:56:14 - /usr/bin/make -B LINT TB --- 2012-12-23 18:56:14 - cd /src/sys/i386/conf TB --- 2012-12-23 18:56:14 - /usr/sbin/config -m LINT TB --- 2012-12-23 18:56:14 - building LINT kernel TB --- 2012-12-23 18:56:14 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 18:56:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 18:56:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 18:56:14 - SRCCONF=/dev/null TB --- 2012-12-23 18:56:14 - TARGET=i386 TB --- 2012-12-23 18:56:14 - TARGET_ARCH=i386 TB --- 2012-12-23 18:56:14 - TZ=UTC TB --- 2012-12-23 18:56:14 - __MAKE_CONF=/dev/null TB --- 2012-12-23 18:56:14 - cd /src TB --- 2012-12-23 18:56:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 18:56:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sha256.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: In function 'spa_generate_rootconf': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: 'KM_ZERO' undeclared (first use in this function) /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: (Each undeclared identifier is reported only once /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 19:17:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 19:17:31 - ERROR: failed to build LINT kernel TB --- 2012-12-23 19:17:31 - 3267.30 user 587.25 system 4189.29 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 19:35:39 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B05FE68C; Sun, 23 Dec 2012 19:35:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 3CC348FC12; Sun, 23 Dec 2012 19:35:39 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNJZcxx046733; Sun, 23 Dec 2012 19:35:38 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNJZc2M046727; Sun, 23 Dec 2012 19:35:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 19:35:38 GMT Message-Id: <201212231935.qBNJZc2M046727@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 19:35:39 -0000 TB --- 2012-12-23 18:07:42 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 18:07:42 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 18:07:42 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2012-12-23 18:07:42 - cleaning the object tree TB --- 2012-12-23 18:08:48 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 18:08:48 - cd /tinderbox/RELENG_8/amd64/amd64 TB --- 2012-12-23 18:08:48 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 18:09:01 - /usr/local/bin/svn update /src TB --- 2012-12-23 18:09:06 - building world TB --- 2012-12-23 18:09:06 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 18:09:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 18:09:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 18:09:06 - SRCCONF=/dev/null TB --- 2012-12-23 18:09:06 - TARGET=amd64 TB --- 2012-12-23 18:09:06 - TARGET_ARCH=amd64 TB --- 2012-12-23 18:09:06 - TZ=UTC TB --- 2012-12-23 18:09:06 - __MAKE_CONF=/dev/null TB --- 2012-12-23 18:09:06 - cd /src TB --- 2012-12-23 18:09:06 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 18:09:06 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Dec 23 19:17:43 UTC 2012 TB --- 2012-12-23 19:17:43 - generating LINT kernel config TB --- 2012-12-23 19:17:43 - cd /src/sys/amd64/conf TB --- 2012-12-23 19:17:43 - /usr/bin/make -B LINT TB --- 2012-12-23 19:17:43 - cd /src/sys/amd64/conf TB --- 2012-12-23 19:17:43 - /usr/sbin/config -m LINT TB --- 2012-12-23 19:17:43 - building LINT kernel TB --- 2012-12-23 19:17:43 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 19:17:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 19:17:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 19:17:43 - SRCCONF=/dev/null TB --- 2012-12-23 19:17:43 - TARGET=amd64 TB --- 2012-12-23 19:17:43 - TARGET_ARCH=amd64 TB --- 2012-12-23 19:17:43 - TZ=UTC TB --- 2012-12-23 19:17:43 - __MAKE_CONF=/dev/null TB --- 2012-12-23 19:17:43 - cd /src TB --- 2012-12-23 19:17:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 19:17:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -s! td=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -s! td=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -s! td=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sha256.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -s! td=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: In function 'spa_generate_rootconf': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: 'KM_ZERO' undeclared (first use in this function) /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: (Each undeclared identifier is reported only once /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 19:35:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 19:35:38 - ERROR: failed to build LINT kernel TB --- 2012-12-23 19:35:38 - 4133.89 user 781.91 system 5276.55 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 20:07:43 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85172E09; Sun, 23 Dec 2012 20:07:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 344668FC12; Sun, 23 Dec 2012 20:07:43 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id qBNK7gm4038939; Sun, 23 Dec 2012 20:07:42 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id qBNK7geB038938; Sun, 23 Dec 2012 20:07:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 23 Dec 2012 20:07:42 GMT Message-Id: <201212232007.qBNK7geB038938@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 20:07:43 -0000 TB --- 2012-12-23 19:14:34 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2012-12-23 19:14:34 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-23 19:14:34 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-12-23 19:14:34 - cleaning the object tree TB --- 2012-12-23 19:14:56 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2012-12-23 19:14:56 - cd /tinderbox/RELENG_8/sparc64/sparc64 TB --- 2012-12-23 19:14:56 - /usr/local/bin/svn cleanup /src TB --- 2012-12-23 19:15:04 - /usr/local/bin/svn update /src TB --- 2012-12-23 19:15:08 - building world TB --- 2012-12-23 19:15:08 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 19:15:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 19:15:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 19:15:08 - SRCCONF=/dev/null TB --- 2012-12-23 19:15:08 - TARGET=sparc64 TB --- 2012-12-23 19:15:08 - TARGET_ARCH=sparc64 TB --- 2012-12-23 19:15:08 - TZ=UTC TB --- 2012-12-23 19:15:08 - __MAKE_CONF=/dev/null TB --- 2012-12-23 19:15:08 - cd /src TB --- 2012-12-23 19:15:08 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 23 19:15:08 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Dec 23 19:53:34 UTC 2012 TB --- 2012-12-23 19:53:34 - generating LINT kernel config TB --- 2012-12-23 19:53:34 - cd /src/sys/sparc64/conf TB --- 2012-12-23 19:53:34 - /usr/bin/make -B LINT TB --- 2012-12-23 19:53:34 - cd /src/sys/sparc64/conf TB --- 2012-12-23 19:53:34 - /usr/sbin/config -m LINT TB --- 2012-12-23 19:53:34 - building LINT kernel TB --- 2012-12-23 19:53:34 - CROSS_BUILD_TESTING=YES TB --- 2012-12-23 19:53:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-23 19:53:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-23 19:53:34 - SRCCONF=/dev/null TB --- 2012-12-23 19:53:34 - TARGET=sparc64 TB --- 2012-12-23 19:53:34 - TARGET_ARCH=sparc64 TB --- 2012-12-23 19:53:34 - TZ=UTC TB --- 2012-12-23 19:53:34 - __MAKE_CONF=/dev/null TB --- 2012-12-23 19:53:34 - cd /src TB --- 2012-12-23 19:53:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 23 19:53:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sha256.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: In function 'spa_generate_rootconf': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: 'KM_ZERO' undeclared (first use in this function) /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: (Each undeclared identifier is reported only once /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3785: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-23 20:07:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-23 20:07:42 - ERROR: failed to build LINT kernel TB --- 2012-12-23 20:07:42 - 2733.95 user 433.50 system 3187.93 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 21:51:54 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AD2564E for ; Sun, 23 Dec 2012 21:51:54 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by mx1.freebsd.org (Postfix) with ESMTP id D46948FC0A for ; Sun, 23 Dec 2012 21:51:53 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id r15so7636431lag.22 for ; Sun, 23 Dec 2012 13:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=3M0j9AAKPpbTW3YZdNiyIEE7ikozYNfO4yWceCCGQiI=; b=AsYzvsIOBmo6Gwb/E0UkzXGx9+UAzhA8Jg3stS7u+OADYrc6N9DeQSWCVGYdRvZNHi I2KlBbErUVlCPwzn4euYoH9t3fEE51HBmCmJsDujzyK1o7uES661EapA8efH+AMu+7c8 DjnEsCs70SBRl2oWgcuBXUt74jOLOPdfm0wn4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=3M0j9AAKPpbTW3YZdNiyIEE7ikozYNfO4yWceCCGQiI=; b=RmtYQH9JrCWnS/muWXzyKBqiYcjBN+ITl+UI8lCnAlXcMhqP3bBWLSvJ6P1o4Vu/7h N+kFRDk+iMh9VW/AeeWGAJIRNljnBvUWoMd5MW9T3EPplIjsgXYumNXuSjV220Mp/ERg cjI7PrSvh2r5DA4nXZbj1WBAJEZ+G2Hdd5Kw8a1kW8nIVjcGMWp16gyqXaF9l/QBpwrp AyY4NlHuER10T1XTY57iUIOew1w8f+/9iKrXd8FNvIls5wOEj51CsoBSt8hfF4j6qnK9 is84W5y84DdRl+Qqvcew11mu4H5O3CXMEY89HUubToqgD6dLLPa6xSgKqeb/xfR9Rb6x xMrA== MIME-Version: 1.0 Received: by 10.152.104.112 with SMTP id gd16mr18783151lab.26.1356299512337; Sun, 23 Dec 2012 13:51:52 -0800 (PST) Sender: simon@qxnitro.org Received: by 10.112.12.52 with HTTP; Sun, 23 Dec 2012 13:51:52 -0800 (PST) X-Originating-IP: [93.163.223.40] Date: Sun, 23 Dec 2012 22:51:52 +0100 X-Google-Sender-Auth: gRhqGco6AbS_7O4lEgMT-JFpr_I Message-ID: Subject: GNATS now available via rsync From: "Simon L. B. Nielsen" To: freebsd-stable@FreeBSD.org, freebsd-ports@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlsmlA0QH8e3sbHX/1YIsUODfIBRO+Hkb1a1KxzmHrjcN7AONiY2x0af5bZkgVIJ74EMwhq X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 21:51:54 -0000 Hey, The GNATS database can now be mirrored using rsync from: rsync://bit0.us-west.freebsd.org/FreeBSD-bit/gnats/ I expect that URL to be permanent, at least while GNATS is still alive. At a later point there will be more mirrors (a us-east will be the first) and I will find a place to publish the mirror list. On a side note, GNATS changes aren't mirrored to the old CVSup system right now, as cvsupd broke on FreeBSD 10.0, which the hosts running GNATS is running. There is no current plans from clusteradm@'s side to fix this now that an alternative way to get GNATS exists and cvsup is deprecated long term anyway. -- Simon L. B. Nielsen Hat: clusteradm@ From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 22:49:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61980372; Sun, 23 Dec 2012 22:49:09 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED238FC13; Sun, 23 Dec 2012 22:49:08 +0000 (UTC) Received: from localhost.takeda.tk (takeda-ws2.lan [10.0.0.123]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id qBNMXa63010389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 23 Dec 2012 14:33:37 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Sun, 23 Dec 2012 14:23:08 -0800 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <1824023197.20121223142308@takeda.tk> To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at chinatsu.takeda.tk X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Dec 2012 22:49:09 -0000 Please help, I reported this issue on http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174372 but the crashes are unbearable since they happen regularly at night, most of the time when periodic.daily is called (3am) but there are exceptions. It seems like it can be triggered by any heavy disk activity. In many of the crash dumps the current process is find command, but of course that's does not always is the cause. When calling scrub, it appears to pass successfully. Smartmon tools is not reporting any disk errors. I tested memory using memtest86 about a month ago and it passed tests successfully. I never had this type of issue on 9.0, and not much changed in my kernel config besides installing WiFi card. System: FreeBSD chinatsu.takeda.tk 9.1-RELEASE FreeBSD 9.1-RELEASE #2 r244482: Wed Dec 19 23:28:15 PST 2012 root@chinatsu.takeda.tk:/usr/obj/usr/src/sys/CHINATSU amd64 It's compiled from releng/9.1 branch. Thank you for any help, Derek Example crash messages: Today: panic: general protection fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1cd trap_fatal() at trap_fatal+0x285 trap() at trap+0x23e calltrap() at calltrap+0x8 --- trap 0x9, rip = 0xffffffff8101f5ac, rsp = 0xffffff8230ac18c0, rbp = 0xffffff8230ac18d0 --- list_prev() at list_prev+0xc arc_evict() at arc_evict+0x194 arc_adjust() at arc_adjust+0x1a1 arc_reclaim_thread() at arc_reclaim_thread+0x1a6 fork_exit() at fork_exit+0x11c fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8230ac1bb0, rbp = 0 --- Uptime: 20h44m51s Dumping 1157 out of 8072 MB:..2%..12%..21%..31%..41%..52%..61%..71%..81%..92% Yesterday: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffffffffffffffe8 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8102d1e7 stack pointer = 0x28:0xffffff82315ec190 frame pointer = 0x28:0xffffff82315ec280 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 34744 (find) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1cd trap_fatal() at trap_fatal+0x285 trap_pfault() at trap_pfault+0x216 trap() at trap+0x363 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff8102d1e7, rsp = 0xffffff82315ec190, rbp = 0xffffff82315ec280 --- arc_evict() at arc_evict+0x1e7 arc_get_data_buf() at arc_get_data_buf+0x1d5 arc_read_nolock() at arc_read_nolock+0x1ec arc_read() at arc_read+0x93 dbuf_read() at dbuf_read+0x452 dmu_buf_hold() at dmu_buf_hold+0xe0 zap_lockdir() at zap_lockdir+0x58 zap_cursor_retrieve() at zap_cursor_retrieve+0x19b zfs_freebsd_readdir() at zfs_freebsd_readdir+0x2ee VOP_READDIR_APV() at VOP_READDIR_APV+0x4a kern_getdirentries() at kern_getdirentries+0x225 sys_getdirentries() at sys_getdirentries+0x23 amd64_syscall() at amd64_syscall+0x5d8 Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80089b29c, rsp = 0x7fffffffd8a8, rbp = 0x1 --- Uptime: 2d3h49m3s Dumping 3701 out of 8072 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% -- Best regards, Derek mailto:takeda@takeda.tk From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 04:07:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98E02C3D; Mon, 24 Dec 2012 04:07:05 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id EF27B8FC0A; Mon, 24 Dec 2012 04:07:04 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so2447330wgb.1 for ; Sun, 23 Dec 2012 20:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=G3tXt7E2tEOYQDgBs1xJSi3ljFCcaDMNmq8eTZViAKA=; b=H2H3cI9vOrUPhb22k3grq7KIxHMCBD813/Y/Rslm4PZJxwe5rlO0jnd9pEVBlWxM6p Aubp1zfQ/6zt9HwCTZvUlpxOw0/JFplHlKVX38fMYQwzP8kv88yqlaIsqGfvs8SKDIrJ rngWhse2Ip2rShiEp6EpiNpY1/lAlSrkgqeN3lJlkgpsTwG0iUmMLM702Hszq1EPDLu1 eQblzn64ZazwkKF7Q2PeDCito36BlaHfKKwxa66iFije3Qj/zPb0zj/kEKlKdvo21U9Y ycNhQ58LNjOBiJTsgbGsCkT2EIwGU2cbNlvQ/JncmXZxjXgsj1TOdfUvRA8SCEjE0u8L F49A== MIME-Version: 1.0 Received: by 10.194.9.162 with SMTP id a2mr33625162wjb.33.1356322024137; Sun, 23 Dec 2012 20:07:04 -0800 (PST) Received: by 10.216.172.197 with HTTP; Sun, 23 Dec 2012 20:07:03 -0800 (PST) In-Reply-To: <50D5F296.9050109@wasikowski.net> References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> Date: Mon, 24 Dec 2012 06:07:03 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ben Morrow , FreeBSD current , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 04:07:05 -0000 On Sat, Dec 22, 2012 at 7:49 PM, =C5=81ukasz W=C4=85sikowski wrote: > W dniu 2012-12-22 18:14, Ben Morrow pisze: >> Quoth =3D?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ=3D=3D?=3D : >>> W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: >>> >>>> Yeah, this is problem in network.subr. An interface is not recognized >>>> as IPv6 capable if the interface is not in "ipv6_network_interfaces" >>>> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it >>>> "just works" because the interface is always assumed to be IPv4 >>>> capable. >>> >>> Ok, I used ifconfig_em0_ipv6=3D"up" and it worked. So it looks like thi= s: >> >> The documented way to do this is to just set the link-local address in >> ifconfig_IF_ipv6, since an interface is required to have a link-local >> address. Either configure an fe80:: address explicitly or set >> >> ifconfig_em0_ipv6=3D"inet6 auto_linklocal" >> >> Alternatively, if you set ipv6_activate_all_interfaces all interfaces >> will be considered IPv6-capable. > > link-local address is assigned by default, even with ifconfig_IF_ipv6=3D"= up". > > root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf ; ifconfig > em0 | grep -E '^[[:space:]]*inet6' | head -2 > hostname=3D"freebsd" > ifconfig_em0=3D"up" > ipv4_addrs_em0=3D"192.168.168.20-24/24" > defaultrouter=3D"192.168.168.1" > ipv6_network_interfaces=3D"em0" > ipv6_defaultrouter=3D"2001:6a0:1cb::ffff" > ifconfig_em0_ipv6=3D"up" > ipv6_addrs_em0=3D"2001:6a0:1cb::1-e/128" > sshd_enable=3D"YES" > dumpdev=3D"NO" > named_enable=3D"YES" > inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1 > inet6 2001:6a0:1cb::1 prefixlen 128 > > Of course using "inet6 auto_linklocal" instead of "up" seems a better > way to do it, thank you for this tip. > > -- > best regards, > Lukasz Wasikowski I have put up the patch at github as: https://gist.github.com/4362018 This version should work with just the ipv6_addrs_IF in rc.conf(5). I changed the detection of ipv6 interfaces so that just having the ipv6_addrs_IF line is enough. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 04:08:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24E7BE48 for ; Mon, 24 Dec 2012 04:08:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9E5258FC0A for ; Mon, 24 Dec 2012 04:08:40 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u3so3183166wey.16 for ; Sun, 23 Dec 2012 20:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=v5YHwDzOguWkM6MSSN5M0DF6z1dskOr0QJ4PQkR1OlI=; b=J9KJxuvz7Tup5CrjHuz+/L+bTCtPFhx+LOyDuBvUhMrjNYVdVtLpDDbNEcJ96I8L+9 gROkwHyxnF0oddBkIi/jCMIyfu6A9gZTOmyANcUM9jsE1S8/OkEoxHwmhFbJEDKADCiD etd8fM526P+DpHMXyfDj6PTLJksMYHTG1Zu7/+80PyzotTy8ru/68yNHTwjO6jg7POUd BMMzSOo3HITB+na+xe50doAP29s1P2G4ubFVe6uLkh3Az286ZYDfa+j+R86iY9qM1wlg bSCAtDXmghAnTVl8ZPUhBP44pqLlnsLGDVXV/f1OpVN5nsQHrUBmLxnZLoMNf1AEcRAt QBgw== MIME-Version: 1.0 Received: by 10.180.93.133 with SMTP id cu5mr25204399wib.32.1356322113858; Sun, 23 Dec 2012 20:08:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 23 Dec 2012 20:08:33 -0800 (PST) In-Reply-To: <20121224041301.W83325@sola.nimnet.asn.au> References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> <20121223150954.B81991@sola.nimnet.asn.au> <20121224041301.W83325@sola.nimnet.asn.au> Date: Sun, 23 Dec 2012 20:08:33 -0800 X-Google-Sender-Auth: 4HbfU1RNtEzy2xGsEjY7LJfOmoU Message-ID: Subject: Re: 9.1 minimal ram requirements From: Adrian Chadd To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: Marten Vijn , Sergey Kandaurov , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 04:08:41 -0000 Ok, I'll see about disabling it in GENERIC and STABLE/9 for now, at least until Ken has some idea of what's going on. Thanks, Adrian From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 04:08:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AF35E49 for ; Mon, 24 Dec 2012 04:08:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id A7F078FC0C for ; Mon, 24 Dec 2012 04:08:43 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id dq12so3144405wgb.24 for ; Sun, 23 Dec 2012 20:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vif0GoUoq8HA5FQIFevYy1amsnqOI+sbOYj5UQpsnr4=; b=pUNwELUe+uI3VpDpjy01IJXzNsYTB2RuL9jEdQuMuRdDPJccoOOw9wwwX1HarQFt9i z9F5YXF5k4Ae5MRLtF8X2coqzCKvFJ58dXJNIQyBa8A56aZAUg1e8myEg/FRXud2EAxl yBxxEsl/mZPgLkaidMtjuRHe1bZCcjc/SirVl2vmzh1BB/CxRRNDbyPuI88cREdA0DQy BzZX8p6fFisByvwr0Ukjf62StdPS8eAm3CyGXDefrPwiErnpXf3zJV8GgTtdi043hWNe awZsj0YGv68pzxX8wZAG/mKCDFHuBpoxn2tAgJHIrHTuZWpbRAOqtJIVeMHcdb3eniIK jxOw== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr33866446wjc.1.1356322122528; Sun, 23 Dec 2012 20:08:42 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 23 Dec 2012 20:08:42 -0800 (PST) In-Reply-To: References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> <20121223150954.B81991@sola.nimnet.asn.au> <20121224041301.W83325@sola.nimnet.asn.au> Date: Sun, 23 Dec 2012 20:08:42 -0800 X-Google-Sender-Auth: d5fYOlSN11eOei0anQV3tmMU5NU Message-ID: Subject: Re: 9.1 minimal ram requirements From: Adrian Chadd To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: Marten Vijn , Sergey Kandaurov , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 04:08:44 -0000 .. has someone filed a PR for it? Adrian From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 05:03:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B4F5846; Mon, 24 Dec 2012 05:03:10 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCFC8FC0A; Mon, 24 Dec 2012 05:03:09 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id qBO4bkdW049692; Sun, 23 Dec 2012 21:37:46 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id qBO4bkEq049691; Sun, 23 Dec 2012 21:37:46 -0700 (MST) (envelope-from ken) Date: Sun, 23 Dec 2012 21:37:46 -0700 From: "Kenneth D. Merry" To: Adrian Chadd Subject: Re: 9.1 minimal ram requirements Message-ID: <20121224043746.GA49438@nargothrond.kdm.org> References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: Marten Vijn , Sergey Kandaurov , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 05:03:10 -0000 The reason it grabs RAM up front is that it was written for an embedded platform where memory allocations might fail later on after things had been running and memory got fragmented. At this point, no, it doesn't need to allocate all of its memory up front. I actually need to put some effort into right-sizing the memory footprint, but that will take adding some fields to the path inquiry CCB so it knows what the capabilities of the target adapter are. (And that typically takes a CAM version bump, which breaks the ABI...) In any case, the memory footprint (and any possible side effects from the mpt driver with FC boards) are why I put the disable switch in. If there is memory allocated when it is disabled, then that is a bug. I'm on vacation so it'll be a little while before I'm in a position to fix this, but hopefully the disable switch should help anyone running with smaller amounts of memory. Ken On Sat, Dec 22, 2012 at 22:32:07 -0800, Adrian Chadd wrote: > Ken, > > Does CAM CTL really need to pre-allocate 35MB of RAM at startup? > > > > Adrian > > On 22 December 2012 16:45, Sergey Kandaurov wrote: > > On 23 December 2012 03:40, Marten Vijn wrote: > >> On 12/23/2012 12:27 AM, Jakub Lach wrote: > >>> > >>> Guys, I've heard about some absurd RAM requirements > >>> for 9.1, has anybody tested it? > >>> > >>> e.g. > >>> > >>> http://forums.freebsd.org/showthread.php?t=36314 > >> > >> > >> jup, I can comfirm this with nanobsd (cross) compiled > >> for my soekris net4501 which has 64 MB mem: > >> > >> from dmesg: real memory = 67108864 (64 MB) > >> > >> while the same config compiled against a 9.0 tree still works... > >> > > > > This (i.e. the "kmem_map too small" message seen with kernel memory > > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > > quite a big kernel memory consumer. > > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. > > A longer term workaround could be to postpone those memory allocations > > until the first call to CTL. > > > > # cam ctl init allocates roughly 35 MB of kernel memory at once > > # three memory pools, somewhat under M_DEVBUF, and memory disk > > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > > > Type InUse MemUse HighUse Requests Size(s) > > devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 > > ctlmem 5062 10113K - 5062 64,2048 > > ctlblk 200 800K - 200 4096 > > ramdisk 1 4096K - 1 > > ctlpool 532 138K - 532 16,512 > > > > -- > > wbr, > > pluknet > > _______________________________________________ > > 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" -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 09:31:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69C00338 for ; Mon, 24 Dec 2012 09:31:38 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8F08FC0A for ; Mon, 24 Dec 2012 09:31:37 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Tn4Nf-0006or-NK for freebsd-stable@freebsd.org; Mon, 24 Dec 2012 01:31:31 -0800 Date: Mon, 24 Dec 2012 01:31:31 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1356341491715-5771862.post@n5.nabble.com> In-Reply-To: References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> <20121223150954.B81991@sola.nimnet.asn.au> <20121224041301.W83325@sola.nimnet.asn.au> Subject: Re: 9.1 minimal ram requirements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 09:31:38 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=174671 -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583p5771862.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 13:27:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A5B7E6B; Mon, 24 Dec 2012 13:27:39 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-x22a.google.com (wg-in-x022a.1e100.net [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 7C61F8FC0A; Mon, 24 Dec 2012 13:27:38 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so2623138wgb.5 for ; Mon, 24 Dec 2012 05:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YRIlK9VqdWvMLcDxEsIZchxkWPzUjTcbf/RK2Id9+MI=; b=C7xkjetrwTBbNKuYDBRhBegxYEnLMIUgTNvrf6549CDR1YuXLIF28mdpXRZOPbe0tl KDE+GUNfJOVQlNNgvXidq9LdNEq/c4oeWaUyNFZUDYB4BF8RWzyiHv7UlWSlasIPG3p2 8gJjOxlgk5bb9wBRWjDEQ6tjJRvUhTvXzDG/g10PGeLVjVxOPf22fUgmlhX43Kcd018I 64gvwQsE7U4SzJmf67NylFaEHen/P1R0+Q1Wa8pmHtkEIuyAmyhsucJV/qmg85dqOHpu 5JTn2/LU9V0TlvlTwZfkVwI61qXsmnbZDNx/7TTxlS+w9s/hQY2tc5XkO7BYMeKfNsip vZqQ== MIME-Version: 1.0 Received: by 10.180.81.39 with SMTP id w7mr35005102wix.15.1356355657157; Mon, 24 Dec 2012 05:27:37 -0800 (PST) Received: by 10.216.172.197 with HTTP; Mon, 24 Dec 2012 05:27:36 -0800 (PST) In-Reply-To: <50D6FDBD.6000401@FreeBSD.org> References: <50B6598B.20200@FreeBSD.org> <50D6F901.7050206@FreeBSD.org> <50D6FDBD.6000401@FreeBSD.org> Date: Mon, 24 Dec 2012 15:27:36 +0200 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Kimmo Paasiala To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 13:27:39 -0000 On Sun, Dec 23, 2012 at 2:49 PM, Andriy Gapon wrote: > on 23/12/2012 14:34 Kimmo Paasiala said the following: >> On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon wrote: >>> >>> I have MFCed the following change, so please double-check if you might be >>> affected. Preferably before upgrading :-) >>> >>> on 28/11/2012 20:35 Andriy Gapon said the following: >>>> >>>> Recently some changes were made to how a root pool is opened for root filesystem >>>> mounting. Previously the root pool had to be present in zpool.cache. Now it is >>>> automatically discovered by probing available GEOM providers. >>>> The new scheme is believed to be more flexible. For example, it allows to prepare >>>> a new root pool at one system, then export it and then boot from it on a new >>>> system without doing any extra/magical steps with zpool.cache. It could also be >>>> convenient after zpool split and in some other situations. >>>> >>>> The change was introduced via multiple commits, the latest relevant revision in >>>> head is r243502. The changes are partially MFC-ed, the remaining parts are >>>> scheduled to be MFC-ed soon. >>>> >>>> I have received a report that the change caused a problem with booting on at least >>>> one system. The problem has been identified as an issue in local environment and >>>> has been fixed. Please read on to see if you might be affected when you upgrade, >>>> so that you can avoid any unnecessary surprises. >>>> >>>> You might be affected if you ever had a pool named the same as your current root >>>> pool. And you still have any disks connected to your system that belonged to that >>>> pool (in whole or via some partitions). And that pool was never properly >>>> destroyed using zpool destroy, but merely abandoned (its disks >>>> re-purposed/re-partitioned/reused). >>>> >>>> If all of the above are true, then I recommend that you run 'zdb -l ' for >>>> all suspect disks and their partitions (or just all disks and partitions). If >>>> this command reports at least one valid ZFS label for a disk or a partition that >>>> do not belong to any current pool, then the problem may affect you. >>>> >>>> The best course is to remove the offending labels. >>>> >>>> If you are affected, please follow up to this email. >> >> Much appreciated! >> >> I have verified that my system is not affected. >> >> One question, do I have to rewrite the zfs gpt boot loader >> (/boot/gptzfsboot) onto the freebsd-boot partition to make use of this >> change? > > This change is kernel-level only. There is no interaction with boot blocks. > > -- > Andriy Gapon I can happily report that booting from the ZFS pool works on my 9-STABLE system without the zpool.cache file. Thanks, merry christmas and happy new year! -Kimmo From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 13:52:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB6AE52E; Mon, 24 Dec 2012 13:52:51 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id 0550A8FC15; Mon, 24 Dec 2012 13:52:50 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jc3so3297322bkc.7 for ; Mon, 24 Dec 2012 05:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=8FrqhWZqcwg9bcyGOwOOnEHVTO0qIwnV92SOIIEF69c=; b=kLCRrqiirnu8/rRG987dS1okVfqY5MGTesmFJ2iyPkgTXjN7epwp/uMj/IK8EwtoKk oBAQtgC/vr3yUf3ANJzjAq1/uIVv3O7duWYd91nSDrxElh8NpzbhR+kIaTsZMneh4dGL +MzAdUXdeezqGflNd33BvzYBYdtv/JtIBInuyma3/S1DQYxVZrsZZjBWmf0URNN71fsm z7U7GE7J4SUHg1MhW9O3IHvjFdzKiDdTUH0r/R7s0vlCogYkog2MNbEACESxUsOWClW1 SMOc/d80YqqCKZ7UoXl7Md0X5ufmtajE2nI5W3CDWRYkiANf7ClYfMSshHIIw02FKCna Z10A== X-Received: by 10.204.136.207 with SMTP id s15mr10514816bkt.5.1356357162692; Mon, 24 Dec 2012 05:52:42 -0800 (PST) Received: from Melon.malikania.fr (235.21.102.84.rev.sfr.net. [84.102.21.235]) by mx.google.com with ESMTPS id y11sm15218476bkw.8.2012.12.24.05.52.40 (version=SSLv3 cipher=OTHER); Mon, 24 Dec 2012 05:52:41 -0800 (PST) Message-ID: <50D85E24.7000108@gmail.com> Date: Mon, 24 Dec 2012 14:52:36 +0100 From: David Demelier User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org Subject: Kernel panic when playing games/iourbanterror Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 13:52:51 -0000 Hello, When playing a lot Urban Terror, the system panic with ACPI related issues : Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xffffffff802c6f15 stack pointer = 0x28:0xffffff80d89ac6c0 frame pointer = 0x28:0x0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1288 (hald) trap number = 9 panic: general protection fault cpuid = 1 Uptime: 1h52m22s Dumping 596 out of 3054 MB:..3%..11%..22%..33%..41%..51%..62%..73%..81%..92% Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 224 __asm("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0xffffff80d89ac6c0 No source file for address 0xffffff80d89ac6c0. (kgdb) backtrace #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 #1 0x0000000000000004 in ?? () #2 0xffffffff804f3ae6 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #3 0xffffffff804f3fa9 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:636 #4 0xffffffff806fcfa9 in trap_fatal (frame=0x9, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #5 0xffffffff806fd554 in trap (frame=0xffffff80d89ac610) at /usr/src/sys/amd64/amd64/trap.c:599 #6 0xffffffff806e81bf in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff802c6f15 in AcpiUtUpdateObjectReference ( Object=0xfffffe0001824a80, Action=0) at /usr/src/sys/contrib/dev/acpica/utilities/utdelete.c:563 #8 0xffffffff802b77a4 in AcpiExResolveNodeToValue ( ObjectPtr=0xfffffe0001a2c2e0, WalkState=0xfffffe0001a2c000) at /usr/src/sys/contrib/dev/acpica/executer/exresnte.c:184 #9 0xffffffff802b7ad3 in AcpiExResolveToValue (StackPtr=0xfffffe0001a2c2e0, WalkState=0xfffffe0001a2c000) at /usr/src/sys/contrib/dev/acpica/executer/exresolv.c:124 #10 0xffffffff802ac433 in AcpiDsEvaluateNamePath (WalkState=0xfffffe0001a2c000) at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:886 ---Type to continue, or q to quit--- #11 0xffffffff802aceef in AcpiDsExecEndOp (WalkState=0xfffffe0001a2c000) at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:436 #12 0xffffffff802c05ba in AcpiPsParseLoop (WalkState=0xfffffe0001a2c000) at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 #13 0xffffffff802c10a8 in AcpiPsParseAml (WalkState=0xfffffe0001a2c000) at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 #14 0xffffffff802c1d45 in AcpiPsExecuteMethod (Info=0xfffffe0033df8540) at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 #15 0xffffffff802bb784 in AcpiNsEvaluate (Info=0xfffffe0033df8540) at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 #16 0xffffffff802bec91 in AcpiEvaluateObject (Handle=0xfffffe00017f7b80, Pathname=0xffffffff8078229f "_BST", ExternalParams=0x0, ReturnBuffer=0xffffff80d89ac960) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfeval.c:289 #17 0xffffffff80309802 in acpi_cmbat_get_bst (arg=Variable "arg" is not available. ) at /usr/src/sys/dev/acpica/acpi_cmbat.c:257 #18 0xffffffff80309af8 in acpi_cmbat_bst (dev=0xfffffe0001936400, bstp=0xfffffe008b319400) at /usr/src/sys/dev/acpica/acpi_cmbat.c:418 #19 0xffffffff8045bd22 in devfs_ioctl_f (fp=0xfffffe001ba256e0, com=3231990289, data=Variable "data" is not available. ) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #20 0xffffffff8053a23d in kern_ioctl (td=0xfffffe00039ae8e0, fd=Variable "fd" is not available. ) at file.h:293 #21 0xffffffff8053a4ad in sys_ioctl (td=0xfffffe00039ae8e0, uap=0xffffff80d89acb70) at /usr/src/sys/kern/sys_generic.c:691 ---Type to continue, or q to quit--- #22 0xffffffff806fc902 in amd64_syscall (td=0xfffffe00039ae8e0, traced=0) at subr_syscall.c:135 #23 0xffffffff806e84a7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #24 0x0000000801d89c5c in ?? () Previous frame inner to this frame (corrupt stack?) Before the panic, a lot of ACPI Error appears in dmesg like that : ACPI Error: Method execution failed [\\_SB_.BAT0._UID] (Node 0xfffffe00017f7b00), AE_AML_NO_OPERAND (20110527/uteval-113) ACPI Error: No object attached to node 0xfffffe00017f7b00 (20110527/exresnte-139) ACPI Error: Method execution failed [\\_SB_.BAT0._UID] (Node 0xfffffe00017f7b00), AE_AML_NO_OPERAND (20110527/uteval-113) ACPI Error: No object attached to node 0xfffffe00017f7b00 (20110527/exresnte-139) This happens on 9.1-RELEASE amd64 Cheers, From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 14:53:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C697237 for ; Mon, 24 Dec 2012 14:53:26 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id E6D778FC15 for ; Mon, 24 Dec 2012 14:53:25 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jc3so3360712bkc.21 for ; Mon, 24 Dec 2012 06:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZlS9AIiuAuMrxYtS4udkC8YoHtnb4tDCmQMB5pfeDSk=; b=ioanEIpBI0h6mG4xyzuAfz97obR20HwCQ0WitLmxj5oKK1QcCx3sHDEsesPSz7RCCH 0t77TyawIUdPvr6MGNJqVkrX6OZ5uBQR8do7btWH8wfgvEpCH6C71J68tnG4XkCL1t5P rMu5dRpiJ1OhUOyww3cAoAc01VtemeN2afR3sI6H4HWI6F5xiRw+qxciYUJOp0ethYw7 2wJTvSXryYh4kiVHCMM1pwUIXqtbt99W4w3Dbuh1SOi//uVno2zQftEBVbCIQfT5GIY4 fx3q+Jlu6yQ+TYmHjww8KH6r3YF+bq7BowjlQgyzElSrKF7zfSvIYhhRm4Fy/ds+GTZK UV+Q== X-Received: by 10.204.5.141 with SMTP id 13mr10452006bkv.35.1356360804499; Mon, 24 Dec 2012 06:53:24 -0800 (PST) Received: from [192.168.50.105] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id u3sm15344338bkw.9.2012.12.24.06.53.22 (version=SSLv3 cipher=OTHER); Mon, 24 Dec 2012 06:53:23 -0800 (PST) Message-ID: <50D86C61.50507@gmail.com> Date: Mon, 24 Dec 2012 15:53:21 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marin Atanasov Nikolov Subject: Re: PKGNG Monitoring in Zabbix References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 14:53:26 -0000 Marin Atanasov Nikolov schreef: > Hey, > > Looks like the end of the World is postponed, so I've though that now I > have some time to document some stuff :) > > The documentations are about monitoring your PKGNG package database in > Zabbix. > > Part I explains how to monitor your database and have graphs of the number > of packages and disk space taken by packages on your FreeBSD system. > > Part II talks about how to perform audits of your package database for > things like missing package dependencies and packages that are known to > vulnerable. > > You can find the documentations at the links below: > > * http://unix-heaven.org/monitorig-pkgng-in-zabbix-part-i > * http://unix-heaven.org/monitorig-pkgng-in-zabbix-part-ii > > Hope you like them, and Happy Holidays! :) > > Regards, > Marin > Thanks, allways nice to see things in my zabbix console I will try it out when i find some time : ) gr Johan Hendriks From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 14:57:39 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95A01372; Mon, 24 Dec 2012 14:57:39 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.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 2AEC98FC0A; Mon, 24 Dec 2012 14:57:38 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 24 Dec 2012 09:57:38 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr17.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BVV29778; Mon, 24 Dec 2012 09:57:37 -0500 X-Auth-ID: anat Received: from pool-173-70-92-11.nwrknj.fios.verizon.net (HELO [192.168.1.8]) ([173.70.92.11]) by smtp01.lnh.mail.rcn.net with ESMTP; 24 Dec 2012 09:57:38 -0500 Message-ID: <50D86D60.2060506@aldan.algebra.com> Date: Mon, 24 Dec 2012 09:57:36 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120820 Thunderbird/14.0 MIME-Version: 1.0 To: Chris Rees Subject: Re: What is "negative group permissions"? (Re: narawntapu security run output) References: <201212230805.qBN850Pj083122@narawntapu.narawntapu> <50D7287C.7020802@aldan.algebra.com> <20121223162332.GA38788@pit.databus.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Barney Wolff , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 14:57:39 -0000 On 23.12.2012 11:48, Chris Rees wrote: > They involve a lot of thought to get right, as well as chmod g-w on > something where you probably meant chmod go-w is a disastrous but > (perhaps) common error. Chris Well, in (over 20) years of dealing with Unix, I've never made a mistake like that, nor do I understand, how it can be considered "common" ... Got to admit, I was surprised to see it. It made me think, I do not understand something -- or that FreeBSD is becoming overly paternalistic. It turned out to be the latter... I doubt, it is useful. Worse, issuing such warnings routinely, only reinforces the unfortunate misconceptions like the one Barney demonstrated in this thread. When originally added, the check was meant to be off by default: r215213 | brooks | 2010-11-12 19:40:43 -0500 (ÐÔ, 12 ÌÉÓ 2010) | 7 lines Add an (off by default) check for negative permissions (where the group on a object has less permissions that everyone). These permissions will not work reliably over NFS if you have more than 14 supplemental groups and are usually not what you mean. MFC after: 1 week perhaps, it should have remained off? Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 15:28:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0015FCDA for ; Mon, 24 Dec 2012 15:28:15 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9F58C8FC0A for ; Mon, 24 Dec 2012 15:28:14 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tn9x0-0007VR-Js for freebsd-stable@freebsd.org; Mon, 24 Dec 2012 16:28:26 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Dec 2012 16:28:22 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Dec 2012 16:28:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: What is "negative group permissions"? (Re: narawntapu security run output) Date: Mon, 24 Dec 2012 15:27:57 +0000 (UTC) Lines: 29 Message-ID: References: <201212230805.qBN850Pj083122@narawntapu.narawntapu> <50D7287C.7020802@aldan.algebra.com> <20121223162332.GA38788@pit.databus.com> <50D86D60.2060506@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20121121 Firefox/10.0.11) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 15:28:16 -0000 Mikhail T. aldan.algebra.com> writes: > > On 23.12.2012 11:48, Chris Rees wrote: > > They involve a lot of thought to get right, as well as chmod g-w on > > something where you probably meant chmod go-w is a disastrous but > > (perhaps) common error. Chris > > Well, in (over 20) years of dealing with Unix, I've never made a mistake > like that, nor do I understand, how it can be considered "common" ... > Got to admit, I was surprised to see it. It made me think, I do not > understand something -- or that FreeBSD is becoming overly > paternalistic. It turned out to be the latter... > > I doubt, it is useful. Worse, issuing such warnings routinely, only > reinforces the unfortunate misconceptions like the one Barney > demonstrated in this thread. When originally added, the check was meant > to be off by default: > ... > perhaps, it should have remained off? Yours, Those security checks are for a reason - people make mistakes (even a perfect guy like you will have a "head in a brown bag" time). It is better to get a heads-up, then think about it and turn it off (customize) if considered unneeded. jb From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 15:37:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09A1BE4 for ; Mon, 24 Dec 2012 15:37:50 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mx1.freebsd.org (Postfix) with ESMTP id 600718FC16 for ; Mon, 24 Dec 2012 15:37:48 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id e4so8777469lag.38 for ; Mon, 24 Dec 2012 07:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=REusAg9V4odcfgo2zOr6Ybn36953GkOKNEVRtkcdRBo=; b=neEu0PTutDr5UVPqHyLRdNtfBdjjqxyxECqzPwK9nehRy+JTYRsEb/mqdj/AeukaT0 hou4DpwmBfT1wakoiYDXwCbHOVI+lmRsS+TO2TSMTMSRKCn5NBGsp12RdKatdOCTctUL imaXLqPiYAqmtCDS+t7JfifubFH0zujhTv/wE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=REusAg9V4odcfgo2zOr6Ybn36953GkOKNEVRtkcdRBo=; b=OTvu7C/t1Jmw1dF9Cc6XRpFgiWzGOyM6Sc5wKuzqTdYurluzxQRZjuBtUfLrIhTx3U FAbyCOpX2bwdimuPtpFS09J/czAYv+CTEOIequbw/bS5SqwYVNOO7aB+/HTSOralOD87 WukQHNeutLDKGkZsX5GMjaz0s032i5t58kApKExHmcoYQ1h90mYQ9Jzhizf5TFs+TtKS qhacIxKEuQ83nmB5Qr/xNLYxgX0fFxOcK/Hbt6A5udCIYtiQOmRfmq9L9ofLx/VzR4RY beoyqhb1HMRIuag3AXb0TacN14uZ7xXsFG/SBz8asIeCtH0DehQZJ3tWKUJGQ1nJPI0V defQ== Received: by 10.112.29.104 with SMTP id j8mr8934537lbh.0.1356363467649; Mon, 24 Dec 2012 07:37:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.162.100 with HTTP; Mon, 24 Dec 2012 07:37:16 -0800 (PST) In-Reply-To: References: <201212230805.qBN850Pj083122@narawntapu.narawntapu> <50D7287C.7020802@aldan.algebra.com> <20121223162332.GA38788@pit.databus.com> <50D86D60.2060506@aldan.algebra.com> From: Eitan Adler Date: Mon, 24 Dec 2012 10:37:16 -0500 Message-ID: Subject: Re: What is "negative group permissions"? (Re: narawntapu security run output) To: jb Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmgPA0AYotR7ZXfj8GFQH5PyCkExYjpLToUBe+CRsSrRuSTEbulqKaX0B+7gaaZUwdiP7fn Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 15:37:50 -0000 On 24 December 2012 10:27, jb wrote: > Those security checks are for a reason - people make mistakes (even a perfect > guy like you will have a "head in a brown bag" time). > It is better to get a heads-up, then think about it and turn it off (customize) > if considered unneeded. +1. Default to helping the new user (or the user that makes mistakes). -- Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 16:01:33 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F2FD6F1; Mon, 24 Dec 2012 16:01:33 +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 512118FC14; Mon, 24 Dec 2012 16:01:31 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA05000; Mon, 24 Dec 2012 18:01:26 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50D87C56.70709@FreeBSD.org> Date: Mon, 24 Dec 2012 18:01:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines References: <1824023197.20121223142308@takeda.tk> In-Reply-To: <1824023197.20121223142308@takeda.tk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 16:01:33 -0000 on 24/12/2012 00:23 Derek Kulinski said the following: > Dumping 3701 out of 8072 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% So do you have the crash dump(s)? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 18:19:05 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2392A6D8; Mon, 24 Dec 2012 18:19:05 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 977B18FC16; Mon, 24 Dec 2012 18:19:04 +0000 (UTC) Received: from localhost.takeda.tk (takeda-ws2.lan [10.0.0.123]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id qBOIJ2Gs012272 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Dec 2012 10:19:03 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Mon, 24 Dec 2012 10:17:19 -0800 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <331959998.20121224101719@takeda.tk> To: Andriy Gapon Subject: Re: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines In-Reply-To: <50D87C56.70709@FreeBSD.org> References: <1824023197.20121223142308@takeda.tk> <50D87C56.70709@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 18:19:05 -0000 Hello Andriy, Monday, December 24, 2012, 8:01:26 AM, you wrote: > on 24/12/2012 00:23 Derek Kulinski said the following: >> Dumping 3701 out of 8072 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > So do you have the crash dump(s)? Yes, but they are 3.5GB each. I attached text dump to GNATS but I can resend it to you (I don't know if it's ok to send attachments to the mailing list). If you would prefer I could give you access to the box. -- Best regards, Derek mailto:takeda@takeda.tk -- Programmer - A red-eyed, mumbling mammal capable of conversing with inanimate objects. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 18:51:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4E12B1A; Mon, 24 Dec 2012 18:51:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by mx1.freebsd.org (Postfix) with ESMTP id 2A01C8FC12; Mon, 24 Dec 2012 18:51:50 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t11so3394658wey.40 for ; Mon, 24 Dec 2012 10:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D2tIgKESpXDbECiYgP5fQYTDsISPTpt6lYjLGsnyKXA=; b=IJLvXpi+MyCl8He70Qz0KS3J9hS9GIumSFBh6fKo4lGtllBOAMYd8gZ5Phrnv0GJ1R 83sHa4uIKpbQbymAdJ7I9G6nUzEsUubg3hIED6oxstbTxnB5kHN9wr/7Vb+Y51IyS96r Z0i8dmGJMh20KZlpr/8RUfC/GwLgRPteltQN1mvEgbnkNsKwosGVOzVOdwRWkdUGtgX2 qM6UiHjHlijEQ0CYZvUZ7XtyiFXEGBO4U8C5aWDD4t2eQnuWQW3Hpo+PpMchVHtKgDLa BVuUDUx8HkpSdnEGW6Udkr0Q4DQxPCg+FvGGf10wnevggwbMAQNerksz2a1/3z/sBZ1l HpjQ== MIME-Version: 1.0 Received: by 10.180.88.40 with SMTP id bd8mr28132509wib.33.1356375104390; Mon, 24 Dec 2012 10:51:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Mon, 24 Dec 2012 10:51:44 -0800 (PST) In-Reply-To: <50D85E24.7000108@gmail.com> References: <50D85E24.7000108@gmail.com> Date: Mon, 24 Dec 2012 10:51:44 -0800 X-Google-Sender-Auth: bD5pPUlxVeJaaM9GauL0rSnBjA0 Message-ID: Subject: Re: Kernel panic when playing games/iourbanterror From: Adrian Chadd To: David Demelier Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 18:51:51 -0000 Hi, Please file a PR? We can bump it to the ACPI person who has been busily making this stuff updated and stable. Thanks! Adrian On 24 December 2012 05:52, David Demelier wrote: > Hello, > > When playing a lot Urban Terror, the system panic with ACPI related issues : > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x20:0xffffffff802c6f15 > stack pointer = 0x28:0xffffff80d89ac6c0 > frame pointer = 0x28:0x0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1288 (hald) > trap number = 9 > panic: general protection fault > cpuid = 1 > Uptime: 1h52m22s > Dumping 596 out of 3054 MB:..3%..11%..22%..33%..41%..51%..62%..73%..81%..92% > > Reading symbols from /boot/modules/vboxdrv.ko...done. > Loaded symbols for /boot/modules/vboxdrv.ko > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > 224 __asm("movq %%gs:0,%0" : "=r" (td)); > (kgdb) list *0xffffff80d89ac6c0 > No source file for address 0xffffff80d89ac6c0. > (kgdb) backtrace > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > #1 0x0000000000000004 in ?? () > #2 0xffffffff804f3ae6 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:448 > #3 0xffffffff804f3fa9 in panic (fmt=0x1
) > at /usr/src/sys/kern/kern_shutdown.c:636 > #4 0xffffffff806fcfa9 in trap_fatal (frame=0x9, eva=Variable "eva" is not > available. > ) > at /usr/src/sys/amd64/amd64/trap.c:857 > #5 0xffffffff806fd554 in trap (frame=0xffffff80d89ac610) > at /usr/src/sys/amd64/amd64/trap.c:599 > #6 0xffffffff806e81bf in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:228 > #7 0xffffffff802c6f15 in AcpiUtUpdateObjectReference ( > Object=0xfffffe0001824a80, Action=0) > at /usr/src/sys/contrib/dev/acpica/utilities/utdelete.c:563 > #8 0xffffffff802b77a4 in AcpiExResolveNodeToValue ( > ObjectPtr=0xfffffe0001a2c2e0, WalkState=0xfffffe0001a2c000) > at /usr/src/sys/contrib/dev/acpica/executer/exresnte.c:184 > #9 0xffffffff802b7ad3 in AcpiExResolveToValue (StackPtr=0xfffffe0001a2c2e0, > WalkState=0xfffffe0001a2c000) > at /usr/src/sys/contrib/dev/acpica/executer/exresolv.c:124 > #10 0xffffffff802ac433 in AcpiDsEvaluateNamePath > (WalkState=0xfffffe0001a2c000) > at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:886 > ---Type to continue, or q to quit--- > #11 0xffffffff802aceef in AcpiDsExecEndOp (WalkState=0xfffffe0001a2c000) > at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:436 > #12 0xffffffff802c05ba in AcpiPsParseLoop (WalkState=0xfffffe0001a2c000) > at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 > #13 0xffffffff802c10a8 in AcpiPsParseAml (WalkState=0xfffffe0001a2c000) > at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 > #14 0xffffffff802c1d45 in AcpiPsExecuteMethod (Info=0xfffffe0033df8540) > at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 > #15 0xffffffff802bb784 in AcpiNsEvaluate (Info=0xfffffe0033df8540) > at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 > #16 0xffffffff802bec91 in AcpiEvaluateObject (Handle=0xfffffe00017f7b80, > Pathname=0xffffffff8078229f "_BST", ExternalParams=0x0, > ReturnBuffer=0xffffff80d89ac960) > at /usr/src/sys/contrib/dev/acpica/namespace/nsxfeval.c:289 > #17 0xffffffff80309802 in acpi_cmbat_get_bst (arg=Variable "arg" is not > available. > ) > at /usr/src/sys/dev/acpica/acpi_cmbat.c:257 > #18 0xffffffff80309af8 in acpi_cmbat_bst (dev=0xfffffe0001936400, > bstp=0xfffffe008b319400) at /usr/src/sys/dev/acpica/acpi_cmbat.c:418 > #19 0xffffffff8045bd22 in devfs_ioctl_f (fp=0xfffffe001ba256e0, > com=3231990289, data=Variable "data" is not available. > ) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > #20 0xffffffff8053a23d in kern_ioctl (td=0xfffffe00039ae8e0, fd=Variable > "fd" is not available. > ) at file.h:293 > #21 0xffffffff8053a4ad in sys_ioctl (td=0xfffffe00039ae8e0, > uap=0xffffff80d89acb70) at /usr/src/sys/kern/sys_generic.c:691 > ---Type to continue, or q to quit--- > #22 0xffffffff806fc902 in amd64_syscall (td=0xfffffe00039ae8e0, traced=0) > at subr_syscall.c:135 > #23 0xffffffff806e84a7 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:387 > #24 0x0000000801d89c5c in ?? () > Previous frame inner to this frame (corrupt stack?) > > Before the panic, a lot of ACPI Error appears in dmesg like that : > > ACPI Error: Method execution failed [\\_SB_.BAT0._UID] (Node > 0xfffffe00017f7b00), AE_AML_NO_OPERAND (20110527/uteval-113) > ACPI Error: No object attached to node 0xfffffe00017f7b00 > (20110527/exresnte-139) > ACPI Error: Method execution failed [\\_SB_.BAT0._UID] (Node > 0xfffffe00017f7b00), AE_AML_NO_OPERAND (20110527/uteval-113) > ACPI Error: No object attached to node 0xfffffe00017f7b00 > (20110527/exresnte-139) > > This happens on 9.1-RELEASE amd64 > > Cheers, > _______________________________________________ > 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 Dec 24 19:58:20 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCB53A14 for ; Mon, 24 Dec 2012 19:58:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4708FC0C for ; Mon, 24 Dec 2012 19:58:19 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qBOJwIjX002409 for ; Mon, 24 Dec 2012 11:58:18 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qBOJwI1B002408 for stable@freebsd.org; Mon, 24 Dec 2012 11:58:18 -0800 (PST) (envelope-from david) Date: Mon, 24 Dec 2012 11:58:18 -0800 From: David Wolfskill To: stable@freebsd.org Subject: stable/9 i386 panic [ACPI/timer?] Message-ID: <20121224195818.GA1867@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 19:58:20 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I finally(!) got around to enabling crash dumps on the primary machine here at the house ... and managed to make use of it (unfortunately). I've copied the relevant files (both those from /var/crash and dmesg.boot) so they should be visibale at (though only the dmesg.boot, core.text.0, & info.0 files should be fetchable for now). [I'll make the vmcore.0 available to individuals who wish to work on the problem; please contact me to arrange this.] Here's a bit of information excerpted from core.text.0: Mon Dec 24 11:16:04 PST 2012 FreeBSD albert.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #434 24= 4582M: Sat Dec 22 05:06:29 PST 2012 root@freebeast.catwhisker.org:/usr/= obj/usr/src/sys/ALBERT i386 Note that while the version string says "244582M": * Userland was at r244608. * The "Modification" was merely a change to src/sys/newvers.sh to re-factor the extraction of the version string. panic: page fault Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x34 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0ad475c stack pointer =3D 0x28:0xc6fba9d8 frame pointer =3D 0x28:0xc6fbaa18 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 11 (idle: cpu0) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(c0ffbab8,46,1,ca931e80,0,...) at 0xc051ef76 =3D db_tr= ace_self_wrapper+0x36/frame 0xc6fba740 kdb_backtrace(c1033ff1,0,c0e75cc4,c6fba7ec,c71f08d0,...) at 0xc0afc400 =3D = kdb_backtrace+0x30/frame 0xc6fba7a0 panic(c0e75cc4,c1034ddb,c71f0a84,1,1,...) at 0xc0ac763c =3D panic+0x1bc/fra= me 0xc6fba7e0 trap_fatal(28,7fffffff,3,0,28,...) at 0xc0e35560 =3D trap_fatal+0x340/frame= 0xc6fba828 trap_pfault(34,c,1,c11a68b0,c6fba940,...) at 0xc0e358cb =3D trap_pfault+0x3= 5b/frame 0xc6fba8a0 trap(c6fba998) at 0xc0e34e13 =3D trap+0x443/frame 0xc6fba98c calltrap() at 0xc0e1e86c =3D calltrap+0x6/frame 0xc6fba98c --- trap 0xc, eip =3D 0xc0ad475c, esp =3D 0xc6fba9d8, ebp =3D 0xc6fbaa18 --- tc_windup(1,0,c0ff3ba6,21c,0,...) at 0xc0ad475c =3D tc_windup+0x1c/frame 0x= c6fbaa18 hardclock_cnt(1,0,0,3,0,...) at 0xc0a77e39 =3D hardclock_cnt+0x2e9/frame 0x= c6fbaa68 handleevents(c6fbaaf8,2,46,c71f08d0,c6fbaae4,...) at 0xc0e3c534 =3D handlee= vents+0x184/frame 0xc6fbaac0 timercb(c7564064,0,c76a82f0,c6fbab58,c0a99a0e,...) at 0xc0e3d1a1 =3D timerc= b+0x281/frame 0xc6fbab14 hpet_intr_single(c7564064,c7569780,0,c6fbabbc,c6fbab78,...) at 0xc053a345 = =3D hpet_intr_single+0x195/frame 0xc6fbab40 hpet_intr(c7564000,0,c71f08d0,14,c723b710,...) at 0xc053a3cf =3D hpet_intr+= 0x6f/frame 0xc6fbab58 intr_event_handle(c723c280,c6fbabbc,c6fbab94,0,c7182600,...) at 0xc0a99c5c = =3D intr_event_handle+0x7c/frame 0xc6fbab78 intr_execute_handlers(c723b710,c6fbabbc,0) at 0xc0e4c552 =3D intr_execute_h= andlers+0x42/frame 0xc6fbab98 lapic_handle_intr(33,c6fbabbc) at 0xc0e4f50d =3D lapic_handle_intr+0x3d/fra= me 0xc6fbabac Xapic_isr1() at 0xc0e1ec35 =3D Xapic_isr1+0x35/frame 0xc6fbabac --- interrupt, eip =3D 0xc0e1a202, esp =3D 0xc6fbabfc, ebp =3D 0xc6fbac3c -= -- acpi_cpu_c1(0,c6fbac58,c0e250a6,0,c1198018,...) at 0xc0e1a202 =3D acpi_cpu_= c1+0x2/frame 0xc6fbac3c cpu_idle_acpi(0,c1198018,c6fbacd0,c0aee519,0,...) at 0xc0e24fff =3D cpu_idl= e_acpi+0x2f/frame 0xc6fbac48 cpu_idle(0,2,c0ffa49a,a36,c71f08d0,...) at 0xc0e250a6 =3D cpu_idle+0x96/fra= me 0xc6fbac58 sched_idletd(0,c6fbad08,0,0,c0aee250,...) at 0xc0aee519 =3D sched_idletd+0x= 2c9/frame 0xc6fbacd0 fork_exit(c0aee250,0,c6fbad08) at 0xc0a977c7 =3D fork_exit+0x67/frame 0xc6f= bacf4 fork_trampoline() at 0xc0e1e8e4 =3D fork_trampoline+0x8/frame 0xc6fbacf4 --- trap 0, eip =3D 0, esp =3D 0xc6fbad40, ebp =3D 0 --- Uptime: 7h11m46s Physical memory: 3045 MB #0 doadump (textdump=3D) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3D) at pcpu.h:249 #1 0xc0ac71fa in kern_reboot (howto=3DUnhandled dwarf expression opcode 0x= c0 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xc0ac7688 in panic (fmt=3DUnhandled dwarf expression opcode 0xc0 ) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xc0e35560 in trap_fatal (frame=3D,=20 eva=3D) at /usr/src/sys/i386/i386/trap.c:1043 #4 0xc0e358cb in trap_pfault (frame=3D, usermode=3DUn= handled dwarf expression opcode 0xc3 ) at /usr/src/sys/i386/i386/trap.c:858 #5 0xc0e34e13 in trap (frame=3D) at /usr/src/sys/i386/i386/trap.c:555 #6 0xc0e1e86c in calltrap () at /tmp/exception-SmXQMs.s:94 #7 0xc0ad475c in tc_windup () at /usr/src/sys/kern/kern_tc.c:450 #8 0xc0a77e39 in hardclock_cnt (usermode=3D) at /usr/src/sys/kern/kern_clock.c:556 #9 0xc0e3c534 in handleevents (now=3D,=20 fake=3D) at /usr/src/sys/kern/kern_clocksource.c:2= 15 #10 0xc0e3d1a1 in timercb (et=3DUnhandled dwarf expression opcode 0xc0 ) at /usr/src/sys/kern/kern_clocksource.c:390 #11 0xc053a345 in hpet_intr_single (arg=3D) at /usr/src/sys/dev/acpica/acpi_hpet.c:260 #12 0xc053a3cf in hpet_intr (arg=3D) at /usr/src/sys/dev/acpica/acpi_hpet.c:278 #13 0xc0a99c5c in intr_event_handle (ie=3DUnhandled dwarf expression opcode= 0xa1 ) at /usr/src/sys/kern/kern_intr.c:1435 #14 0xc0e4c552 in intr_execute_handlers (isrc=3D,=20 frame=3D) at /usr/src/sys/x86/x86/intr_machdep.c:2= 69 #15 0xc0e4f50d in lapic_handle_intr (vector=3D-956585056, frame=3D0xc6fbaba= 0) at /usr/src/sys/x86/x86/local_apic.c:780 #16 0xc0e1ec35 in Xapic_isr1 () at /tmp/exception-SmXQMs.s:214 #17 0xc0e1a202 in acpi_cpu_c1 () at /usr/src/sys/i386/acpica/acpi_machdep.c:114 Previous frame inner to this frame (corrupt stack?) Any suggestions? At this point, I don't really know enough to file a PR. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDYs9kACgkQmprOCmdXAD07QgCeNIz5WZ0yyCuNLlD7gBqdZp3X bOMAoIkesl27aJVq7NFsXECwKdjJ8w3a =yv1k -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 20:46:55 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A8DE1D8; Mon, 24 Dec 2012 20:46:55 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id E51BF8FC0A; Mon, 24 Dec 2012 20:46:54 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 8CE1256074; Mon, 24 Dec 2012 14:46:53 -0600 (CST) Date: Mon, 24 Dec 2012 14:46:53 -0600 From: Mark Linimon To: Derek Kulinski Subject: Re: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines Message-ID: <20121224204653.GA23711@lonesome.com> References: <1824023197.20121223142308@takeda.tk> <50D87C56.70709@FreeBSD.org> <331959998.20121224101719@takeda.tk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <331959998.20121224101719@takeda.tk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 20:46:55 -0000 On Mon, Dec 24, 2012 at 10:17:19AM -0800, Derek Kulinski wrote: > Yes, but they are 3.5GB each. I attached text dump to GNATS but I can > resend it to you We have a limit of 500K on GNATS PRs. For something that huge, a PR database is really not the right place for it -- please post the dumps somewhere and include a URL to them in a followup to the PR. Thanks. Mark Linimon, on behalf of bugmeister From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 20:55:29 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07C664C6; Mon, 24 Dec 2012 20:55:29 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id CC5DF8FC12; Mon, 24 Dec 2012 20:55:28 +0000 (UTC) Received: from localhost.takeda.tk (takeda-ws2.lan [10.0.0.123]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id qBOKtRZO015237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Dec 2012 12:55:28 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Mon, 24 Dec 2012 12:55:38 -0800 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <47474870.20121224125538@takeda.tk> To: Mark Linimon Subject: Re: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines In-Reply-To: <20121224204653.GA23711@lonesome.com> References: <1824023197.20121223142308@takeda.tk> <50D87C56.70709@FreeBSD.org> <331959998.20121224101719@takeda.tk> <20121224204653.GA23711@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 20:55:29 -0000 Hello Mark, Monday, December 24, 2012, 12:46:53 PM, you wrote: > On Mon, Dec 24, 2012 at 10:17:19AM -0800, Derek Kulinski wrote: >> Yes, but they are 3.5GB each. I attached text dump to GNATS but I can >> resend it to you > We have a limit of 500K on GNATS PRs. For something that huge, a PR > database is really not the right place for it -- please post the dumps > somewhere and include a URL to them in a followup to the PR. > Thanks. > Mark Linimon, on behalf of bugmeister I included the text dump, but I do not see it when I visit the web interface so I don't know if it was attached there or not. -- Best regards, Derek mailto:takeda@takeda.tk My new car runs at 56Kbps From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 21:04:16 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D01996BD for ; Mon, 24 Dec 2012 21:04:16 +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 2E3738FC0C for ; Mon, 24 Dec 2012 21:04:15 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA06306; Mon, 24 Dec 2012 23:04:07 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TnFBv-000Hlw-FV; Mon, 24 Dec 2012 23:04:07 +0200 Message-ID: <50D8C344.4090702@FreeBSD.org> Date: Mon, 24 Dec 2012 23:04:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Wolfskill Subject: Re: stable/9 i386 panic [ACPI/timer?] References: <20121224195818.GA1867@albert.catwhisker.org> In-Reply-To: <20121224195818.GA1867@albert.catwhisker.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 21:04:16 -0000 on 24/12/2012 21:58 David Wolfskill said the following: > I finally(!) got around to enabling crash dumps on the primary machine > here at the house ... and managed to make use of it (unfortunately). > > I've copied the relevant files (both those from /var/crash and > dmesg.boot) so they should be visibale at > (though > only the dmesg.boot, core.text.0, & info.0 files should be fetchable > for now). [I'll make the vmcore.0 available to individuals who > wish to work on the problem; please contact me to arrange this.] > > Here's a bit of information excerpted from core.text.0: > > Mon Dec 24 11:16:04 PST 2012 > > FreeBSD albert.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #434 244582M: Sat Dec 22 05:06:29 PST 2012 root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/ALBERT i386 > > Note that while the version string says "244582M": > > * Userland was at r244608. > > * The "Modification" was merely a change to src/sys/newvers.sh to re-factor > the extraction of the version string. > > > > panic: page fault > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x34 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0ad475c > stack pointer = 0x28:0xc6fba9d8 > frame pointer = 0x28:0xc6fbaa18 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 11 (idle: cpu0) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c0ffbab8,46,1,ca931e80,0,...) at 0xc051ef76 = db_trace_self_wrapper+0x36/frame 0xc6fba740 > kdb_backtrace(c1033ff1,0,c0e75cc4,c6fba7ec,c71f08d0,...) at 0xc0afc400 = kdb_backtrace+0x30/frame 0xc6fba7a0 > panic(c0e75cc4,c1034ddb,c71f0a84,1,1,...) at 0xc0ac763c = panic+0x1bc/frame 0xc6fba7e0 > trap_fatal(28,7fffffff,3,0,28,...) at 0xc0e35560 = trap_fatal+0x340/frame 0xc6fba828 > trap_pfault(34,c,1,c11a68b0,c6fba940,...) at 0xc0e358cb = trap_pfault+0x35b/frame 0xc6fba8a0 > trap(c6fba998) at 0xc0e34e13 = trap+0x443/frame 0xc6fba98c > calltrap() at 0xc0e1e86c = calltrap+0x6/frame 0xc6fba98c > --- trap 0xc, eip = 0xc0ad475c, esp = 0xc6fba9d8, ebp = 0xc6fbaa18 --- > tc_windup(1,0,c0ff3ba6,21c,0,...) at 0xc0ad475c = tc_windup+0x1c/frame 0xc6fbaa18 > hardclock_cnt(1,0,0,3,0,...) at 0xc0a77e39 = hardclock_cnt+0x2e9/frame 0xc6fbaa68 > handleevents(c6fbaaf8,2,46,c71f08d0,c6fbaae4,...) at 0xc0e3c534 = handleevents+0x184/frame 0xc6fbaac0 > timercb(c7564064,0,c76a82f0,c6fbab58,c0a99a0e,...) at 0xc0e3d1a1 = timercb+0x281/frame 0xc6fbab14 > hpet_intr_single(c7564064,c7569780,0,c6fbabbc,c6fbab78,...) at 0xc053a345 = hpet_intr_single+0x195/frame 0xc6fbab40 > hpet_intr(c7564000,0,c71f08d0,14,c723b710,...) at 0xc053a3cf = hpet_intr+0x6f/frame 0xc6fbab58 > intr_event_handle(c723c280,c6fbabbc,c6fbab94,0,c7182600,...) at 0xc0a99c5c = intr_event_handle+0x7c/frame 0xc6fbab78 > intr_execute_handlers(c723b710,c6fbabbc,0) at 0xc0e4c552 = intr_execute_handlers+0x42/frame 0xc6fbab98 > lapic_handle_intr(33,c6fbabbc) at 0xc0e4f50d = lapic_handle_intr+0x3d/frame 0xc6fbabac > Xapic_isr1() at 0xc0e1ec35 = Xapic_isr1+0x35/frame 0xc6fbabac > --- interrupt, eip = 0xc0e1a202, esp = 0xc6fbabfc, ebp = 0xc6fbac3c --- > acpi_cpu_c1(0,c6fbac58,c0e250a6,0,c1198018,...) at 0xc0e1a202 = acpi_cpu_c1+0x2/frame 0xc6fbac3c > cpu_idle_acpi(0,c1198018,c6fbacd0,c0aee519,0,...) at 0xc0e24fff = cpu_idle_acpi+0x2f/frame 0xc6fbac48 > cpu_idle(0,2,c0ffa49a,a36,c71f08d0,...) at 0xc0e250a6 = cpu_idle+0x96/frame 0xc6fbac58 > sched_idletd(0,c6fbad08,0,0,c0aee250,...) at 0xc0aee519 = sched_idletd+0x2c9/frame 0xc6fbacd0 > fork_exit(c0aee250,0,c6fbad08) at 0xc0a977c7 = fork_exit+0x67/frame 0xc6fbacf4 > fork_trampoline() at 0xc0e1e8e4 = fork_trampoline+0x8/frame 0xc6fbacf4 > --- trap 0, eip = 0, esp = 0xc6fbad40, ebp = 0 --- > Uptime: 7h11m46s > Physical memory: 3045 MB > > > #0 doadump (textdump=) at pcpu.h:249 > 249 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:249 > #1 0xc0ac71fa in kern_reboot (howto=Unhandled dwarf expression opcode 0xc0 > ) > at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xc0ac7688 in panic (fmt=Unhandled dwarf expression opcode 0xc0 > ) at /usr/src/sys/kern/kern_shutdown.c:636 > #3 0xc0e35560 in trap_fatal (frame=, > eva=) at /usr/src/sys/i386/i386/trap.c:1043 > #4 0xc0e358cb in trap_pfault (frame=, usermode=Unhandled dwarf expression opcode 0xc3 > ) > at /usr/src/sys/i386/i386/trap.c:858 > #5 0xc0e34e13 in trap (frame=) > at /usr/src/sys/i386/i386/trap.c:555 > #6 0xc0e1e86c in calltrap () at /tmp/exception-SmXQMs.s:94 > #7 0xc0ad475c in tc_windup () at /usr/src/sys/kern/kern_tc.c:450 I'd say that what you see is impossible... Could you please provide the following info from kgdb? p timehands p th0 ... p th9 disassemble tc_windup > #8 0xc0a77e39 in hardclock_cnt (usermode=) > at /usr/src/sys/kern/kern_clock.c:556 > #9 0xc0e3c534 in handleevents (now=, > fake=) at /usr/src/sys/kern/kern_clocksource.c:215 > #10 0xc0e3d1a1 in timercb (et=Unhandled dwarf expression opcode 0xc0 > ) at /usr/src/sys/kern/kern_clocksource.c:390 > #11 0xc053a345 in hpet_intr_single (arg=) > at /usr/src/sys/dev/acpica/acpi_hpet.c:260 > #12 0xc053a3cf in hpet_intr (arg=) > at /usr/src/sys/dev/acpica/acpi_hpet.c:278 > #13 0xc0a99c5c in intr_event_handle (ie=Unhandled dwarf expression opcode 0xa1 > ) > at /usr/src/sys/kern/kern_intr.c:1435 > #14 0xc0e4c552 in intr_execute_handlers (isrc=, > frame=) at /usr/src/sys/x86/x86/intr_machdep.c:269 > #15 0xc0e4f50d in lapic_handle_intr (vector=-956585056, frame=0xc6fbaba0) > at /usr/src/sys/x86/x86/local_apic.c:780 > #16 0xc0e1ec35 in Xapic_isr1 () at /tmp/exception-SmXQMs.s:214 > #17 0xc0e1a202 in acpi_cpu_c1 () > at /usr/src/sys/i386/acpica/acpi_machdep.c:114 > Previous frame inner to this frame (corrupt stack?) > > Any suggestions? At this point, I don't really know enough to file a PR. > > Peace, > david > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 21:16:29 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4B4D8C4; Mon, 24 Dec 2012 21:16:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE378FC0A; Mon, 24 Dec 2012 21:16:28 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qBOLGSUH002807; Mon, 24 Dec 2012 13:16:28 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qBOLGSlD002806; Mon, 24 Dec 2012 13:16:28 -0800 (PST) (envelope-from david) Date: Mon, 24 Dec 2012 13:16:28 -0800 From: David Wolfskill To: Andriy Gapon Subject: Re: stable/9 i386 panic [ACPI/timer?] Message-ID: <20121224211628.GB1867@albert.catwhisker.org> References: <20121224195818.GA1867@albert.catwhisker.org> <50D8C344.4090702@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline In-Reply-To: <50D8C344.4090702@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 21:16:29 -0000 --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 24, 2012 at 11:04:04PM +0200, Andriy Gapon wrote: > ... > I'd say that what you see is impossible... Well, I suppose it's small comfort, but that does make me feel a little better about being a bit clueless about why this happened. Thanks! :-} > Could you please provide the following info from kgdb? > p timehands > p th0 > ... > p th9 > disassemble tc_windup > ... Here you go, cut/pasted (though I elided the "---Type to continue, or q to quit---" lines): albert(9.1-P)[3] kgdb /boot/kernel/kernel.symbols vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. =2E.. Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x34 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0ad475c stack pointer =3D 0x28:0xc6fba9d8 frame pointer =3D 0x28:0xc6fbaa18 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 11 (idle: cpu0) trap number =3D 12 panic: page fault =2E.. Loaded symbols for /boot/kernel/drm.ko #0 doadump (textdump=3D) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) frame 7 #7 0xc0ad475c in tc_windup () at /usr/src/sys/kern/kern_tc.c:450 450 /usr/src/sys/kern/kern_tc.c: No such file or directory. in /usr/src/sys/kern/kern_tc.c Current language: auto; currently minimal (kgdb) p timehands $1 =3D (struct timehands * volatile) 0xc11ba910 (kgdb) p th0 $2 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3989950369, th_offset =3D= { sec =3D 25906, frac =3D 2057132249855343962}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 180944}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 180944041}, th_generation =3D 669311= ,=20 th_next =3D 0xc112a7e4} (kgdb) p th1 $3 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3990015836, th_offset =3D= { sec =3D 25906, frac =3D 2167819058537565778}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 186944}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 186944385}, th_generation =3D 669311= ,=20 th_next =3D 0xc112a820} (kgdb) p th2 $4 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3990048555, th_offset =3D= { sec =3D 25906, frac =3D 2223137947340682090}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 189943}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 189943228}, th_generation =3D 669311= ,=20 th_next =3D 0xc112a85c} (kgdb) p th3 $5 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3990059490, th_offset =3D= { sec =3D 25906, frac =3D 2241626044442123970}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 190945}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 190945470}, th_generation =3D 669311= ,=20 th_next =3D 0xc112a898} (kgdb) p th4 $6 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3990070376, th_offset =3D= { sec =3D 25906, frac =3D 2260031295932411698}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 191943}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 191943220}, th_generation =3D 669311= ,=20 th_next =3D 0xc112a8d4} (kgdb) p th5 $7 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3990081323, th_offset =3D= { sec =3D 25906, frac =3D 2278539681754952554}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 192946}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 192946562}, th_generation =3D 669311= ,=20 th_next =3D 0xc11ba910} (kgdb) p th6 $8 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3989906722, th_offset =3D= { sec =3D 25906, frac =3D 1983337099038093506}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 176943}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 176943598}, th_generation =3D 669310= ,=20 th_next =3D 0xc112a94c} (kgdb) p th7 $9 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3989927028, th_offset =3D= { sec =3D 25906, frac =3D 2017668996591077394}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 178804}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 178804734}, th_generation =3D 669310= ,=20 th_next =3D 0xc112a988} (kgdb) p th8 $10 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3989928549, th_offset =3D= { sec =3D 25906, frac =3D 2020240591990372602}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 178944}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 178944140}, th_generation =3D 669310= ,=20 th_next =3D 0xc112a9c4} (kgdb) p th9 $11 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3989939440, th_offset =3D= { sec =3D 25906, frac =3D 2038654297114451570}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 179942}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 179942349}, th_generation =3D 669310= ,=20 th_next =3D 0xc112a7a8} (kgdb) disassemble tc_windup Dump of assembler code for function tc_windup: 0xc0ad4740 : push %ebp 0xc0ad4741 : mov %esp,%ebp 0xc0ad4743 : and $0xfffffff8,%esp 0xc0ad4749 : push %ebx 0xc0ad474a : push %edi 0xc0ad474b : push %esi 0xc0ad474c : sub $0x34,%esp 0xc0ad474f : mov 0xc112a6c8,%ecx 0xc0ad4755 : mov %ecx,0x14(%esp) 0xc0ad4759 : mov 0x38(%ecx),%ebx 0xc0ad475c : mov 0x34(%ebx),%eax 0xc0ad475f : mov %eax,0x1c(%esp) 0xc0ad4763 : movl $0x0,0x34(%ebx) 0xc0ad476a : mov %ebx,0x4(%esp) 0xc0ad476e : mov %ecx,(%esp) 0xc0ad4771 : movl $0x34,0x8(%esp) 0xc0ad4779 : call 0xc0e32f14 0xc0ad477e : mov (%ebx),%esi 0xc0ad4780 : mov %esi,(%esp) 0xc0ad4783 : call *(%esi) 0xc0ad4785 : mov %eax,%edi 0xc0ad4787 : mov (%ebx),%eax 0xc0ad4789 : mov 0x14(%ebx),%ecx 0xc0ad478c : sub %ecx,%edi 0xc0ad478e : and 0x8(%esi),%edi 0xc0ad4791 : mov %eax,%esi 0xc0ad4793 : xor %eax,%eax 0xc0ad4795 : mov 0xc112a5f8,%edx 0xc0ad479b : cmp %edx,%esi 0xc0ad479d : je 0xc0ad47a9 0xc0ad479f : mov %edx,(%esp) 0xc0ad47a2 : call *(%edx) 0xc0ad47a4 : mov (%ebx),%esi 0xc0ad47a6 : mov 0x14(%ebx),%ecx 0xc0ad47a9 : mov %eax,0x18(%esp) 0xc0ad47ad : add %edi,%ecx 0xc0ad47af : mov %ecx,0x14(%ebx) 0xc0ad47b2 : and 0x8(%esi),%ecx 0xc0ad47b5 : mov %ecx,0x14(%ebx) 0xc0ad47b8 : mov 0xc(%esi),%ecx 0xc0ad47bb : mov 0x10(%esi),%eax 0xc0ad47be : cmp %ecx,%edi 0xc0ad47c0 : setbe %dl 0xc0ad47c3 : test %eax,%eax 0xc0ad47c5 : je 0xc0ad47c9 0xc0ad47c7 : mov $0x1,%dl 0xc0ad47c9 : movl $0x0,0x24(%esp) 0xc0ad47d1 : test %dl,%dl 0xc0ad47d3 : jne 0xc0ad4807 0xc0ad47d5 : mov 0x18(%ebx),%edx 0xc0ad47d8 : mov %ebx,%esi 0xc0ad47da : movl $0x0,0x24(%esp) 0xc0ad47e2 : nop =20 0xc0ad47e3 : nop =20 0xc0ad47e4 : nop =20 0xc0ad47e5 : nop =20 0xc0ad47e6 : nop =20 0xc0ad47e7 : nop =20 0xc0ad47e8 : nop =20 0xc0ad47e9 : nop =20 0xc0ad47ea : nop =20 0xc0ad47eb : nop =20 0xc0ad47ec : nop =20 0xc0ad47ed : nop =20 0xc0ad47ee : nop =20 0xc0ad47ef : nop =20 0xc0ad47f0 : sub %ecx,%edi 0xc0ad47f2 : cmp %ecx,%edi 0xc0ad47f4 : seta %bl 0xc0ad47f7 : test %eax,%eax 0xc0ad47f9 : je 0xc0ad47fd 0xc0ad47fb : xor %bl,%bl 0xc0ad47fd : inc %edx 0xc0ad47fe : test %bl,%bl 0xc0ad4800 : jne 0xc0ad47f0 0xc0ad4802 : mov %esi,%ebx 0xc0ad4804 : mov %edx,0x18(%ebx) 0xc0ad4807 : shrd $0x1,%eax,%ecx 0xc0ad480b : cmp %ecx,%edi 0xc0ad480d : setbe %dl 0xc0ad4810 : shr %eax 0xc0ad4812 : cmp %eax,0x24(%esp) 0xc0ad4816 : setbe %al 0xc0ad4819 : je 0xc0ad481d 0xc0ad481b : mov %al,%dl 0xc0ad481d : mov 0xc(%ebx),%ecx 0xc0ad4820 : mov 0x10(%ebx),%esi 0xc0ad4823 : test %dl,%dl 0xc0ad4825 : jne 0xc0ad4840 0xc0ad4827 : mov %ecx,%eax 0xc0ad4829 : mul %edi 0xc0ad482b : mov %ecx,%eax 0xc0ad482d : imul 0x24(%esp),%eax 0xc0ad4832 : add %edx,%eax 0xc0ad4834 : mov %esi,%edx 0xc0ad4836 : imul %edi,%edx 0xc0ad4839 : add %eax,%edx 0xc0ad483b : js 0xc0ad4840 0xc0ad483d : incl 0x18(%ebx) 0xc0ad4840 : mov %ecx,%eax 0xc0ad4842 : mul %edi 0xc0ad4844 : mov %edx,0x10(%esp) 0xc0ad4848 : mov %ecx,%edx 0xc0ad484a : mov 0x24(%esp),%ecx 0xc0ad484e : imul %edx,%ecx 0xc0ad4851 : add 0x10(%esp),%ecx 0xc0ad4855 : imul %edi,%esi 0xc0ad4858 : add %ecx,%esi 0xc0ad485a : mov 0x1c(%ebx),%edx 0xc0ad485d : mov 0x20(%ebx),%ecx 0xc0ad4860 : add %edx,%eax 0xc0ad4862 : mov %eax,0x1c(%ebx) 0xc0ad4865 : adc %ecx,%esi 0xc0ad4867 : mov %esi,0x20(%ebx) 0xc0ad486a : cmp %edx,%eax 0xc0ad486c : setb %al 0xc0ad486f : cmp %ecx,%esi 0xc0ad4871 : setb %cl 0xc0ad4874 : je 0xc0ad4878 0xc0ad4876 : mov %cl,%al 0xc0ad4878 : lea 0x18(%ebx),%esi 0xc0ad487b : test %al,%al 0xc0ad487d : mov 0x14(%esp),%edi 0xc0ad4881 : je 0xc0ad4885 0xc0ad4883 : incl (%esi) 0xc0ad4885 : mov (%edi),%eax 0xc0ad4887 : mov 0x4(%eax),%ecx 0xc0ad488a : test %ecx,%ecx 0xc0ad488c : je 0xc0ad4893 0xc0ad488e : mov %eax,(%esp) 0xc0ad4891 : call *%ecx 0xc0ad4893 : mov 0x8(%esi),%eax 0xc0ad4896 : mov %eax,0x30(%esp) 0xc0ad489a : mov (%esi),%eax 0xc0ad489c : mov 0x4(%esi),%ecx 0xc0ad489f : mov %ecx,0x2c(%esp) 0xc0ad48a3 : mov %eax,0x28(%esp) 0xc0ad48a7 : mov 0x2c(%esp),%edx 0xc0ad48ab : mov 0x30(%esp),%eax 0xc0ad48af : mov 0xc11f65b8,%esi 0xc0ad48b5 : add %edx,%esi 0xc0ad48b7 : mov 0xc11f65bc,%ecx 0xc0ad48bd : adc %eax,%ecx 0xc0ad48bf : mov %ecx,0x30(%esp) 0xc0ad48c3 : mov %esi,0x2c(%esp) 0xc0ad48c7 : cmp %edx,%esi 0xc0ad48c9 : setb %dl 0xc0ad48cc : cmp %eax,%ecx 0xc0ad48ce : setb %al 0xc0ad48d1 : je 0xc0ad48d5 0xc0ad48d3 : mov %al,%dl 0xc0ad48d5 : mov 0x28(%esp),%esi 0xc0ad48d9 : test %dl,%dl 0xc0ad48db : je 0xc0ad48e2 0xc0ad48dd : inc %esi 0xc0ad48de : mov %esi,0x28(%esp) 0xc0ad48e2 : add 0xc11f65b4,%esi 0xc0ad48e8 : mov %esi,0x28(%esp) 0xc0ad48ec : mov %esi,%eax 0xc0ad48ee : sub 0x24(%edi),%eax 0xc0ad48f1 : mov $0x2,%edi 0xc0ad48f6 : cmp $0xc8,%eax 0xc0ad48fb : jg 0xc0ad48ff 0xc0ad48fd : mov %eax,%edi 0xc0ad48ff : test %edi,%edi 0xc0ad4901 : jle 0xc0ad4943 0xc0ad4903 : mov %ebx,0x20(%esp) 0xc0ad4907 : lea 0x4(%ebx),%ebx 0xc0ad490a : nop =20 0xc0ad490b : nop =20 0xc0ad490c : nop =20 0xc0ad490d : nop =20 0xc0ad490e : nop =20 0xc0ad490f : nop =20 0xc0ad4910 : lea 0x28(%esp),%eax 0xc0ad4914 : mov %eax,0x4(%esp) 0xc0ad4918 : mov %ebx,(%esp) 0xc0ad491b : call 0xc0ab58c0 0xc0ad4920 : mov 0x28(%esp),%eax 0xc0ad4924 : cmp %esi,%eax 0xc0ad4926 : je 0xc0ad4932 0xc0ad4928 : mov %eax,%ecx 0xc0ad492a : sub %esi,%ecx 0xc0ad492c : add %ecx,0xc11f65b4 0xc0ad4932 : dec %edi 0xc0ad4933 : test %edi,%edi 0xc0ad4935 : mov %eax,%esi 0xc0ad4937 : jg 0xc0ad4910 0xc0ad4939 : mov 0x30(%esp),%ecx 0xc0ad493d : mov 0x20(%esp),%ebx 0xc0ad4941 : jmp 0xc0ad4945 0xc0ad4943 : mov %esi,%eax 0xc0ad4945 : mov %eax,0x24(%ebx) 0xc0ad4948 : mov $0xf4240,%edx 0xc0ad494d : mov %ecx,%eax 0xc0ad494f : mul %edx 0xc0ad4951 : mov %edx,0x28(%ebx) 0xc0ad4954 : mov 0x28(%esp),%eax 0xc0ad4958 : mov %eax,0x2c(%ebx) 0xc0ad495b : mov $0x3b9aca00,%edx 0xc0ad4960 : mov %ecx,%eax 0xc0ad4962 : mul %edx 0xc0ad4964 : mov %edx,0x30(%ebx) 0xc0ad4967 : mov (%ebx),%eax 0xc0ad4969 : mov 0xc112a5f8,%esi 0xc0ad496f : cmp %esi,%eax 0xc0ad4971 : je 0xc0ad49fa 0xc0ad4977 : testb $0x1,0x1c(%esi) 0xc0ad497b : je 0xc0ad4983 0xc0ad497d : incl 0xc11bde70 0xc0ad4983 : testb $0x1,0x1c(%eax) 0xc0ad4987 : je 0xc0ad498f 0xc0ad4989 : decl 0xc11bde70 0xc0ad498f : mov %esi,(%ebx) 0xc0ad4991 : mov 0x18(%esp),%eax 0xc0ad4995 : mov %eax,0x14(%ebx) 0xc0ad4998 : mov %ebx,0x20(%esp) 0xc0ad499c : mov 0xc112a5f8,%ebx 0xc0ad49a2 : mov 0x8(%ebx),%eax 0xc0ad49a5 : mov 0xc(%ebx),%edi 0xc0ad49a8 : add $0x1,%eax 0xc0ad49ab : mov %eax,(%esp) 0xc0ad49ae : sbb %eax,%eax 0xc0ad49b0 : and $0x1,%eax 0xc0ad49b3 : mov %eax,0x4(%esp) 0xc0ad49b7 : movl $0x0,0xc(%esp) 0xc0ad49bf : movl $0x3,0x8(%esp) 0xc0ad49c7 : call 0xc0e3ed30 <__udivdi3> 0xc0ad49cc : mov 0x10(%ebx),%ecx 0xc0ad49cf : mov %ecx,0x4(%esp) 0xc0ad49d3 : mov %edi,(%esp) 0xc0ad49d6 : mov %edx,0xc(%esp) 0xc0ad49da : mov %eax,0x8(%esp) 0xc0ad49de : mov $0x1,%edi 0xc0ad49e3 : call 0xc0e3ed30 <__udivdi3> 0xc0ad49e8 : test %eax,%eax 0xc0ad49ea : je 0xc0ad49ee 0xc0ad49ec : mov %eax,%edi 0xc0ad49ee : mov %edi,0xc112a5fc 0xc0ad49f4 : mov 0x20(%esp),%ebx 0xc0ad49f8 : jmp 0xc0ad49fc 0xc0ad49fa : mov %eax,%esi 0xc0ad49fc : mov 0xc(%esi),%eax 0xc0ad49ff : mov 0x10(%esi),%ecx 0xc0ad4a02 : mov %ecx,0xc(%esp) 0xc0ad4a06 : mov %eax,0x8(%esp) 0xc0ad4a0a : mov 0x8(%ebx),%ecx 0xc0ad4a0d : mov %ecx,%eax 0xc0ad4a0f : sar $0x1f,%eax 0xc0ad4a12 : shr $0x16,%eax 0xc0ad4a15 : add 0x4(%ebx),%eax 0xc0ad4a18 : adc $0x0,%ecx 0xc0ad4a1b : shrd $0xa,%ecx,%eax 0xc0ad4a1f : mov $0x897,%edx 0xc0ad4a24 : mul %edx 0xc0ad4a26 : mov %eax,(%esp) 0xc0ad4a29 : sar $0xa,%ecx 0xc0ad4a2c : imul $0x897,%ecx,%eax 0xc0ad4a32 : add %edx,%eax 0xc0ad4a34 : xor $0x80000000,%eax 0xc0ad4a39 : mov %eax,0x4(%esp) 0xc0ad4a3d : call 0xc0e3ed30 <__udivdi3> 0xc0ad4a42 : add %eax,%eax 0xc0ad4a44 : mov %eax,0xc(%ebx) 0xc0ad4a47 : adc %edx,%edx 0xc0ad4a49 : mov %edx,0x10(%ebx) 0xc0ad4a4c : mov 0x1c(%esp),%ecx 0xc0ad4a50 : inc %ecx 0xc0ad4a51 : mov $0x1,%eax 0xc0ad4a56 : test %ecx,%ecx 0xc0ad4a58 : je 0xc0ad4a5c 0xc0ad4a5a : mov %ecx,%eax 0xc0ad4a5c : mov %eax,0x34(%ebx) 0xc0ad4a5f : mov 0x24(%ebx),%eax 0xc0ad4a62 : mov %eax,0xc112a600 0xc0ad4a67 : mov 0x18(%ebx),%eax 0xc0ad4a6a : mov %eax,0xc112a604 0xc0ad4a6f : mov %ebx,0xc112a6c8 0xc0ad4a75 : call 0xc0ac6670 0xc0ad4a7a : add $0x34,%esp 0xc0ad4a7d : pop %esi 0xc0ad4a7e : pop %edi 0xc0ad4a7f : pop %ebx 0xc0ad4a80 : mov %ebp,%esp 0xc0ad4a82 : pop %ebp 0xc0ad4a83 : ret =20 End of assembler dump. (kgdb)=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDYxisACgkQmprOCmdXAD11qgCeK+l9cYelxDW6qRLpBpk3LY9p U2cAoIU1XClAoZXMQDokq3GZxS4TFWQL =t8gr -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 22:35:28 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 230A3914 for ; Mon, 24 Dec 2012 22:35:28 +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 7C1B18FC0C for ; Mon, 24 Dec 2012 22:35:27 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA06711; Tue, 25 Dec 2012 00:35:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TnGcC-000Hsr-Rj; Tue, 25 Dec 2012 00:35:20 +0200 Message-ID: <50D8D8A6.60402@FreeBSD.org> Date: Tue, 25 Dec 2012 00:35:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Wolfskill Subject: Re: stable/9 i386 panic [ACPI/timer?] References: <20121224195818.GA1867@albert.catwhisker.org> <50D8C344.4090702@FreeBSD.org> <20121224211628.GB1867@albert.catwhisker.org> In-Reply-To: <20121224211628.GB1867@albert.catwhisker.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 22:35:28 -0000 on 24/12/2012 23:16 David Wolfskill said the following: > albert(9.1-P)[3] kgdb /boot/kernel/kernel.symbols vmcore.0 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > ... > Unread portion of the kernel message buffer: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x34 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0ad475c > stack pointer = 0x28:0xc6fba9d8 > frame pointer = 0x28:0xc6fbaa18 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 11 (idle: cpu0) > trap number = 12 > panic: page fault > ... > Loaded symbols for /boot/kernel/drm.ko > #0 doadump (textdump=) at pcpu.h:249 > 249 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) frame 7 > #7 0xc0ad475c in tc_windup () at /usr/src/sys/kern/kern_tc.c:450 > 450 /usr/src/sys/kern/kern_tc.c: No such file or directory. > in /usr/src/sys/kern/kern_tc.c > Current language: auto; currently minimal > (kgdb) p timehands > $1 = (struct timehands * volatile) 0xc11ba910 > (kgdb) p th0 > $2 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3989950369, th_offset = { > sec = 25906, frac = 2057132249855343962}, th_microtime = { > tv_sec = 1356376278, tv_usec = 180944}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 180944041}, th_generation = 669311, > th_next = 0xc112a7e4} > (kgdb) p th1 > $3 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3990015836, th_offset = { > sec = 25906, frac = 2167819058537565778}, th_microtime = { > tv_sec = 1356376278, tv_usec = 186944}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 186944385}, th_generation = 669311, > th_next = 0xc112a820} > (kgdb) p th2 > $4 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3990048555, th_offset = { > sec = 25906, frac = 2223137947340682090}, th_microtime = { > tv_sec = 1356376278, tv_usec = 189943}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 189943228}, th_generation = 669311, > th_next = 0xc112a85c} > (kgdb) p th3 > $5 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3990059490, th_offset = { > sec = 25906, frac = 2241626044442123970}, th_microtime = { > tv_sec = 1356376278, tv_usec = 190945}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 190945470}, th_generation = 669311, > th_next = 0xc112a898} > (kgdb) p th4 > $6 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3990070376, th_offset = { > sec = 25906, frac = 2260031295932411698}, th_microtime = { > tv_sec = 1356376278, tv_usec = 191943}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 191943220}, th_generation = 669311, > th_next = 0xc112a8d4} > (kgdb) p th5 > $7 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3990081323, th_offset = { > sec = 25906, frac = 2278539681754952554}, th_microtime = { > tv_sec = 1356376278, tv_usec = 192946}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 192946562}, th_generation = 669311, > th_next = 0xc11ba910} > (kgdb) p th6 > $8 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3989906722, th_offset = { > sec = 25906, frac = 1983337099038093506}, th_microtime = { > tv_sec = 1356376278, tv_usec = 176943}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 176943598}, th_generation = 669310, > th_next = 0xc112a94c} > (kgdb) p th7 > $9 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3989927028, th_offset = { > sec = 25906, frac = 2017668996591077394}, th_microtime = { > tv_sec = 1356376278, tv_usec = 178804}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 178804734}, th_generation = 669310, > th_next = 0xc112a988} > (kgdb) p th8 > $10 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3989928549, th_offset = { > sec = 25906, frac = 2020240591990372602}, th_microtime = { > tv_sec = 1356376278, tv_usec = 178944}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 178944140}, th_generation = 669310, > th_next = 0xc112a9c4} > (kgdb) p th9 > $11 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3989939440, th_offset = { > sec = 25906, frac = 2038654297114451570}, th_microtime = { > tv_sec = 1356376278, tv_usec = 179942}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 179942349}, th_generation = 669310, > th_next = 0xc112a7a8} > (kgdb) disassemble tc_windup > Dump of assembler code for function tc_windup: > 0xc0ad4740 : push %ebp > 0xc0ad4741 : mov %esp,%ebp > 0xc0ad4743 : and $0xfffffff8,%esp > 0xc0ad4749 : push %ebx > 0xc0ad474a : push %edi > 0xc0ad474b : push %esi > 0xc0ad474c : sub $0x34,%esp > 0xc0ad474f : mov 0xc112a6c8,%ecx > 0xc0ad4755 : mov %ecx,0x14(%esp) > 0xc0ad4759 : mov 0x38(%ecx),%ebx > 0xc0ad475c : mov 0x34(%ebx),%eax Could you please also provide from the same frame i reg p &timehands ? Thank you. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 22:39:59 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F595A88; Mon, 24 Dec 2012 22:39:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 536FC8FC16; Mon, 24 Dec 2012 22:39:59 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qBOMdwF3003174; Mon, 24 Dec 2012 14:39:58 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qBOMdwHp003173; Mon, 24 Dec 2012 14:39:58 -0800 (PST) (envelope-from david) Date: Mon, 24 Dec 2012 14:39:58 -0800 From: David Wolfskill To: Andriy Gapon Subject: Re: stable/9 i386 panic [ACPI/timer?] Message-ID: <20121224223958.GC1867@albert.catwhisker.org> References: <20121224195818.GA1867@albert.catwhisker.org> <50D8C344.4090702@FreeBSD.org> <20121224211628.GB1867@albert.catwhisker.org> <50D8D8A6.60402@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FsscpQKzF/jJk6ya" Content-Disposition: inline In-Reply-To: <50D8D8A6.60402@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 22:39:59 -0000 --FsscpQKzF/jJk6ya Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 25, 2012 at 12:35:18AM +0200, Andriy Gapon wrote: > ... > Could you please also provide from the same frame > i reg > p &timehands > ? Thank you! You're the one doing the work. :-} I had left teh kgdb session active; I also included "p *timehands" just in case it might be of use: (kgdb) i reg eax 0x1 1 ecx 0xc11ba910 -1055151856 edx 0xc72405ff -953940481 ebx 0x0 0 esp 0x0 0x0 ebp 0xc6fbaa18 0xc6fbaa18 esi 0x1 1 edi 0xc71c8300 -954432768 eip 0xc0ad475c 0xc0ad475c eflags 0x10086 65670 cs 0x20 32 ss 0xc6fbaa18 -956585448 ds 0x28 40 es 0xc6fb0028 -956628952 fs 0xc71f0008 -954269688 gs 0x0 0 (kgdb) p &timehands $13 =3D (struct timehands * volatile *) 0xc112a6c8 (kgdb) p *timehands $14 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 th_scale =3D 1690726758248, th_offset_count =3D 3990092176, th_offset =3D= { sec =3D 25906, frac =3D 2296889139262218098}, th_microtime =3D { tv_sec =3D 1356376278, tv_usec =3D 193941}, th_nanotime =3D { tv_sec =3D 1356376278, tv_nsec =3D 193941288}, th_generation =3D 1,=20 th_next =3D 0x0} (kgdb)=20 Also: the machine has been in service for about 2.5 years, and was purchased "refurbished". If it turns out that there are hardware issues, my feelings won't be hurt at all -- I'd merely want to identify the (likely) failing part(s) and replace them. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --FsscpQKzF/jJk6ya Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDY2b0ACgkQmprOCmdXAD1DtgCdHso9wmhtxoyikK2Zesuxj8tW NQEAoIh8NghJMwymrcdQ9yEXVKA9u8xm =ZRMZ -----END PGP SIGNATURE----- --FsscpQKzF/jJk6ya-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 22:58:08 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8AFAEC1 for ; Mon, 24 Dec 2012 22:58:08 +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 D765A8FC16 for ; Mon, 24 Dec 2012 22:58:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA06820; Tue, 25 Dec 2012 00:58:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TnGy9-000HuQ-Dx; Tue, 25 Dec 2012 00:58:01 +0200 Message-ID: <50D8DDF8.5040807@FreeBSD.org> Date: Tue, 25 Dec 2012 00:58:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Wolfskill Subject: Re: stable/9 i386 panic [ACPI/timer?] References: <20121224195818.GA1867@albert.catwhisker.org> <50D8C344.4090702@FreeBSD.org> <20121224211628.GB1867@albert.catwhisker.org> <50D8D8A6.60402@FreeBSD.org> <20121224223958.GC1867@albert.catwhisker.org> In-Reply-To: <20121224223958.GC1867@albert.catwhisker.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 22:58:08 -0000 on 25/12/2012 00:39 David Wolfskill said the following: > I had left teh kgdb session active; I also included "p *timehands" just in > case it might be of use: Thank you. Please also print &th0 ... &th9. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 23:04:33 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A54AFF3; Mon, 24 Dec 2012 23:04:33 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id DDB348FC0A; Mon, 24 Dec 2012 23:04:32 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qBON4Pce003300; Mon, 24 Dec 2012 15:04:25 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qBON4PpQ003299; Mon, 24 Dec 2012 15:04:25 -0800 (PST) (envelope-from david) Date: Mon, 24 Dec 2012 15:04:25 -0800 From: David Wolfskill To: Andriy Gapon Subject: Re: stable/9 i386 panic [ACPI/timer?] Message-ID: <20121224230425.GD1867@albert.catwhisker.org> References: <20121224195818.GA1867@albert.catwhisker.org> <50D8C344.4090702@FreeBSD.org> <20121224211628.GB1867@albert.catwhisker.org> <50D8D8A6.60402@FreeBSD.org> <20121224223958.GC1867@albert.catwhisker.org> <50D8DDF8.5040807@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EP0wieDxd4TSJjHq" Content-Disposition: inline In-Reply-To: <50D8DDF8.5040807@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 23:04:33 -0000 --EP0wieDxd4TSJjHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 25, 2012 at 12:58:00AM +0200, Andriy Gapon wrote: > on 25/12/2012 00:39 David Wolfskill said the following: > > I had left teh kgdb session active; I also included "p *timehands" just= in > > case it might be of use: >=20 > Thank you. > Please also print &th0 ... &th9. > ... Here you go: (kgdb) p &th0 $15 =3D (struct timehands *) 0xc112a7a8 (kgdb) p &th1 $16 =3D (struct timehands *) 0xc112a7e4 (kgdb) p &th2 $17 =3D (struct timehands *) 0xc112a820 (kgdb) p &th3 $18 =3D (struct timehands *) 0xc112a85c (kgdb) p &th4 $19 =3D (struct timehands *) 0xc112a898 (kgdb) p &th5 $20 =3D (struct timehands *) 0xc112a8d4 (kgdb) p &th6 $21 =3D (struct timehands *) 0xc112a910 (kgdb) p &th7 $22 =3D (struct timehands *) 0xc112a94c (kgdb) p &th8 $23 =3D (struct timehands *) 0xc112a988 (kgdb) p &th9 $24 =3D (struct timehands *) 0xc112a9c4 (kgdb)=20 I've copied /boot/kernel/kernel.symbols over, as well: I need to head out for some errands for a while. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --EP0wieDxd4TSJjHq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDY33kACgkQmprOCmdXAD2g+ACdHtw5MKEwyHVaszpNPm0/uCox VK8Anjxf099O8Hfg8EuhvuNktG3N4lW7 =nFYc -----END PGP SIGNATURE----- --EP0wieDxd4TSJjHq-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 23:28:03 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C68BC347; Mon, 24 Dec 2012 23:28: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 DCC1D8FC0A; Mon, 24 Dec 2012 23:28:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA07223; Tue, 25 Dec 2012 01:28:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TnHRB-000Hxu-40; Tue, 25 Dec 2012 01:28:01 +0200 Message-ID: <50D8E500.1070408@FreeBSD.org> Date: Tue, 25 Dec 2012 01:28:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines References: <1824023197.20121223142308@takeda.tk> <50D87C56.70709@FreeBSD.org> <331959998.20121224101719@takeda.tk> In-Reply-To: <331959998.20121224101719@takeda.tk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 23:28:03 -0000 on 24/12/2012 20:17 Derek Kulinski said the following: > Hello Andriy, > > Monday, December 24, 2012, 8:01:26 AM, you wrote: > >> on 24/12/2012 00:23 Derek Kulinski said the following: >>> Dumping 3701 out of 8072 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > >> So do you have the crash dump(s)? > > Yes, but they are 3.5GB each. I attached text dump to GNATS but I can > resend it to you (I don't know if it's ok to send attachments to the > mailing list). If you would prefer I could give you access to the > box. Derek, I've looked through the cores and it does look like in all cases some sort of memory corruption is a precursor to a subsequent crash. I can't decidedly say if the corruptions are caused by the hardware, by some code overwriting random memory locations ("rogue" driver) or by a "simpler" bug like use after free. I am always inclined to suspect the hardware first. You can try to reproduce the problem with some additional checks enabled in the kernel. Those should catch the problem earlier and thus make its source clearer. I recommend the following: options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_MEMGUARD makeoptions DEBUG+="-DDEBUG" The last is really needed only for the ZFS and OpenSolaris compat code. It make result in some extra noise from unrelated subsystems. Perhaps you could just add "#define DEBUG" to sys/cddl/contrib/opensolaris/uts/common/sys/debug.h. I haven't tested this approach though. Also, please put vm.memguard.desc="arc_buf_hdr_t" into loader.conf. Please note that these options will make your system significantly slower. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Dec 24 23:33:23 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 477F8737 for ; Mon, 24 Dec 2012 23:33:23 +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 8D6B78FC0A for ; Mon, 24 Dec 2012 23:33:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA07264; Tue, 25 Dec 2012 01:33:16 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TnHWG-000HyQ-9Q; Tue, 25 Dec 2012 01:33:16 +0200 Message-ID: <50D8E63B.5050804@FreeBSD.org> Date: Tue, 25 Dec 2012 01:33:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Wolfskill Subject: Re: stable/9 i386 panic [ACPI/timer?] References: <20121224195818.GA1867@albert.catwhisker.org> <50D8C344.4090702@FreeBSD.org> <20121224211628.GB1867@albert.catwhisker.org> <50D8D8A6.60402@FreeBSD.org> <20121224223958.GC1867@albert.catwhisker.org> <50D8DDF8.5040807@FreeBSD.org> <20121224230425.GD1867@albert.catwhisker.org> In-Reply-To: <20121224230425.GD1867@albert.catwhisker.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Dec 2012 23:33:23 -0000 on 25/12/2012 01:04 David Wolfskill said the following: > On Tue, Dec 25, 2012 at 12:58:00AM +0200, Andriy Gapon wrote: >> on 25/12/2012 00:39 David Wolfskill said the following: >>> I had left teh kgdb session active; I also included "p *timehands" just in >>> case it might be of use: >> >> Thank you. >> Please also print &th0 ... &th9. >> ... > > Here you go: > > (kgdb) p &th0 > $15 = (struct timehands *) 0xc112a7a8 > (kgdb) p &th1 > $16 = (struct timehands *) 0xc112a7e4 > (kgdb) p &th2 > $17 = (struct timehands *) 0xc112a820 > (kgdb) p &th3 > $18 = (struct timehands *) 0xc112a85c > (kgdb) p &th4 > $19 = (struct timehands *) 0xc112a898 > (kgdb) p &th5 > $20 = (struct timehands *) 0xc112a8d4 > (kgdb) p &th6 > $21 = (struct timehands *) 0xc112a910 Comparing the above and the following from an earlier email: > (kgdb) p timehands > $1 = (struct timehands * volatile) 0xc11ba910 and the following: > (kgdb) p th5 > $7 = {th_counter = 0xc115174c, th_adjustment = 51068786373500, > th_scale = 1690726758248, th_offset_count = 3990081323, th_offset = { > sec = 25906, frac = 2278539681754952554}, th_microtime = { > tv_sec = 1356376278, tv_usec = 192946}, th_nanotime = { > tv_sec = 1356376278, tv_nsec = 192946562}, th_generation = 669311, > th_next = 0xc11ba910} I am quite sure that the impossible happened only because the faulty memory made it possible. > (kgdb) p &th7 > $22 = (struct timehands *) 0xc112a94c > (kgdb) p &th8 > $23 = (struct timehands *) 0xc112a988 > (kgdb) p &th9 > $24 = (struct timehands *) 0xc112a9c4 > (kgdb) > > I've copied /boot/kernel/kernel.symbols over, as well: I need to head > out for some errands for a while. > > Peace, > david > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 00:11:53 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B845A54; Tue, 25 Dec 2012 00:11:53 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id EF45A8FC0A; Tue, 25 Dec 2012 00:11:52 +0000 (UTC) Received: from localhost.takeda.tk (takeda-ws2.lan [10.0.0.123]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id qBP0BjNe002051 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Dec 2012 16:11:46 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Mon, 24 Dec 2012 16:11:56 -0800 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <574019558.20121224161156@takeda.tk> To: Andriy Gapon Subject: Re: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines In-Reply-To: <50D8E500.1070408@FreeBSD.org> References: <1824023197.20121223142308@takeda.tk> <50D87C56.70709@FreeBSD.org> <331959998.20121224101719@takeda.tk> <50D8E500.1070408@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Dec 2012 00:11:53 -0000 Hello Andriy, Monday, December 24, 2012, 3:28:00 PM, you wrote: > I've looked through the cores and it does look like in all cases some sort of > memory corruption is a precursor to a subsequent crash. > I can't decidedly say if the corruptions are caused by the hardware, by some > code overwriting random memory locations ("rogue" driver) or by a "simpler" bug > like use after free. > I am always inclined to suspect the hardware first. > You can try to reproduce the problem with some additional checks enabled in the > kernel. Those should catch the problem earlier and thus make its source clearer. > I recommend the following: > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options DEBUG_MEMGUARD > makeoptions DEBUG+="-DDEBUG" > The last is really needed only for the ZFS and OpenSolaris compat code. It make > result in some extra noise from unrelated subsystems. > Perhaps you could just add "#define DEBUG" to > sys/cddl/contrib/opensolaris/uts/common/sys/debug.h. I haven't tested this > approach though. > Also, please put vm.memguard.desc="arc_buf_hdr_t" into loader.conf. > Please note that these options will make your system significantly slower. I recompiled the kernel and is running with options you specified (I enabled DEBUG in the file). Anyway even at boot time I started getting following warnings, is this anything: Dec 24 16:06:03 chinatsu kernel: Creating and/or trimming log files Dec 24 16:06:03 chinatsu kernel: lock order reversal: Dec 24 16:06:03 chinatsu kernel: 1st 0xffffffff80bf5780 pf task mtx (pf task mtx) @ /usr/src/sys/contrib/pf/net/pf.c:3330 Dec 24 16:06:03 chinatsu kernel: . Dec 24 16:06:03 chinatsu kernel: 2nd 0xfffffe0009211af8 radix node head (radix node head) @ /usr/src/sys/net/route.c:384 Dec 24 16:06:03 chinatsu kernel: KDB: stack backtrace: Dec 24 16:06:03 chinatsu kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 24 16:06:03 chinatsu kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 24 16:06:03 chinatsu kernel: _witness_debugger() at _witness_debugger+0x2c Dec 24 16:06:03 chinatsu kernel: witness_checkorder() at witness_checkorder+0x844 Dec 24 16:06:03 chinatsu kernel: _rw_rlock() at Dec 24 16:06:03 chinatsu kernel: Starting syslogd. Dec 24 16:06:03 chinatsu kernel: _rw_rlock+0x81 Dec 24 16:06:03 chinatsu kernel: rtalloc1_fib() at rtalloc1_fib+0x11c Dec 24 16:06:03 chinatsu kernel: rtalloc_ign_fib() at rtalloc_ign_fib+0xc5 Dec 24 16:06:03 chinatsu kernel: pf_routable() at pf_routable+0x1fd Dec 24 16:06:03 chinatsu kernel: pf_test_rule() at pf_test_rule+0x6cf Dec 24 16:06:03 chinatsu kernel: pf_test() at pf_test+0xf58 Dec 24 16:06:03 chinatsu kernel: pf_check_in() at pf_check_in+0x2b Dec 24 16:06:03 chinatsu kernel: pfil_run_hooks() at pfil_run_hooks+0xd2 Dec 24 16:06:03 chinatsu kernel: ip_input() at ip_input+0x2dc Dec 24 16:06:03 chinatsu kernel: netisr_dispatch_src() at netisr_dispatch_src+0x170 Dec 24 16:06:03 chinatsu kernel: ether_demux() at ether_demux+0x17d Dec 24 16:06:03 chinatsu kernel: ether_nh_input() at ether_nh_input+0x209 Dec 24 16:06:03 chinatsu kernel: netisr_dispatch_src() at netisr_dispatch_src+0x170 Dec 24 16:06:03 chinatsu kernel: alc_int_task() at alc_int_task+0x2ff Dec 24 16:06:03 chinatsu kernel: taskqueue_run_locked() at taskqueue_run_locked+0x93 Dec 24 16:06:03 chinatsu kernel: taskqueue_thread_loop() at taskqueue_thread_loop+0x3e Dec 24 16:06:03 chinatsu kernel: fork_exit() at fork_exit+0x133 Dec 24 16:06:03 chinatsu kernel: fork_trampoline() at fork_trampoline+0xe Dec 24 16:06:03 chinatsu kernel: --- trap 0, rip = 0, rsp = 0xffffff85fb2ebbb0, rbp = 0 --- Dec 24 16:06:03 chinatsu kernel: No core dumps found. Dec 24 16:06:04 chinatsu kernel: lock order reversal: Dec 24 16:06:04 chinatsu kernel: 1st 0xffffff85b9cb8dd8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2677 Dec 24 16:06:04 chinatsu kernel: 2nd 0xfffffe00092c5c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 Dec 24 16:06:04 chinatsu kernel: KDB: stack backtrace: Dec 24 16:06:04 chinatsu kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 24 16:06:04 chinatsu kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 24 16:06:04 chinatsu kernel: _witness_debugger() at _witness_debugger+0x2c Dec 24 16:06:04 chinatsu kernel: witness_checkorder() at witness_checkorder+0x844 Dec 24 16:06:04 chinatsu kernel: _sx_xlock() at _sx_xlock+0x61 Dec 24 16:06:04 chinatsu kernel: ufsdirhash_acquire() at ufsdirhash_acquire+0x33 Dec 24 16:06:04 chinatsu kernel: ufsdirhash_remove() at Dec 24 16:06:04 chinatsu kernel: ufsdirhash_remove+0x16 Dec 24 16:06:04 chinatsu kernel: ufs_dirremove() at ufs_dirremove+0x1bb Dec 24 16:06:04 chinatsu kernel: ufs_remove() at ufs_remove+0x92 Dec 24 16:06:04 chinatsu kernel: VOP_REMOVE_APV() at VOP_REMOVE_APV+0xb7 Dec 24 16:06:04 chinatsu kernel: kern_unlinkat() at kern_unlinkat+0x2eb Dec 24 16:06:04 chinatsu kernel: amd64_syscall() at amd64_syscall+0x30e Dec 24 16:06:04 chinatsu kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 24 16:06:04 chinatsu kernel: --- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x80090a22c, rsp = 0x7fffffff Dec 24 16:06:04 chinatsu kernel: ca88, rbp = 0x7fffffffdf20 --- Dec 24 16:06:04 chinatsu kernel: lock order reversal: Dec 24 16:06:04 chinatsu kernel: 1st 0xfffffe00266ddbd8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:849 Dec 24 16:06:04 chinatsu kernel: 2nd 0xfffffe002679a818 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 Dec 24 16:06:04 chinatsu kernel: KDB: stack backtrace: Dec 24 16:06:04 chinatsu kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 24 16:06:04 chinatsu kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 24 16:06:04 chinatsu kernel: _witness_debugger() at _witness_debugger+0x2c Dec 24 16:06:04 chinatsu kernel: witness_checkorder() at witness_checkorder+0x844 Dec 24 16:06:04 chinatsu kernel: __lockmgr_args() at __lockmgr_args+0x10d9 Dec 24 16:06:04 chinatsu kernel: vop_stdlock() at vop_stdlock+0x39 Dec 24 16:06:04 chinatsu kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf Dec 24 16:06:04 chinatsu kernel: _vn_lock() at _vn_lock+0x47 Dec 24 16:06:04 chinatsu kernel: vget() at vget+0x7b Dec 24 16:06:04 chinatsu kernel: devfs_allocv() at devfs_allocv+0x13f Dec 24 16:06:04 chinatsu kernel: devfs_root() at devfs_root+0x4d Dec 24 16:06:04 chinatsu kernel: vfs_donmount() at vfs_donmount+0xafa Dec 24 16:06:04 chinatsu kernel: sys_nmount() at sys_nmount+0x66 Dec 24 16:06:04 chinatsu kernel: amd64_syscall() at amd64_syscall+0x30e Dec 24 16:06:04 chinatsu kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 24 16:06:04 chinatsu kernel: --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a8d71c, rsp = 0x7fffffffccc8, rbp = 0x801009048 --- Dec 24 16:06:05 chinatsu named[1387]: starting BIND 9.8.3-P4 -t /var/named -u bind Dec 24 16:06:05 chinatsu kernel: Starting named. -- Best regards, Derek mailto:takeda@takeda.tk People say Microsoft paid 14M$ for using the Rolling Stones song 'Start me up' in their commercials. This is wrong. Microsoft payed 14M$ only for a part of the song. For instance, they didn't use the line 'You'll make a grown man cry'. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 00:43:23 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D7AB332; Tue, 25 Dec 2012 00:43:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id E47C98FC13; Tue, 25 Dec 2012 00:43:22 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qBP0hMRg003684; Mon, 24 Dec 2012 16:43:22 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qBP0hMLS003683; Mon, 24 Dec 2012 16:43:22 -0800 (PST) (envelope-from david) Date: Mon, 24 Dec 2012 16:43:22 -0800 From: David Wolfskill To: Andriy Gapon Subject: Re: stable/9 i386 panic [ACPI/timer?] Message-ID: <20121225004322.GE1867@albert.catwhisker.org> References: <20121224195818.GA1867@albert.catwhisker.org> <50D8C344.4090702@FreeBSD.org> <20121224211628.GB1867@albert.catwhisker.org> <50D8D8A6.60402@FreeBSD.org> <20121224223958.GC1867@albert.catwhisker.org> <50D8DDF8.5040807@FreeBSD.org> <20121224230425.GD1867@albert.catwhisker.org> <50D8E63B.5050804@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T6xhMxlHU34Bk0ad" Content-Disposition: inline In-Reply-To: <50D8E63B.5050804@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Dec 2012 00:43:23 -0000 --T6xhMxlHU34Bk0ad Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 25, 2012 at 01:33:15AM +0200, Andriy Gapon wrote: > ... > > (kgdb) p &th6 > > $21 =3D (struct timehands *) 0xc112a910 >=20 > Comparing the above and the following from an earlier email: > > (kgdb) p timehands > > $1 =3D (struct timehands * volatile) 0xc11ba910 > and the following: > > (kgdb) p th5 > > $7 =3D {th_counter =3D 0xc115174c, th_adjustment =3D 51068786373500,=20 > > th_scale =3D 1690726758248, th_offset_count =3D 3990081323, th_offset= =3D { > > sec =3D 25906, frac =3D 2278539681754952554}, th_microtime =3D { > > tv_sec =3D 1356376278, tv_usec =3D 192946}, th_nanotime =3D { > > tv_sec =3D 1356376278, tv_nsec =3D 192946562}, th_generation =3D 66= 9311,=20 > > th_next =3D 0xc11ba910} >=20 >=20 > I am quite sure that the impossible happened only because the faulty memo= ry made > it possible. Ah. Well, that's not unreasonable, then. I have (2) 1GB DIMMs + (2) 512MB DIMMs in the machine presently. Since I bought the 1GB DIMMs more recently, I'll just pull the 512MB DIMMs for now, and if that causes things to settle down, I'll plan on buying a couple more 1GBDIMMs to replace the 512MB DIMMs. Thank you very much for your help! > ... Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --T6xhMxlHU34Bk0ad Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDY9qkACgkQmprOCmdXAD291QCeOSDgoyDoVmeQEep1neax29YI 25UAn3J6jV69fWFz7Kgc4Hog9zOow1Nf =FInv -----END PGP SIGNATURE----- --T6xhMxlHU34Bk0ad-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 05:42:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98C7DF98; Tue, 25 Dec 2012 05:42:45 +0000 (UTC) (envelope-from olivier777a7@gmail.com) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by mx1.freebsd.org (Postfix) with ESMTP id 159E48FC14; Tue, 25 Dec 2012 05:42:43 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id w12so9112316lag.26 for ; Mon, 24 Dec 2012 21:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=e53pbmEe4yus1pqAV51dzsbm7DtF2kbV9vSrhgKG4v0=; b=E81UhbflvqrcqOOwlnqI96AyYpzRACn5ykMI98GOTpJTT34LYSIMpGna1/eBT+cvG5 GZVS+8Rp6AGhMWteQg7wGZfjFTgng1HPAhqMi50GrbB849BYyVRqqu7snXsio4UyzUrf uocS58dp7G0PANMZAoKTs+JyO+PmWFl6wU3/UKYDsAxSzLI8SF9QsVXEkKQejNBWFtQy 5PKoo9vPj7UuJo8Y2ZIb/eJvp+UsSJcuqbc8P2ec0i7xVohndZBDpXOxvqVYYgwi+dnT boyIHdHtF4ooPEG7YFm80pGBE7NcuZevZ+yQ0ELHpDKYf5jrs1AWq/0b/QCTvvUbG4ej sFqw== MIME-Version: 1.0 Received: by 10.112.23.233 with SMTP id p9mr9517554lbf.6.1356414162381; Mon, 24 Dec 2012 21:42:42 -0800 (PST) Received: by 10.114.78.41 with HTTP; Mon, 24 Dec 2012 21:42:42 -0800 (PST) Date: Mon, 24 Dec 2012 21:42:42 -0800 Message-ID: Subject: CAM hangs in 9-STABLE? [Was: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE] From: olivier To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, ken@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Dec 2012 05:42:45 -0000 Dear All It turns out that reverting to an older version of the mps driver did not fix the ZFS hangs I've been struggling with in 9.1 and 9-STABLE after all (they just took a bit longer to occur again, possibly just by chance). I followed steps along lines suggested by Andriy to collect more information when the problem occurs. Hopefully this will help figure out what's going on. As far as I can tell, what happens is that at some point IO operations to a bunch of drives that belong to different pools get stuck. For these drives, gstat shows no activity but 1 pending operation, as such: L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da1 I've been running gstat in a loop (every 100s) to monitor the machine. Just before the hang occurs, everything seems fine (see full gstat output below). Right after the hang occurs a number of drives seem stuck (see full gstat output below). Notably, some stuck drives are seen through the mps driver and others through the mpt driver. So the problem doesn't seem to be driver-specific. I have had the problem occur (at a lower frequency) on similar machines that don't use the mpt driver (and only have 1 disk provided through mps), so the problem doesn't seem to be caused by the mpt driver (and is likely not caused by defective hardware). Since based on the information I provided earlier Andriy thinks the problem might not originate in ZFS, perhaps that means that the problem is in the CAM layer? camcontrol tags -v (as suggested by Andriy) in the hung state shows for example (pass56:mpt1:0:8:20): dev_openings 254 (pass56:mpt1:0:8:20): dev_active 1 (pass56:mpt1:0:8:20): devq_openings 254 (pass56:mpt1:0:8:20): devq_queued 0 (pass56:mpt1:0:8:20): held 0 (pass56:mpt1:0:8:20): mintags 2 (pass56:mpt1:0:8:20): maxtags 255 (I'm not providing full camcontrol tags output below because I couldn't get it to run during the specific hang I documented most thoroughly; the example above is from a different occurrence of the hang). The buses don't seem completely frozen: if I manually remove drives while the machine is hanging, that's picked up by the mpt driver, which prints out corresponding messages to the console. But camcontrol reset all or rescan all don't seem to do anything. I've tried reducing vfs.zfs.vdev.min_pending and vfs.zfs.vdev.max_pending to 1, to no avail. Any suggestions to resolve this problem, work around it, or further investigate it would be greatly appreciated! Thanks a lot Olivier Detailed information: Output of procstat -a -kk when the machine is hanging is available at http://pastebin.com/7D2KtT35 (not putting it here because it's pretty long) dmesg is available at http://pastebin.com/9zJQwWJG . Note that I'm using LUN masking, so the "illegal requests" reported aren't really errors. Maybe one day if I get my problems sorted out I'll use geom multipathing instead. My kernel config is include GENERIC ident MYKERNEL options IPSEC device crypto options OFED # Infiniband protocol device mlx4ib # ConnectX Infiniband support device mlxen # ConnectX Ethernet support device mthca # Infinihost cards device ipoib # IP over IB devices options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering options KDB options DDB Full output of gstat just before the hang (at most 100s before the hang): L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da2/da2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da0/da0 1 85 48 79 4.7 35 84 0.5 0 0 0.0 24.3 da1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da1/da1 1 83 47 77 4.3 34 79 0.5 0 0 0.0 22.1 da4 1 1324 1303 21433 0.6 19 42 0.7 0 0 0.0 79.8 da3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da5 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da6 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da7 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da8 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da9 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da10 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da11 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da12 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da13 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da14 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da15 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da16 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da17 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da18 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da19 0 97 57 93 3.5 38 84 0.3 0 0 0.0 21.3 da20 0 85 47 69 3.3 36 86 0.4 0 0 0.0 16.8 da21 0 1666 1641 18992 0.3 23 43 0.4 0 0 0.0 57.9 da22 0 93 55 98 3.5 36 87 0.4 0 0 0.0 20.6 da23 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da24 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da25 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da26 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da27 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da28 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da29 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da30 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da31 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da32 0 1200 0 0 0.0 1198 11751 0.6 0 0 0.0 67.3 da33 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da34 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da35 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da36 0 81 44 67 2.0 35 84 0.3 0 0 0.0 10.1 da37 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da38 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da39 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da40 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da41 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da42 1 1020 999 22028 0.8 19 42 0.7 0 0 0.0 84.8 da43 0 1050 1029 23479 0.8 19 47 0.7 0 0 0.0 83.3 da44 1 1006 984 22758 0.8 21 46 0.6 0 0 0.0 84.8 da45 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da46 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da47 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da48 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da49 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da50 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 cd0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da4/da4 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da3/da3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da5/da5 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da6/da6 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da7/da7 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da8/da8 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da9/da9 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da10/da10 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da11/da11 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da12/da12 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da13/da13 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da14/da14 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da15/da15 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da16/da16 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da17/da17 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da18/da18 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da19/da19 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da20/da20 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da21/da21 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da22/da22 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da23/da23 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da24/da24 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da25/da25 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da26/da26 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 PART/da26/da26 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da26p1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da26p2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da26p3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da27/da27 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da28/da28 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da29/da29 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da30/da30 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da31/da31 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da32/da32 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da33/da33 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da34/da34 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da35/da35 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da36/da36 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da37/da37 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da38/da38 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da39/da39 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da40/da40 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da41/da41 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da42/da42 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da43/da43 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da44/da44 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da45/da45 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da46/da46 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da47/da47 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da48/da48 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da49/da49 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da50/da50 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/cd0/cd0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da26p1/da26p1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da26p2/da26p2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 LABEL/da26p1/da26p1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 gptid/84d4487b-34e3-11e2-b773-00259058949a 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da26p3/da26p3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 LABEL/da26p2/da26p2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 gptid/b4255780-34e3-11e2-b773-00259058949a 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/gptid/84d4487b-34e3-11e2-b773-00259058949a/gptid/84d4487b-34e3-11e2-b773-00259058949a 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da25 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/gptid/b4255780-34e3-11e2-b773-00259058949a/gptid/b4255780-34e3-11e2-b773-00259058949a 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da40 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da41 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da26p3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da29 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da30 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da24 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da6 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da7 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da16 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da17 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da20 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da21 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da37 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da23 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da4 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da43 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da44 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da22 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da33 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da45 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da3 Full output of gstat just after the hang (at most 100s after the hang): L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da2/da2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da0/da0 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da1/da1 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da4 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da5 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da6 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da7 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da8 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da9 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da10 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da11 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da12 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da13 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da14 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da15 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da16 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da17 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da18 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da19 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da20 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da21 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da22 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da23 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da24 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da25 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da26 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da27 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da28 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da29 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da30 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da31 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da32 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da33 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da34 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da35 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da36 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da37 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da38 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da39 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da40 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da41 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da42 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da43 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da44 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da45 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da46 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da47 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da48 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da49 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da50 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 cd0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da4/da4 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da3/da3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da5/da5 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da6/da6 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da7/da7 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da8/da8 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da9/da9 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da10/da10 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da11/da11 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da12/da12 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da13/da13 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da14/da14 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da15/da15 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da16/da16 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da17/da17 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da18/da18 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da19/da19 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da20/da20 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da21/da21 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da22/da22 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da23/da23 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da24/da24 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da25/da25 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da26/da26 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 PART/da26/da26 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da26p1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da26p2 1 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 da26p3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da27/da27 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da28/da28 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da29/da29 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da30/da30 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da31/da31 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da32/da32 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da33/da33 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da34/da34 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da35/da35 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da36/da36 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da37/da37 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da38/da38 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da39/da39 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da40/da40 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da41/da41 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da42/da42 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da43/da43 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da44/da44 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da45/da45 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da46/da46 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da47/da47 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da48/da48 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da49/da49 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da50/da50 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/cd0/cd0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da26p1/da26p1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da26p2/da26p2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 LABEL/da26p1/da26p1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 gptid/84d4487b-34e3-11e2-b773-00259058949a 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/da26p3/da26p3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 LABEL/da26p2/da26p2 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 gptid/b4255780-34e3-11e2-b773-00259058949a 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/gptid/84d4487b-34e3-11e2-b773-00259058949a/gptid/84d4487b-34e3-11e2-b773-00259058949a 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da25 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 DEV/gptid/b4255780-34e3-11e2-b773-00259058949a/gptid/b4255780-34e3-11e2-b773-00259058949a 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da40 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da41 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da26p3 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da29 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da30 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da24 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da6 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da7 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da16 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da17 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da20 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da21 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da37 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da23 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da1 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da4 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da43 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da44 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da22 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da33 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da45 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0 ZFS::VDEV/zfs::vdev/da3 On Thu, Dec 13, 2012 at 10:14 PM, olivier wrote: > For what it's worth, I think I might have solved my problem by reverting > to an older version of the mps driver. I checked out a recent version of > 9-STABLE and reversed the changes in > http://svnweb.freebsd.org/base?view=revision&revision=230592 (perhaps > there was a simpler way of reverting to the older mps driver). So far so > good, no hang even when hammering the file system. > > This does not conclusively prove that the new LSI mps driver is at fault, > but that seems to be a likely explanation. > > Thanks to everybody who pointed me in the right direction. Hope this helps > others who run into similar problems with 9.1 > Olivier > > > On Thu, Dec 13, 2012 at 10:14 AM, olivier wrote: > >> >> >> On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: >> >>> Google for "zfs deadman". This is already committed upstream and I >>> think that it >>> is imported into FreeBSD, but I am not sure... Maybe it's imported just >>> into the >>> vendor area and is not merged yet. >>> >> >> Yes, that's exactly what I had in mind. The logic for panicking makes >> sense. >> As far as I can tell you're correct that deadman is in the vendor area >> but not merged. Any idea when it might make it into 9-STABLE? >> Thanks >> Olivier >> >> >> >> >>> So, when enabled this logic would panic a system as a way of letting >>> know that >>> something is wrong. You can read in the links why panic was selected >>> for this job. >>> >>> And speaking FreeBSD-centric - I think that our CAM layer would be a >>> perfect place >>> to detect such issues in non-ZFS-specific way. >>> >>> -- >>> Andriy Gapon >>> >> >> > From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 08:18:42 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2856A5F7; Tue, 25 Dec 2012 08:18:42 +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 324858FC0C; Tue, 25 Dec 2012 08:18:40 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA10993; Tue, 25 Dec 2012 10:18:27 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TnPiU-000Iee-Ul; Tue, 25 Dec 2012 10:18:27 +0200 Message-ID: <50D9614F.6040306@FreeBSD.org> Date: Tue, 25 Dec 2012 10:18:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Derek Kulinski Subject: Re: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines References: <1824023197.20121223142308@takeda.tk> <50D87C56.70709@FreeBSD.org> <331959998.20121224101719@takeda.tk> <50D8E500.1070408@FreeBSD.org> <574019558.20121224161156@takeda.tk> In-Reply-To: <574019558.20121224161156@takeda.tk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Dec 2012 08:18:42 -0000 on 25/12/2012 02:11 Derek Kulinski said the following: > Hello Andriy, > > Monday, December 24, 2012, 3:28:00 PM, you wrote: > >> I've looked through the cores and it does look like in all cases some sort of >> memory corruption is a precursor to a subsequent crash. > >> I can't decidedly say if the corruptions are caused by the hardware, by some >> code overwriting random memory locations ("rogue" driver) or by a "simpler" bug >> like use after free. > >> I am always inclined to suspect the hardware first. > >> You can try to reproduce the problem with some additional checks enabled in the >> kernel. Those should catch the problem earlier and thus make its source clearer. > >> I recommend the following: >> options INVARIANTS >> options INVARIANT_SUPPORT >> options WITNESS >> options DEBUG_MEMGUARD >> makeoptions DEBUG+="-DDEBUG" > >> The last is really needed only for the ZFS and OpenSolaris compat code. It make >> result in some extra noise from unrelated subsystems. >> Perhaps you could just add "#define DEBUG" to >> sys/cddl/contrib/opensolaris/uts/common/sys/debug.h. I haven't tested this >> approach though. > >> Also, please put vm.memguard.desc="arc_buf_hdr_t" into loader.conf. > >> Please note that these options will make your system significantly slower. > > I recompiled the kernel and is running with options you specified (I > enabled DEBUG in the file). > > Anyway even at boot time I started getting following warnings, is this > anything: These witness warning are OK-ish. Watch for panics. BTW, I should have said this earlier. Whatever the kind of the corruptions it would be much worse if a corruption would get propagated to the stable storage. Especially if it would be in any kind of pool metadata. So, your data is at great risk now. Please also take measures to back it up. Preferably by using a different system. > Dec 24 16:06:03 chinatsu kernel: Creating and/or trimming log files > Dec 24 16:06:03 chinatsu kernel: lock order reversal: > Dec 24 16:06:03 chinatsu kernel: 1st 0xffffffff80bf5780 pf task mtx (pf task mtx) @ /usr/src/sys/contrib/pf/net/pf.c:3330 > Dec 24 16:06:03 chinatsu kernel: . > Dec 24 16:06:03 chinatsu kernel: 2nd 0xfffffe0009211af8 radix node head (radix node head) @ /usr/src/sys/net/route.c:384 > Dec 24 16:06:03 chinatsu kernel: KDB: stack backtrace: > Dec 24 16:06:03 chinatsu kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Dec 24 16:06:03 chinatsu kernel: kdb_backtrace() at kdb_backtrace+0x37 > Dec 24 16:06:03 chinatsu kernel: _witness_debugger() at _witness_debugger+0x2c > Dec 24 16:06:03 chinatsu kernel: witness_checkorder() at witness_checkorder+0x844 > Dec 24 16:06:03 chinatsu kernel: _rw_rlock() at > Dec 24 16:06:03 chinatsu kernel: Starting syslogd. > Dec 24 16:06:03 chinatsu kernel: _rw_rlock+0x81 > Dec 24 16:06:03 chinatsu kernel: rtalloc1_fib() at rtalloc1_fib+0x11c > Dec 24 16:06:03 chinatsu kernel: rtalloc_ign_fib() at rtalloc_ign_fib+0xc5 > Dec 24 16:06:03 chinatsu kernel: pf_routable() at pf_routable+0x1fd > Dec 24 16:06:03 chinatsu kernel: pf_test_rule() at pf_test_rule+0x6cf > Dec 24 16:06:03 chinatsu kernel: pf_test() at pf_test+0xf58 > Dec 24 16:06:03 chinatsu kernel: pf_check_in() at pf_check_in+0x2b > Dec 24 16:06:03 chinatsu kernel: pfil_run_hooks() at pfil_run_hooks+0xd2 > Dec 24 16:06:03 chinatsu kernel: ip_input() at ip_input+0x2dc > Dec 24 16:06:03 chinatsu kernel: netisr_dispatch_src() at netisr_dispatch_src+0x170 > Dec 24 16:06:03 chinatsu kernel: ether_demux() at ether_demux+0x17d > Dec 24 16:06:03 chinatsu kernel: ether_nh_input() at ether_nh_input+0x209 > Dec 24 16:06:03 chinatsu kernel: netisr_dispatch_src() at netisr_dispatch_src+0x170 > Dec 24 16:06:03 chinatsu kernel: alc_int_task() at alc_int_task+0x2ff > Dec 24 16:06:03 chinatsu kernel: taskqueue_run_locked() at taskqueue_run_locked+0x93 > Dec 24 16:06:03 chinatsu kernel: taskqueue_thread_loop() at taskqueue_thread_loop+0x3e > Dec 24 16:06:03 chinatsu kernel: fork_exit() at fork_exit+0x133 > Dec 24 16:06:03 chinatsu kernel: fork_trampoline() at fork_trampoline+0xe > Dec 24 16:06:03 chinatsu kernel: --- trap 0, rip = 0, rsp = 0xffffff85fb2ebbb0, rbp = 0 --- > Dec 24 16:06:03 chinatsu kernel: No core dumps found. > Dec 24 16:06:04 chinatsu kernel: lock order reversal: > Dec 24 16:06:04 chinatsu kernel: 1st 0xffffff85b9cb8dd8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2677 > Dec 24 16:06:04 chinatsu kernel: 2nd 0xfffffe00092c5c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 > Dec 24 16:06:04 chinatsu kernel: KDB: stack backtrace: > Dec 24 16:06:04 chinatsu kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Dec 24 16:06:04 chinatsu kernel: kdb_backtrace() at kdb_backtrace+0x37 > Dec 24 16:06:04 chinatsu kernel: _witness_debugger() at _witness_debugger+0x2c > Dec 24 16:06:04 chinatsu kernel: witness_checkorder() at witness_checkorder+0x844 > Dec 24 16:06:04 chinatsu kernel: _sx_xlock() at _sx_xlock+0x61 > Dec 24 16:06:04 chinatsu kernel: ufsdirhash_acquire() at ufsdirhash_acquire+0x33 > Dec 24 16:06:04 chinatsu kernel: ufsdirhash_remove() at > Dec 24 16:06:04 chinatsu kernel: ufsdirhash_remove+0x16 > Dec 24 16:06:04 chinatsu kernel: ufs_dirremove() at ufs_dirremove+0x1bb > Dec 24 16:06:04 chinatsu kernel: ufs_remove() at ufs_remove+0x92 > Dec 24 16:06:04 chinatsu kernel: VOP_REMOVE_APV() at VOP_REMOVE_APV+0xb7 > Dec 24 16:06:04 chinatsu kernel: kern_unlinkat() at kern_unlinkat+0x2eb > Dec 24 16:06:04 chinatsu kernel: amd64_syscall() at amd64_syscall+0x30e > Dec 24 16:06:04 chinatsu kernel: Xfast_syscall() at Xfast_syscall+0xf7 > Dec 24 16:06:04 chinatsu kernel: --- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x80090a22c, rsp = 0x7fffffff > Dec 24 16:06:04 chinatsu kernel: ca88, rbp = 0x7fffffffdf20 --- > Dec 24 16:06:04 chinatsu kernel: lock order reversal: > Dec 24 16:06:04 chinatsu kernel: 1st 0xfffffe00266ddbd8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:849 > Dec 24 16:06:04 chinatsu kernel: 2nd 0xfffffe002679a818 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 > Dec 24 16:06:04 chinatsu kernel: KDB: stack backtrace: > Dec 24 16:06:04 chinatsu kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Dec 24 16:06:04 chinatsu kernel: kdb_backtrace() at kdb_backtrace+0x37 > Dec 24 16:06:04 chinatsu kernel: _witness_debugger() at _witness_debugger+0x2c > Dec 24 16:06:04 chinatsu kernel: witness_checkorder() at witness_checkorder+0x844 > Dec 24 16:06:04 chinatsu kernel: __lockmgr_args() at __lockmgr_args+0x10d9 > Dec 24 16:06:04 chinatsu kernel: vop_stdlock() at vop_stdlock+0x39 > Dec 24 16:06:04 chinatsu kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf > Dec 24 16:06:04 chinatsu kernel: _vn_lock() at _vn_lock+0x47 > Dec 24 16:06:04 chinatsu kernel: vget() at vget+0x7b > Dec 24 16:06:04 chinatsu kernel: devfs_allocv() at devfs_allocv+0x13f > Dec 24 16:06:04 chinatsu kernel: devfs_root() at devfs_root+0x4d > Dec 24 16:06:04 chinatsu kernel: vfs_donmount() at vfs_donmount+0xafa > Dec 24 16:06:04 chinatsu kernel: sys_nmount() at sys_nmount+0x66 > Dec 24 16:06:04 chinatsu kernel: amd64_syscall() at amd64_syscall+0x30e > Dec 24 16:06:04 chinatsu kernel: Xfast_syscall() at Xfast_syscall+0xf7 > Dec 24 16:06:04 chinatsu kernel: --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a8d71c, rsp = 0x7fffffffccc8, rbp = 0x801009048 --- > Dec 24 16:06:05 chinatsu named[1387]: starting BIND 9.8.3-P4 -t /var/named -u bind > Dec 24 16:06:05 chinatsu kernel: Starting named. > > > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 15:37:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E9E03EE for ; Tue, 25 Dec 2012 15:37:47 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from mproxy8.sbb.rs (mproxy8.sbb.rs [89.216.2.98]) by mx1.freebsd.org (Postfix) with ESMTP id EFB458FC0A for ; Tue, 25 Dec 2012 15:37:46 +0000 (UTC) Received: from faust.localdomain (cable-178-148-101-80.dynamic.sbb.rs [178.148.101.80]) by mproxy8.sbb.rs (8.14.4/8.14.4) with ESMTP id qBPFFbaB006497 for ; Tue, 25 Dec 2012 16:15:43 +0100 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at SBB mail Received: by faust.localdomain (Postfix, from userid 1001) id 95804A41EB6; Tue, 25 Dec 2012 16:15:32 +0100 (CET) Date: Tue, 25 Dec 2012 16:15:32 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: 9.1 minimal ram requirements Message-ID: <20121225151532.GA1404@faust.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy8.sbb.rs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Dec 2012 15:37:47 -0000 So, it's fine and recommended to remove ctl device from kernel? I installed from image on the site two weeks ago and consider it release. Zoran From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 17:30:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E20060B for ; Tue, 25 Dec 2012 17:30:47 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by mx1.freebsd.org (Postfix) with ESMTP id C194C8FC12 for ; Tue, 25 Dec 2012 17:30:46 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id c1so9842877lah.9 for ; Tue, 25 Dec 2012 09:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=02cyQ3xyNySjyq+TwtLeS213h8zHivGDuYHgxXX7uvE=; b=aOdqavis0ztVIWVdC/HfiPmH/Wl5fWHR5fuv7aTP4m208nVU80YAPtCY9gzbC7s4J2 6qn+aXKGf1R/wLMyfMRjFyH3CG8Wgb3pywInwTKlFXr0pnGDolNaNE71NTuNvYDrSV/y 0tMvz+kic9MVnz9DEzVz7YWRyVwmeBS1Cqo6+R6zqALIG963Ckiswlfyyak0MXiZ2y1g w/FY14efG/1XUhJS6fqkttLO1m6bxr8z3QsmXhLLb3tXPO5tDETX+CTSb8PDgD9wOIzC 1NXpV92vJa1Oh7Wew4AR27spqKjoVO+a3qF1plWSd2liDjqsN2RYYOLgyouqfve1HOA3 fn8A== MIME-Version: 1.0 Received: by 10.112.14.46 with SMTP id m14mr9997174lbc.98.1356456645261; Tue, 25 Dec 2012 09:30:45 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.11.165 with HTTP; Tue, 25 Dec 2012 09:30:45 -0800 (PST) In-Reply-To: <20121225151532.GA1404@faust.sbb.rs> References: <20121225151532.GA1404@faust.sbb.rs> Date: Tue, 25 Dec 2012 18:30:45 +0100 X-Google-Sender-Auth: 6Y66OUHmFnFlpX5fMr4eNsZFp14 Message-ID: Subject: Re: 9.1 minimal ram requirements From: CeDeROM To: Zoran Kolic Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Dec 2012 17:30:47 -0000 I always considered FreeBSD to be the most unabiguous, straightforward and sometimes even raw, but still extremely powerful and innovative, operating system out there. Seeing 9.1-RELEASE instead 9.1-PRERELASE or 9.1-RC4 is also a bad suprise for me... I have fallback into RC3 and I think the RELEASE files should be removed as well because there was no RELEASE yet. There is no rush to get RELEASE, I am sure it is better to get RC4, RC5, RC6 and then a RELEASE "when its ready". When people get buggy and unstable RELEASE and install it on a production systems they will neither come back to the system nor even support it in future :-( -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 18:02:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94F2795F for ; Tue, 25 Dec 2012 18:02:59 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0FAA08FC0A for ; Tue, 25 Dec 2012 18:02:58 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id d3so9852448lah.3 for ; Tue, 25 Dec 2012 10:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tKTpWAqBjqyukSN2wRPu/Dtj0ia5TemibulxIfRnKvM=; b=GZUW5QmK67+TL7VZzo1Ov0pfpvu0+P/rK3dpaUqQWGIenjga2IZI8Vm8HYxVsYFrBJ yD/65yxpo9JmSk0J1DZv4wD8e91Rm2knmgqmbWsFmQgb3v+AvnHm359NVGeGxQmVaqeQ mMZBLFIJfAIpFMYK2fTtV2jHLPWh0xbnvnpZc1uIm3WUH5NjkfIl9UyAD7LuLk8Ex0jq rB6Y7dMJXylgXvUQMgULHKOzreRmBIBE7f882j09IXL/JbCkt/2H2pAhCmeer0B+IIpT VnTTfUFLRu4EdCYBlUubObt0Xp9TZOq/H/OEi+IyS/9JsTcbKhnSBJbll8yHJ29qZX0y oHMw== MIME-Version: 1.0 Received: by 10.152.105.103 with SMTP id gl7mr23051535lab.10.1356458577823; Tue, 25 Dec 2012 10:02:57 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.11.165 with HTTP; Tue, 25 Dec 2012 10:02:57 -0800 (PST) In-Reply-To: References: <20121225151532.GA1404@faust.sbb.rs> Date: Tue, 25 Dec 2012 19:02:57 +0100 X-Google-Sender-Auth: DkO_9gQS_iVYRN2pw96SWC8cdd4 Message-ID: Subject: Re: 9.1 minimal ram requirements From: CeDeROM To: kpaasial@gmail.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Dec 2012 18:02:59 -0000 On Tue, Dec 25, 2012 at 6:41 PM, Kimmo Paasiala wrote: > If it works for 99.99% percent of the users and fails for the > remaining miniscule percentage because they have a very peculiar > hardware, very small amount of ram etc, should the release called > buggy and unstable? I really don't think so. Hey hey :-) Its rather a matter of organization, not to rush towards a release (see "do we get 9.1 before christmas"), if there are known issues (see security, etc). I also started to use RC myself as I found some stuff suprising on 9.0. But when I consider someone to use FreeBSD while there are release made before release, or rarely used stuff added by default that takes 1000% of standard kernel RAM usage, or similar - this does not look serious, this makes people think "i will use linux, things like this happens there all the time but i have more drivers", etc, etc. Even for FreeBSD enhousiast it is hard to discuss with people on better organization of FreeBSD over Linux in that case. From what I read there are people working hard to make a release, but we should not rush them at cost of quality. I am still with FreeBSD and I really like it more than Linux, this is why I think quality is more important than bleeding-edge here :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Tue Dec 25 21:16:06 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEF94383; Tue, 25 Dec 2012 21:16:06 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id BD39D8FC12; Tue, 25 Dec 2012 21:16:06 +0000 (UTC) Received: from localhost.takeda.tk (takeda-ws2.lan [10.0.0.123]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id qBPLG58K022933 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 25 Dec 2012 13:16:05 -0800 (PST) (envelope-from takeda@takeda.tk) Date: Tue, 25 Dec 2012 13:06:35 -0800 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <1501851114.20121225130635@takeda.tk> To: Andriy Gapon Subject: Re: FreeBSD 9.1-RELEASE crashes almost daily; backtraces always list zfs routines In-Reply-To: <50D9614F.6040306@FreeBSD.org> References: <1824023197.20121223142308@takeda.tk> <50D87C56.70709@FreeBSD.org> <331959998.20121224101719@takeda.tk> <50D8E500.1070408@FreeBSD.org> <574019558.20121224161156@takeda.tk> <50D9614F.6040306@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Dec 2012 21:16:07 -0000 Hello Andriy, Tuesday, December 25, 2012, 12:18:23 AM, you wrote: >> I recompiled the kernel and is running with options you specified (I >> enabled DEBUG in the file). >> >> Anyway even at boot time I started getting following warnings, is this >> anything: > These witness warning are OK-ish. > Watch for panics. Sadly (I guess :) I did not have crash today (I don't see even a warning at that time), I'll update when it happens. Will also try to run that task today and will see if it will do anything. > BTW, I should have said this earlier. Whatever the kind of the corruptions it > would be much worse if a corruption would get propagated to the stable storage. > Especially if it would be in any kind of pool metadata. > So, your data is at great risk now. > Please also take measures to back it up. Preferably by using a different system. I'm backing it up using zfs send since dump doesn't appear to work on ZFS. Anyway zpool scrub does not show any problems... I performed my last scan when I started this thread. -- Best regards, Derek mailto:takeda@takeda.tk Hand over the calculator, friends don't let friends derive drunk From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 10:35:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C37D4FF8 for ; Wed, 26 Dec 2012 10:35:16 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp1.insight.synacor.com [208.47.185.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3298FC14 for ; Wed, 26 Dec 2012 10:35:15 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=AYoz7grG c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=BbwyZmbTN3oA:10 a=S3ChV_DLfNiJnN1w-FAA:9 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:57626] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 8A/59-25232-CD2DAD05; Wed, 26 Dec 2012 05:35:08 -0500 Date: Wed, 26 Dec 2012 05:35:08 -0500 Message-ID: <8A.59.25232.CD2DAD05@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Can't build kernel with ndis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Dec 2012 10:35:16 -0000 I am trying to build FreeBSD update, STABLE branch, and buildkernel apparently snagged on ndis, which I don't want to do without. According to "man ndis", I need in kernel config options NDISAPI device ndis device wlan which I have: device wlan # 802.11 support options NDISAPI # This is in the hope of enabling Hiro USB wireless adapter device ndis Error message, final lines of buildkernel log file, are MAKE=make sh /usr/src/sys/conf/newvers.sh SANDY /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wred undant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wm issing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I /usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_gl obal.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param la rge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding - fstack-protector -Werror vers.c linking kernel.debug if_ndis.o: In function `ndis_detach': /usr/src/sys/dev/if_ndis/if_ndis.c:1084: undefined reference to `ndis_free_amem' if_ndis.o: In function `ndis_attach': /usr/src/sys/dev/if_ndis/if_ndis.c:563: undefined reference to `ndis_alloc_amem' *** [kernel.debug] Error code 1 Stop in /usr/obj/usr/src/sys/SANDY. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. Tom From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 10:35:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA86E11F; Wed, 26 Dec 2012 10:35:24 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD578FC08; Wed, 26 Dec 2012 10:35:23 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id dq12so3908162wgb.12 for ; Wed, 26 Dec 2012 02:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=jVh9yc5RDbBdobNPNVpV68xdMbhhUXwDVh3JSbAnD0U=; b=HYr6quzv42CPBu6zM4HLBGZYRl61KC/iNtNAoCc+ZyIJABqmJeIo1J0SSIqYjlc2Oi vyB6RvPNunv/Dpjoy1PtdoOzIEXiV8QWzFraaHl0YgLMoer/TqMeg/owGc17Yg5x6lB8 x8VB2eixiYnLFaB/Lex3XCqJLOl1tVw3xTUm2hdLGXMwGOtxShEO9ZF0V+ss9sp15W0w Sn3I2eGQfs1lsyGqLBuYBs/HR7mSO+vB+9OlHkSkodt8HZcurR5sitFm7idN1nr9w9dg UnYzmF65f4+JzpJiRDLMjqFfowr9fq/wWLohUM66cg+fPx5SYc9sj5JIQx5vA9uxxuSw 6JFg== MIME-Version: 1.0 Received: by 10.180.103.136 with SMTP id fw8mr34174081wib.27.1356514383056; Wed, 26 Dec 2012 01:33:03 -0800 (PST) Received: by 10.216.172.197 with HTTP; Wed, 26 Dec 2012 01:33:02 -0800 (PST) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> Date: Wed, 26 Dec 2012 11:33:02 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: freebsd-stable@freebsd.org, FreeBSD current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Dec 2012 10:35:25 -0000 On Mon, Dec 24, 2012 at 6:07 AM, Kimmo Paasiala wrote: > On Sat, Dec 22, 2012 at 7:49 PM, =C5=81ukasz W=C4=85sikowski > wrote: >> W dniu 2012-12-22 18:14, Ben Morrow pisze: >>> Quoth =3D?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ=3D=3D?=3D : >>>> W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: >>>> >>>>> Yeah, this is problem in network.subr. An interface is not recognized >>>>> as IPv6 capable if the interface is not in "ipv6_network_interfaces" >>>>> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it >>>>> "just works" because the interface is always assumed to be IPv4 >>>>> capable. >>>> >>>> Ok, I used ifconfig_em0_ipv6=3D"up" and it worked. So it looks like th= is: >>> >>> The documented way to do this is to just set the link-local address in >>> ifconfig_IF_ipv6, since an interface is required to have a link-local >>> address. Either configure an fe80:: address explicitly or set >>> >>> ifconfig_em0_ipv6=3D"inet6 auto_linklocal" >>> >>> Alternatively, if you set ipv6_activate_all_interfaces all interfaces >>> will be considered IPv6-capable. >> >> link-local address is assigned by default, even with ifconfig_IF_ipv6=3D= "up". >> >> root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf ; ifconfig >> em0 | grep -E '^[[:space:]]*inet6' | head -2 >> hostname=3D"freebsd" >> ifconfig_em0=3D"up" >> ipv4_addrs_em0=3D"192.168.168.20-24/24" >> defaultrouter=3D"192.168.168.1" >> ipv6_network_interfaces=3D"em0" >> ipv6_defaultrouter=3D"2001:6a0:1cb::ffff" >> ifconfig_em0_ipv6=3D"up" >> ipv6_addrs_em0=3D"2001:6a0:1cb::1-e/128" >> sshd_enable=3D"YES" >> dumpdev=3D"NO" >> named_enable=3D"YES" >> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1 >> inet6 2001:6a0:1cb::1 prefixlen 128 >> >> Of course using "inet6 auto_linklocal" instead of "up" seems a better >> way to do it, thank you for this tip. >> >> -- >> best regards, >> Lukasz Wasikowski > > > I have put up the patch at github as: > > https://gist.github.com/4362018 > > This version should work with just the ipv6_addrs_IF in rc.conf(5). I > changed the detection of ipv6 interfaces so that just having the > ipv6_addrs_IF line is enough. > > -Kimmo I've revised the patch again and updated it at gihub, https://gist.github.com/4362018. It can now be applied at top level of sources (/usr/src typically). It now does the deconfiguration in reverse order of the configuration, meaning the aliases configured with ipv6_addrs_IF are removed before the ones configured with ifconfig_IF_aliasN=3D"inet6 ...". Also as noted in my previous message it's possible to configure all IPv6 addresses with a single ipv6_addrs_IF line in rc.conf: ipv6_addrs_re0=3D"2001:db8:1111:2222::1-4/64" I consider this version of the patch pretty much completed work. It applies cleanly to HEAD version r244694 and I don't see why it wouldn't work in HEAD as well. Now, is there any interest in seeing this feature as part of future versions of FreeBSD? Could it be incorporated to HEAD and then MFC'ed to 9-STABLE if it turns out it's seen as a useful feature? Regards, Kimmo Paasiala From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 11:14:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F40E3784; Wed, 26 Dec 2012 11:14:49 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id 743EC8FC14; Wed, 26 Dec 2012 11:14:49 +0000 (UTC) Received: from [10.10.1.100] (unknown [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 544AEB8D2C; Wed, 26 Dec 2012 12:14:40 +0100 (CET) X-DKIM: OpenDKIM Filter v2.5.2 mail.tyknet.dk 544AEB8D2C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1356520480; bh=CuLODVjCH1lFv8bAVGLYfsMEJuA5Llg59mM1WdVELws=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=bKV5jW4pdkl1u1bTpjZrF6i9G8n7/qUfpAafuogYmJa2pedA0ZRFW3TfwTHlwVMgq vpZZH7dP3oke8SXjlIT448OLr213I7SbdpLq1GBm56w2Nl6iQOV2TznhvEPBrQT9K+ bChn8V0wpv+8g/Gigw47vs7svozSxrVxa9sJWVDs= Message-ID: <50DADC1C.2000203@gibfest.dk> Date: Wed, 26 Dec 2012 12:14:36 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: bz@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Dec 2012 11:14:50 -0000 On 26-12-2012 10:33, Kimmo Paasiala wrote: > Now, is there any interest in seeing this feature as part of future > versions of FreeBSD? Could it be incorporated to HEAD and then MFC'ed > to 9-STABLE if it turns out it's seen as a useful feature? Yes please! I've been waiting for this for a while, as it will greatly simplify my rc.conf on a whole bunch of jail hosts. I've spoken with bz@ about this at eurobsdcon in November 2011 and he agreed that it is a missing feature, so I suspect it is a matter of time before your patch is picked up by a committer. Thank you for your work! Best regards Thomas Steen Rasmussen ps. bz@ cc'ed so he sees this thread From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 14:44:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13ACAB51 for ; Wed, 26 Dec 2012 14:44:48 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 89B958FC08 for ; Wed, 26 Dec 2012 14:44:46 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBQEijsJ011194 for ; Wed, 26 Dec 2012 07:44:46 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBQEiMFX074149; Wed, 26 Dec 2012 07:44:22 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Can't build kernel with ndis From: Ian Lepore To: Thomas Mueller In-Reply-To: <8A.59.25232.CD2DAD05@smtp01.insight.synacor.com> References: <8A.59.25232.CD2DAD05@smtp01.insight.synacor.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Dec 2012 07:44:22 -0700 Message-ID: <1356533062.1144.26.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Dec 2012 14:44:48 -0000 On Wed, 2012-12-26 at 05:35 -0500, Thomas Mueller wrote: > I am trying to build FreeBSD update, STABLE branch, and buildkernel apparently snagged on ndis, which I don't want to do without. According to "man ndis", I need in kernel config > > options NDISAPI > device ndis > device wlan > > which I have: > > device wlan # 802.11 support > options NDISAPI # This is in the hope of enabling Hiro USB wireless adapter > device ndis > > Error message, final lines of buildkernel log file, are > > MAKE=make sh /usr/src/sys/conf/newvers.sh SANDY > /usr/local/bin/svnversion > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wred > undant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wm > issing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I > /usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_gl > obal.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param la > rge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding - > fstack-protector -Werror vers.c > linking kernel.debug > if_ndis.o: In function `ndis_detach': > /usr/src/sys/dev/if_ndis/if_ndis.c:1084: undefined reference to `ndis_free_amem' > if_ndis.o: In function `ndis_attach': > /usr/src/sys/dev/if_ndis/if_ndis.c:563: undefined reference to `ndis_alloc_amem' > *** [kernel.debug] Error code 1 > > Stop in /usr/obj/usr/src/sys/SANDY. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > *** [buildkernel] Error code 1 > > Stop in /usr/src. Try adding "device pccard" -- Ian From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 17:03:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38C0A1E1 for ; Wed, 26 Dec 2012 17:03:00 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from mproxy8.sbb.rs (mproxy8.sbb.rs [89.216.2.98]) by mx1.freebsd.org (Postfix) with ESMTP id B3EDF8FC12 for ; Wed, 26 Dec 2012 17:02:59 +0000 (UTC) Received: from faust.localdomain (cable-178-148-111-64.dynamic.sbb.rs [178.148.111.64]) by mproxy8.sbb.rs (8.14.4/8.14.4) with ESMTP id qBQH2kDP011089; Wed, 26 Dec 2012 18:02:51 +0100 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at SBB mail Received: by faust.localdomain (Postfix, from userid 1001) id 46616A41E6A; Wed, 26 Dec 2012 18:02:33 +0100 (CET) Date: Wed, 26 Dec 2012 18:02:33 +0100 From: Zoran Kolic To: CeDeROM Subject: Re: 9.1 minimal ram requirements Message-ID: <20121226170233.GA1408@faust.sbb.rs> References: <20121225151532.GA1404@faust.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy8.sbb.rs Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Dec 2012 17:03:00 -0000 > Seeing 9.1-RELEASE instead 9.1-PRERELASE > or 9.1-RC4 is also a bad suprise for me... I assume it does not look like release is the lack of packages. Simply, I installed and compiled from ports. Cannot say if it stands on the site as a decoration, but I have it on desktop and laptop and found it a serious piece of work. The point is that I had to install, since I had had two new computers waiting blank. If no-one has any idea on the subject, I will just remove the line in kernel. Hopes are that old "make reinstallkernel KERNCONF..." still works. Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 17:28:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C50445AA for ; Wed, 26 Dec 2012 17:28:27 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by mx1.freebsd.org (Postfix) with ESMTP id 42A2E8FC0A for ; Wed, 26 Dec 2012 17:28:26 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id c1so11066713lah.9 for ; Wed, 26 Dec 2012 09:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QourDp5/BG1WsQFdkV/WJZNpeYg8FXpGbDFfQfRuMfA=; b=VAG4U/ZA47hZ4FVYkRmfJlHl+MvzLECnwEjzPjlL7pvuDqTqbFdCozJBVaF4J6RZGB CCNjSEwO0UxtlkkNJ3ZbWUCBDFWaEHWxOHa+lHRqeDbASxSLHqv+G8XYeL4dhvXoA0Wq vMYWR4fn7dTItNpCnjnfw5ZjhNnSaGaDgumxhLXox7TeUii78dDd8CXMqwAAuTIvdxBJ fAoXMhywQZEdDtk1WJ3wNjsl7pwEvvpid6qByFGBuvd6eLfsRAc16RXdJQFCckClPWBU qG3yHV94SII88JIiqko9VOgo+g5CpRdgYxcesYuANGCpoWcP5OkBY4ATYyrS3o/AAu3T mAdQ== MIME-Version: 1.0 Received: by 10.152.147.103 with SMTP id tj7mr26404095lab.54.1356542906063; Wed, 26 Dec 2012 09:28:26 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.11.165 with HTTP; Wed, 26 Dec 2012 09:28:25 -0800 (PST) In-Reply-To: <20121226170233.GA1408@faust.sbb.rs> References: <20121225151532.GA1404@faust.sbb.rs> <20121226170233.GA1408@faust.sbb.rs> Date: Wed, 26 Dec 2012 18:28:25 +0100 X-Google-Sender-Auth: NLYhGeJIjTYxfoOq-YsGfJheF30 Message-ID: Subject: Re: 9.1 minimal ram requirements From: CeDeROM To: Zoran Kolic Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Dec 2012 17:28:27 -0000 On Wed, Dec 26, 2012 at 6:02 PM, Zoran Kolic wrote: >> Seeing 9.1-RELEASE instead 9.1-PRERELASE >> or 9.1-RC4 is also a bad suprise for me... > > I assume it does not look like release is the lack > of packages. Simply, I installed and compiled from > ports. Making a Release is a well defined process as I read on http://www.freebsd.org/doc/en/articles/releng/release-proc.html and it has its precisely defined meaning. If we loose that meaning the process is irrelevant and so the word "RELEASE". Process stands for quality I guess... There are two extremely important sentences imo at the end of this document: "FreeBSD releases must always be reproducible." - this way we get system that behaves exactly the same after some time, this is very important. "Local hacks in the release engineer's environment are not acceptable." - this is what happens now? > Cannot say if it stands on the site as a > decoration, but I have it on desktop and laptop > and found it a serious piece of work. > The point is that I had to install, since I had had > two new computers waiting blank. 9.1-RC3 works just fine as well for some weeks :-) When your computers are not production machines I also recommend this to you Zoran to test RC in order to make RELEASE a better product. What you have now is labeled as RELEASE but it is a decoration. The "RELEASE" will be different from what you have found and installed (I think there are already versions with different tags available). This is really the thing that pushed me away from Linux :-( > If no-one has any idea on the subject, I will just > remove the line in kernel. Hopes are that old > "make reinstallkernel KERNCONF..." still works. Good luck :-) However if you simply want to diable that RAM consuming function there is a switch that can disable it and make install possible..? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 17:43:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1BD4955 for ; Wed, 26 Dec 2012 17:43:27 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from mproxy8.sbb.rs (mproxy8.sbb.rs [89.216.2.98]) by mx1.freebsd.org (Postfix) with ESMTP id 65E648FC0A for ; Wed, 26 Dec 2012 17:43:27 +0000 (UTC) Received: from faust.localdomain (cable-178-148-111-64.dynamic.sbb.rs [178.148.111.64]) by mproxy8.sbb.rs (8.14.4/8.14.4) with ESMTP id qBQHhKiq007626; Wed, 26 Dec 2012 18:43:26 +0100 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at SBB mail Received: by faust.localdomain (Postfix, from userid 1001) id CA3CFA41EB6; Wed, 26 Dec 2012 18:43:04 +0100 (CET) Date: Wed, 26 Dec 2012 18:43:04 +0100 From: Zoran Kolic To: CeDeROM Subject: Re: 9.1 minimal ram requirements Message-ID: <20121226174304.GA1397@faust.sbb.rs> References: <20121225151532.GA1404@faust.sbb.rs> <20121226170233.GA1408@faust.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy8.sbb.rs Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Dec 2012 17:43:27 -0000 > 9.1-RC3 works just fine as well for some weeks :-) When your computers > are not production machines I also recommend this to you Zoran to test > RC in order to make RELEASE a better product. What you have now is > labeled as RELEASE but it is a decoration. The "RELEASE" will be > different from what you have found and installed (I think there are > already versions with different tags available). This is really the > thing that pushed me away from Linux :-( I removed the line and it booted just fine. To me, 9.1 is probably the best looking release, but it might be due to new hardware. I'n not aware what is going on, regarding release or "release". At full speed I support the way devel team does the work. And contrary, the team has to bear with users, who want to know. I had new desktop and new laptop waiting, since power surge killed some devices at my home. And I waited for 3 months. None could say I was impatient. The release image is on the site. And, if you change RC3 to RELEASE in browser, there is even more. Why would serious guys keep those files available, if not for usage? My best guess is that some packages compile made all that fuss. What else might be? Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Wed Dec 26 18:03:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A2CF150 for ; Wed, 26 Dec 2012 18:03:44 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9938FC14 for ; Wed, 26 Dec 2012 18:03:43 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id qd14so10534108ieb.20 for ; Wed, 26 Dec 2012 10:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o4IyQLF+mDzr4CnSB4zfgyKqBUbxiuo3VclK60/9RSc=; b=WrAtEDfwztDUneVilKyiLCPxnMFzYcDxUlK8XnXYXvPcmK/K1qYWlSyR4FCVotHUwp Jrvk4MAtmkG1L7aY6Z+2prr6eFcICpgrHoNPcVL+RxejettDwCO6fweDcltMrkqDqUOc Q4Vpc49vjAjZbXcuz+9ViLUjUlbrp2AIqih+iEeOVMDeHbGvZ1Fu9dRWQBhS+aEt02G2 xOeRWsz+KHwLQmqi17Hnch8LVh03BRdjLx9LA4qtOuSP0TNLuvNB2FeZiOWnNzUvV8UU zaJxF/Pmh8p1Y6QtQdXH0r7ApB3anft8z+oybXJdvR6jGpa0ZPew/3ozaQ+t83HId/88 AQ5w== MIME-Version: 1.0 Received: by 10.50.57.225 with SMTP id l1mr24277837igq.37.1356544562899; Wed, 26 Dec 2012 09:56:02 -0800 (PST) Received: by 10.64.143.138 with HTTP; Wed, 26 Dec 2012 09:56:02 -0800 (PST) In-Reply-To: <20121226174304.GA1397@faust.sbb.rs> References: <20121225151532.GA1404@faust.sbb.rs> <20121226170233.GA1408@faust.sbb.rs> <20121226174304.GA1397@faust.sbb.rs> Date: Wed, 26 Dec 2012 19:56:02 +0200 Message-ID: Subject: Re: 9.1 minimal ram requirements From: Kimmo Paasiala To: Zoran Kolic Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Dec 2012 18:03:44 -0000 On Wed, Dec 26, 2012 at 7:43 PM, Zoran Kolic wrote: >> 9.1-RC3 works just fine as well for some weeks :-) When your computers >> are not production machines I also recommend this to you Zoran to test >> RC in order to make RELEASE a better product. What you have now is >> labeled as RELEASE but it is a decoration. The "RELEASE" will be >> different from what you have found and installed (I think there are >> already versions with different tags available). This is really the >> thing that pushed me away from Linux :-( > > I removed the line and it booted just fine. > To me, 9.1 is probably the best looking release, but > it might be due to new hardware. > > I'n not aware what is going on, regarding release or > "release". At full speed I support the way devel team > does the work. And contrary, the team has to bear with > users, who want to know. I had new desktop and new > laptop waiting, since power surge killed some devices > at my home. And I waited for 3 months. None could say > I was impatient. The release image is on the site. And, > if you change RC3 to RELEASE in browser, there is even > more. Why would serious guys keep those files available, > if not for usage? > My best guess is that some packages compile made all > that fuss. What else might be? > Best regards > > Zoran You are correct, the hold up that has kept the release from being announced is the recent security incident that could have compromised the package build clusters. It looks like everything is all right after all. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 03:13:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2867BA9F for ; Thu, 27 Dec 2012 03:13:22 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp1.insight.synacor.com [208.47.185.23]) by mx1.freebsd.org (Postfix) with ESMTP id C477B8FC0A for ; Thu, 27 Dec 2012 03:13:21 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=AYoz7grG c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=BbwyZmbTN3oA:10 a=oJP1_OaXFiBdME-54XkA:9 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:46346] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 6A/35-25232-FCCBBD05; Wed, 26 Dec 2012 22:13:20 -0500 Date: Wed, 26 Dec 2012 22:13:19 -0500 Message-ID: <6A.35.25232.FCCBBD05@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Can't build kernel with ndis Cc: Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 03:13:22 -0000 I am trying to build FreeBSD update, STABLE branch, and buildkernel apparently snagged on ndis, which I don't want to do without. According to "man ndis", I need in kernel config options NDISAPI device ndis device wlan which I have: device wlan # 802.11 support options NDISAPI # This is in the hope of enabling Hiro USB wireless adapter device ndis Error message, final lines of buildkernel log file, are MAKE=make sh /usr/src/sys/conf/newvers.sh SANDY /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wred undant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wm issing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I /usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_gl obal.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param la rge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding - fstack-protector -Werror vers.c linking kernel.debug if_ndis.o: In function `ndis_detach': /usr/src/sys/dev/if_ndis/if_ndis.c:1084: undefined reference to `ndis_free_amem' if_ndis.o: In function `ndis_attach': /usr/src/sys/dev/if_ndis/if_ndis.c:563: undefined reference to `ndis_alloc_amem' *** [kernel.debug] Error code 1 Stop in /usr/obj/usr/src/sys/SANDY. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. Now Ian Lepore suggests adding to kernel config device pccard So I uncommented the device lines for cbb, pccard and cardbus even though my computer has no PCMCIA. I don't know why, this ought to be documented. So the kernel apparently built but would not install due to something related to auditdistd. UPDATING file refers to auditdistd(8) as if it were a man page, but I could find it nowhere, not even the FreeBSD online man pages. I ran mergemaster -p but didn't want to let it destroy my master.passwd, so I would up adding auditdistd user line with vi editor. But the kernel still wouldn't install. Now I am at an impasse. Maybe wait until 9.1 is really released? Tom From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 04:38:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38A78907 for ; Thu, 27 Dec 2012 04:38:57 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by mx1.freebsd.org (Postfix) with ESMTP id BCDC98FC08 for ; Thu, 27 Dec 2012 04:38:56 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id c10so3651046eaa.36 for ; Wed, 26 Dec 2012 20:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PJE0tT1BOmTvzD3HikGmunPYq1zN9L8FjO3NVuF93Hw=; b=akdt/BsX9Y9g+xoly2zHXxt7gkZ9cNWnfyX5XKQqcDDoAFcwnYrQxTdCZRaJ5lnYbE fLJ7ZW13+iLheK/T/yVKdqK+JaR9m3BqOOa+pGXrLFUHucVR3Blybg/55NN6Ch76PuGL CD2Ym1/86G3P1Wihnh7vyeixOaEbatmA7oivI2iNkq/fHDkH8iot73X5KhGlQx35n7kN f5QKNBIM8OJjjeKhzE0BFVYQZFGWXtqHtO/u2fxvAEgBvID1/axUHv7c41SMFds4T5rp mf9Wrb2G35ND74vE0RTZubwuauWZ6MsWCxci4VhVMtQshnW4w5g3IkxHihA7l6zeClvl JBqw== MIME-Version: 1.0 Received: by 10.14.2.196 with SMTP id 44mr74817753eef.25.1356583129740; Wed, 26 Dec 2012 20:38:49 -0800 (PST) Received: by 10.223.170.193 with HTTP; Wed, 26 Dec 2012 20:38:49 -0800 (PST) In-Reply-To: <6A.35.25232.FCCBBD05@smtp01.insight.synacor.com> References: <6A.35.25232.FCCBBD05@smtp01.insight.synacor.com> Date: Wed, 26 Dec 2012 20:38:49 -0800 Message-ID: Subject: Re: Can't build kernel with ndis From: Kevin Oberman To: Thomas Mueller Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 04:38:57 -0000 On Wed, Dec 26, 2012 at 7:13 PM, Thomas Mueller wrote: > I am trying to build FreeBSD update, STABLE branch, and buildkernel apparently snagged on ndis, which I don't want to do without. According to "man ndis", I need in kernel config > > options NDISAPI > device ndis > device wlan > > which I have: > > device wlan # 802.11 support > options NDISAPI # This is in the hope of enabling Hiro USB wireless adapter > device ndis > > Error message, final lines of buildkernel log file, are > > MAKE=make sh /usr/src/sys/conf/newvers.sh SANDY > /usr/local/bin/svnversion > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wred > undant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wm > issing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I > /usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_gl > obal.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param la > rge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding - > fstack-protector -Werror vers.c > linking kernel.debug > if_ndis.o: In function `ndis_detach': > /usr/src/sys/dev/if_ndis/if_ndis.c:1084: undefined reference to `ndis_free_amem' > if_ndis.o: In function `ndis_attach': > /usr/src/sys/dev/if_ndis/if_ndis.c:563: undefined reference to `ndis_alloc_amem' > *** [kernel.debug] Error code 1 > > Stop in /usr/obj/usr/src/sys/SANDY. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > > Now Ian Lepore suggests adding to kernel config > > device pccard > > So I uncommented the device lines for cbb, pccard and cardbus even though my computer has no PCMCIA. I don't know why, this ought to be documented. > > So the kernel apparently built but would not install due to something related to auditdistd. > > UPDATING file refers to auditdistd(8) as if it were a man page, but I could find it nowhere, not even the FreeBSD online man pages. > > I ran mergemaster -p but didn't want to let it destroy my master.passwd, so I would up adding auditdistd user line with vi editor. But the kernel still wouldn't install. Now I am at an impasse. Maybe wait until 9.1 is really released? If you want to insert the auditdistd user manually, that is fine, though I find doing it with mergemaster easier. (If you use it correctly ('m' option), it won't destroy your password file. But don't do it with vi. the actual pssword file is only a part of the process and the tool to properly edit it is vipw. Ir will edit /etc/passed, update master.passwd file, and, most importantly, update actual passworf databases. You can manually do this by running pwd_mkdb. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 09:45:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 562F9E43 for ; Thu, 27 Dec 2012 09:45:03 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 91DE18FC08 for ; Thu, 27 Dec 2012 09:45:02 +0000 (UTC) Received: (qmail 10723 invoked by uid 89); 27 Dec 2012 09:44:52 -0000 Received: by simscan 1.4.0 ppid: 10718, pid: 10720, t: 0.1513s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:16133 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 27 Dec 2012 09:44:52 -0000 Date: Thu, 27 Dec 2012 10:44:51 +0100 From: Rainer Duffner To: freebsd-stable@freebsd.org Subject: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1 Message-ID: <20121227104451.6fc6bfed@suse3> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 09:45:03 -0000 Hi, as I see it, pkgng is actually included in 9.1 as /usr/sbin/pkg, right? But when I define WITH_PKGNG=yes in /etc/make.conf the ports-system wants to install the pkgng-package (because it looks for pkgng in /usr/local/sbin). Is there a way to say "I have the pkg tool in base already"? Or is the pkg in base supposed to just install the pkgng from ports? Best Regards, Rainer From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 09:56:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 161F13B9; Thu, 27 Dec 2012 09:56:18 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from orac.jarasoft.net (orac.jarasoft.net [37.34.58.13]) by mx1.freebsd.org (Postfix) with ESMTP id BB2208FC08; Thu, 27 Dec 2012 09:56:17 +0000 (UTC) Received: from orac.jarasoft.net (orac.jarasoft.net [37.34.58.13]) by orac.jarasoft.net (Postfix) with ESMTP id D200E10A0B5; Thu, 27 Dec 2012 10:53:26 +0100 (CET) Received: from jarasc430 (raats.xs4all.nl [82.95.230.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by orac.jarasoft.net (Postfix) with ESMTPSA id 7D164109F67; Thu, 27 Dec 2012 10:53:26 +0100 (CET) Message-ID: <10CAB5BED66A49CBAF20A9DE02CAC3DD@jarasc430> From: "Jack Raats" To: , Subject: FreeBSD 9.1-PRERELEASE Date: Thu, 27 Dec 2012 10:53:23 +0100 Organization: Jack Raats, JaRaSoft, Steenbergen, Nederland MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 09:56:18 -0000 Hi, In this mailinglist I'm reading a lot about problems (re)compiling the = system. At this moment I'm running: "FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047: Sun Dec 9 15:33:19 CET 2012" = without problems. Is it save to recompile the system with all patches? Thanks Jack Raats From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 10:03:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E87D2604 for ; Thu, 27 Dec 2012 10:03:00 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 72F7A8FC16 for ; Thu, 27 Dec 2012 10:03:00 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.6/8.14.5) with ESMTP id qBRA2rGX082079 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Dec 2012 10:02:53 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.7.3 smtp.infracaninophile.co.uk qBRA2rGX082079 Authentication-Results: smtp.infracaninophile.co.uk/qBRA2rGX082079; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Message-ID: <50DC1CC5.30402@FreeBSD.org> Date: Thu, 27 Dec 2012 10:02:45 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Rainer Duffner Subject: Re: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1 References: <20121227104451.6fc6bfed@suse3> In-Reply-To: <20121227104451.6fc6bfed@suse3> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig31DD9BDE6FA63C15C7DD7385" X-Virus-Scanned: clamav-milter 0.97.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 10:03:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig31DD9BDE6FA63C15C7DD7385 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27/12/2012 09:44, Rainer Duffner wrote: > as I see it, pkgng is actually included in 9.1 as /usr/sbin/pkg, right?= /usr/sbin/pkg and /usr/local/sbin/pkg are very different. /usr/local/sbin/pkg is a binary package management system. /usr/sbin/pkg is a shim that can bootstrap the installation of /usr/local/sbin/pkg if it is not already installed, or that invokes /usr/local/sbin/pkg preserving the rest of the command line otherwise. > Is there a way to say "I have the pkg tool in base already"? pkgng is not in base and there are no plans to import it. If you are going to use pkgng then you need to install it, either from ports or by using the /usr/sbin/pkg shim to install from a pkgng package. > Or is the pkg in base supposed to just install the pkgng from ports? Indirectly. /usr/sbin/pkg installs from a pre-compiled tarball, which is generated from the ports-mgmt/pkg port. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig31DD9BDE6FA63C15C7DD7385 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDcHMwACgkQ8Mjk52CukIwhGACeJsw2ZAA0mpwjhGZpUOPOyd4F M3oAn1s3Ij5mXj2L87P39wTxP9QA8Snd =gW/a -----END PGP SIGNATURE----- --------------enig31DD9BDE6FA63C15C7DD7385-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 10:35:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77980E93 for ; Thu, 27 Dec 2012 10:35:22 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by mx1.freebsd.org (Postfix) with ESMTP id F31A58FC12 for ; Thu, 27 Dec 2012 10:35:21 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id ik5so4221569bkc.10 for ; Thu, 27 Dec 2012 02:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VQ9iFTpKHhLM+kJTtwsOMEGjD+UCxkooQrsQ84UfoaM=; b=Err8EBGVPBGdh6ZhCwbzJ/2wSOKRn7yZaRqsWXOWFeQ1acOLVzNFXusW5SuojN66n/ P+wiecRTiMC38Gysrvrgl6MiOX7gWbZjaWVAauPevdhP9pub5Dmm2n6diLGMTpWar6Fi qOGsUe9oAIbGqxTjcfsnNLaVOTQk97YaQMzY+kcHrTg+53HlpzxJz3bpSxAbYh8Avg6q hB4wa1ZBeoJbzw68Hu1jFJyMbHrkgtpO4CkqRU8Zs4gmSGMEReXiMCuuxdhOiKI8m08+ S6VuqJ/Hs1VBDAACnYm3LlzEgAOxVd1j6g4YdGedAMTN197DvwzvzlYGeZ5DXwk3UFKV 2I3A== X-Received: by 10.204.131.76 with SMTP id w12mr14244059bks.44.1356604515147; Thu, 27 Dec 2012 02:35:15 -0800 (PST) Received: from Melon.malikania.fr (110.89.123.78.rev.sfr.net. [78.123.89.110]) by mx.google.com with ESMTPS id i20sm20070563bkw.5.2012.12.27.02.35.13 (version=SSLv3 cipher=OTHER); Thu, 27 Dec 2012 02:35:14 -0800 (PST) Message-ID: <50DC245A.7020002@gmail.com> Date: Thu, 27 Dec 2012 11:35:06 +0100 From: David Demelier User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1 References: <20121227104451.6fc6bfed@suse3> <50DC1CC5.30402@FreeBSD.org> In-Reply-To: <50DC1CC5.30402@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 10:35:22 -0000 On 27/12/2012 11:02, Matthew Seaman wrote: > On 27/12/2012 09:44, Rainer Duffner wrote: >> as I see it, pkgng is actually included in 9.1 as /usr/sbin/pkg, right? > > /usr/sbin/pkg and /usr/local/sbin/pkg are very different. > > /usr/local/sbin/pkg is a binary package management system. > > /usr/sbin/pkg is a shim that can bootstrap the installation of > /usr/local/sbin/pkg if it is not already installed, or that invokes > /usr/local/sbin/pkg preserving the rest of the command line otherwise. > >> Is there a way to say "I have the pkg tool in base already"? > > pkgng is not in base and there are no plans to import it. If you are > going to use pkgng then you need to install it, either from ports or by > using the /usr/sbin/pkg shim to install from a pkgng package. > Why there is no plan to import it? >> Or is the pkg in base supposed to just install the pkgng from ports? > > Indirectly. /usr/sbin/pkg installs from a pre-compiled tarball, which > is generated from the ports-mgmt/pkg port. > > Cheers, > > Matthew > Cheers, David From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 10:38:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6951FB2 for ; Thu, 27 Dec 2012 10:38:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAD58FC08 for ; Thu, 27 Dec 2012 10:38:40 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:84c:b2ef:124a:7931] (unknown [IPv6:2001:7b8:3a7:0:84c:b2ef:124a:7931]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B6E545C5A; Thu, 27 Dec 2012 11:38:32 +0100 (CET) Message-ID: <50DC252C.205@FreeBSD.org> Date: Thu, 27 Dec 2012 11:38:36 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: David Demelier Subject: Re: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1 References: <20121227104451.6fc6bfed@suse3> <50DC1CC5.30402@FreeBSD.org> <50DC245A.7020002@gmail.com> In-Reply-To: <50DC245A.7020002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 10:38:41 -0000 On 2012-12-27 11:35, David Demelier wrote: > On 27/12/2012 11:02, Matthew Seaman wrote: ... >> pkgng is not in base and there are no plans to import it. If you are >> going to use pkgng then you need to install it, either from ports or by >> using the /usr/sbin/pkg shim to install from a pkgng package. > Why there is no plan to import it? Because pkgng is developed independently from the base system. As soon as you put a copy of it in base, it is no longer independent. :-) From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 11:17:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12CB47CF for ; Thu, 27 Dec 2012 11:17:23 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7328FC12 for ; Thu, 27 Dec 2012 11:17:22 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id d3so12079525lah.3 for ; Thu, 27 Dec 2012 03:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=f5AiJ6U2lhsnahSI8odN+l1JPE/94SbRF6I17/EKjWc=; b=XkcJ6SRkCXOByhiMCz5oajJNnMaTN8gbCfEfiTR8fYiFLM+ETN4z396MNhcC8HwzWy YowFt5+2xx/4IVnscEdiESq5ITAWxA0lcQoyQmxsRiQgj2UNn1ZXcLTAZkCxhkz7ngm1 mZuVgmW1invaas8LG8f16wgfA+3vfdknoFfzYzjJv+VUQsiyCS/nSL2Ml2LZltASR07C YnGB5xLuZ06ya7W31cCWFcCxfk96fLO3UmqYDxaQxTY++wWgXEn9jjyRCCpCP2fIEVlf VrodqSn4onpE4vd3fqp1IA8QsXWnr0BhQe8/fZti3OQIgXdlLGGPVQpqDegJcn1SiKmW KLYw== MIME-Version: 1.0 Received: by 10.152.105.103 with SMTP id gl7mr27773355lab.10.1356607041241; Thu, 27 Dec 2012 03:17:21 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.11.165 with HTTP; Thu, 27 Dec 2012 03:17:21 -0800 (PST) Date: Thu, 27 Dec 2012 12:17:21 +0100 X-Google-Sender-Auth: M28ipDyM2PAG9znFTBS2_ID3SVk Message-ID: Subject: 9.1-RC3: xorg-input-mouse, xfce4-panel From: CeDeROM To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 11:17:23 -0000 Hello :-) I have found some issues with 9.1-RC3 packages/configuration using binary packages: 1. xorg-input-mouse is old driver (?) that has the issue mentioned on the list (current?) - the mouse is not always detected at first xorg run. Please make sure 9.1-RELEASE use new mouse driver that has this issue fixed (?) and/or update default configuration to use AllowEmptyInput properly (Off). 2. I have some issues with xfce4-panel there seems to be more than one running, the panel is in configuration state at startup, sometimes a popup is displayed (about xfce4-panel) that stops the further running of the xfce4, when this popup is displayed on another monitor (in multi display configuration) this makes xfce4 startup delayed... This happens in default xfce4 configuration, when I remove all of the configuration, on a working configuration, etc. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 11:35:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 902DB9B0 for ; Thu, 27 Dec 2012 11:35:02 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 18FB48FC0C for ; Thu, 27 Dec 2012 11:35:01 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id F31F75C323 for ; Thu, 27 Dec 2012 12:28:55 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id MxD48e2NenD7 for ; Thu, 27 Dec 2012 12:28:54 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id B78465C31F for ; Thu, 27 Dec 2012 12:28:54 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id B19AD50851 for ; Thu, 27 Dec 2012 12:28:54 +0100 (CET) Message-ID: <50DC30F6.1050904@incore.de> Date: Thu, 27 Dec 2012 12:28:54 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 11:35:02 -0000 On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed the same behaviour as described for UFS+SU+J in lists.freebsd.org/pipermail/freebsd-current/2012-January/030937.html. The snapshot was initiated by amanda with dump 3ubLshf 64 1048576 0 - /dev/mirror/gm0p10.journal (pid 50347) and the process creating the snapshot is /sbin/mksnap_ffs /home /home/.snap/dump_snapshot (pid 50350). The process 50350 hangs and also all following processes that tried to access the home partition, some of them work, but don't come to an end, e.g. a shell after (Ctrl T): load: 0.61 cmd: sh 52670 [suspfs] 43.46r 0.00u 0.00s 0% 2272k. All write I/O's to all gjournaled partitions are stopped. Under normal circumstances the snapshot is taken in five seconds, so I have definitiv not the problem I have described in lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html. My system disk with root,var,usr and home is completely mirrored and gjournaled with journals in extra partitions: gpart show mirror/gm0 --> => 34 286749420 mirror/gm0 GPT (136G) 34 128 1 freebsd-boot (64k) 162 8601600 2 freebsd-swap (4.1G) 8601762 2097152 3 freebsd-swap (1.0G) 10698914 4194304 4 freebsd-swap (2.0G) 14893218 4194304 5 freebsd-swap (2.0G) 19087522 4194304 6 freebsd-swap (2.0G) 23281826 2097152 7 freebsd-ufs (1.0G) 25378978 8388608 8 freebsd-ufs (4.0G) 33767586 67108864 9 freebsd-ufs (32G) 100876450 185873004 10 freebsd-ufs (88G) df -h -t ufs --> Filesystem Size Used Avail Capacity Mounted on /dev/mirror/gm0p7.journal 989M 313M 596M 34% / /dev/mirror/gm0p8.journal 3.9G 2.2G 1.4G 61% /var /dev/mirror/gm0p9.journal 31G 8.6G 19G 30% /usr /dev/mirror/gm0p10.journal 85G 17G 62G 22% /home gmirror status --> Name Status Components mirror/gm0 COMPLETE da6 (ACTIVE) da7 (ACTIVE) gjournal status --> Name Status Components mirror/gm0p7.journal N/A mirror/gm0p3 mirror/gm0p7 mirror/gm0p8.journal N/A mirror/gm0p4 mirror/gm0p8 mirror/gm0p9.journal N/A mirror/gm0p5 mirror/gm0p9 mirror/gm0p10.journal N/A mirror/gm0p6 mirror/gm0p10 I got some information from the hanging system with DDB: KDB: enter: Break to debugger [thread pid 11 tid 100004 ] Stopped at kdb_enter+0x3b: movq $0,0x483332(%rip) db> show pcpu cpuid = 2 dynamic pcpu = 0xffffff807f7d0080 curthread = 0xffffff000235c000: pid 11 "idle: cpu2" curpcb = 0xffffff8000051d00 fpcurthread = none idlethread = 0xffffff000235c000: tid 100004 "idle: cpu2" curpmap = 0xffffffff80889170 tssp = 0xffffffff808f65d0 commontssp = 0xffffffff808f65d0 rsp0 = 0xffffff8000051d00 gs32p = 0xffffffff808f5408 ldt = 0xffffffff808f5448 tss = 0xffffffff808f5438 db> show allpcpu Current CPU: 2 cpuid = 0 dynamic pcpu = 0x449080 curthread = 0xffffff0002368470: pid 11 "idle: cpu0" curpcb = 0xffffff800005bd00 fpcurthread = none idlethread = 0xffffff0002368470: tid 100006 "idle: cpu0" curpmap = 0xffffffff80889170 tssp = 0xffffffff808f6500 commontssp = 0xffffffff808f6500 rsp0 = 0xffffff800005bd00 gs32p = 0xffffffff808f5338 ldt = 0xffffffff808f5378 tss = 0xffffffff808f5368 cpuid = 1 dynamic pcpu = 0xffffff807f7c9080 curthread = 0xffffff00023688e0: pid 11 "idle: cpu1" curpcb = 0xffffff8000056d00 fpcurthread = none idlethread = 0xffffff00023688e0: tid 100005 "idle: cpu1" curpmap = 0xffffffff80889170 tssp = 0xffffffff808f6568 commontssp = 0xffffffff808f6568 rsp0 = 0xffffff8000056d00 gs32p = 0xffffffff808f53a0 ldt = 0xffffffff808f53e0 tss = 0xffffffff808f53d0 cpuid = 2 dynamic pcpu = 0xffffff807f7d0080 curthread = 0xffffff000235c000: pid 11 "idle: cpu2" curpcb = 0xffffff8000051d00 fpcurthread = none idlethread = 0xffffff000235c000: tid 100004 "idle: cpu2" curpmap = 0xffffffff80889170 tssp = 0xffffffff808f65d0 commontssp = 0xffffffff808f65d0 rsp0 = 0xffffff8000051d00 gs32p = 0xffffffff808f5408 ldt = 0xffffffff808f5448 tss = 0xffffffff808f5438 cpuid = 3 dynamic pcpu = 0xffffff807f7d7080 curthread = 0xffffff000235c470: pid 11 "idle: cpu3" curpcb = 0xffffff800004cd00 fpcurthread = none idlethread = 0xffffff000235c470: tid 100003 "idle: cpu3" curpmap = 0xffffffff80889170 tssp = 0xffffffff808f6638 commontssp = 0xffffffff808f6638 rsp0 = 0xffffff800004cd00 gs32p = 0xffffffff808f5470 ldt = 0xffffffff808f54b0 tss = 0xffffffff808f54a0 db> trace Tracing pid 11 tid 100004 td 0xffffff000235c000 kdb_enter() at kdb_enter+0x3b kdb_alt_break_internal() at kdb_alt_break_internal+0x8a uart_intr() at uart_intr+0x2cd intr_event_handle() at intr_event_handle+0x62 intr_execute_handlers() at intr_execute_handlers+0x5f lapic_handle_intr() at lapic_handle_intr+0x37 Xapic_isr1() at Xapic_isr1+0xa5 --- interrupt, rip = 0xffffffff805ae2c6, rsp = 0xffffff8000051b10, rbp = 0xffffff8000051b20 --- acpi_cpu_c1() at acpi_cpu_c1+0x6 acpi_cpu_idle() at acpi_cpu_idle+0x20a sched_idletd() at sched_idletd+0x11f fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000051cf0, rbp = 0 --- db> show lock Giant class: sleep mutex name: Giant flags: {DEF, RECURSE} state: {UNOWNED} db> show lockedvnods Locked vnodes 0xffffff012a730588: tag ufs, type VREG usecount 1, writecount 0, refcount 2 mountedhere 0 flags (VV_SYSTEM) lock type snaplk: EXCL by thread 0xffffff00847cc000 (pid 50350) with exclusive waiters pending ino 23552, on dev mirror/gm0p10.journal db> show lockchain thread 100004 (pid 11, idle: cpu2) running on CPU 2 db> show sleepchain thread 100004 (pid 11, idle: cpu2) running on CPU 2 db> show thread Thread 100004 at 0xffffff000235c000: proc (pid 11): 0xffffff000235a470 name: idle: cpu2 stack: 0xffffff800004e000-0xffffff8000051fff flags: 0x50024 pflags: 0x200000 state: RUNNING (CPU 2) priority: 255 container lock: sched lock 2 (0xffffffff80894d80) db> show proc 50350 Process 50350 (mksnap_ffs) at 0xffffff00847b68e0: state: NORMAL uid: 0 gids: 5 parent: pid 50347 at 0xffffff00842d48e0 ABI: FreeBSD ELF64 arguments: /sbin/mksnap_ffs threads: 1 100215 D suspfs 0xffffff0002f2907c mksnap_ffs db> show threads 100111 (0xffffff0002d85000) (stack 0xffffff8245057000) sched_switch() at sched_switch+0xde 100166 (0xffffff0002f6b000) (stack 0xffffff824516a000) sched_switch() at sched_switch+0xde 100622 (0xffffff006a8d2000) (stack 0xffffff8245a52000) sched_switch() at sched_switch+0xde .... 100215 (0xffffff00847cc000) (stack 0xffffff824525f000) sched_switch() at sched_switch+0xde .... It seems there is a deadlock on the suspfs lock, but I could not figure out who holds this lock. Any hints how to get better diagnostic information for next time the error occurs are welcome. -- Andreas Longwitz From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 11:45:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F22DABA3 for ; Thu, 27 Dec 2012 11:45:19 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 7340B8FC08 for ; Thu, 27 Dec 2012 11:45:19 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.6/8.14.5) with ESMTP id qBRBjFJe083887 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Dec 2012 11:45:15 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.7.3 smtp.infracaninophile.co.uk qBRBjFJe083887 Authentication-Results: smtp.infracaninophile.co.uk/qBRBjFJe083887; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Message-ID: <50DC34C4.9080307@FreeBSD.org> Date: Thu, 27 Dec 2012 11:45:08 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1 References: <20121227104451.6fc6bfed@suse3> <50DC1CC5.30402@FreeBSD.org> <50DC245A.7020002@gmail.com> <50DC252C.205@FreeBSD.org> In-Reply-To: <50DC252C.205@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB3EF86E887AA713DE416D88" X-Virus-Scanned: clamav-milter 0.97.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 11:45:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB3EF86E887AA713DE416D88 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27/12/2012 10:38, Dimitry Andric wrote: > On 2012-12-27 11:35, David Demelier wrote: >> On 27/12/2012 11:02, Matthew Seaman wrote: >>> pkgng is not in base and there are no plans to import it. If you are= >>> going to use pkgng then you need to install it, either from ports or = by >>> using the /usr/sbin/pkg shim to install from a pkgng package. >> Why there is no plan to import it? > Because pkgng is developed independently from the base system. As soon= > as you put a copy of it in base, it is no longer independent. :-) Which somewhat begs the question as to why pkgng is developed independently of the base system. That is for entirely pragmatic reasons: there are rules about what you can change in the lifetime of a FreeBSD major or minor release. Which for a project of the scope of pkgng would basically mean taking many years to develop and adopt it. This is one of the sticking points that has effectively stymied development of pkg_tools over the years. By keeping pkgng out of the base we get: * Exactly the same version of pkgng for all current versions of FreeBSD -- which is important, as it means port maintainers can generally rely on solving problems one time for all versions. * The ability to develop pkgng at as rapid a pace as we can maintain. -- there is still a large amount of new functionality yet to be introduced, particularly the dependency solver, which will be quite revolutionary when it comes in. * Related to the above, we have been able to arbitrarily declare that the libpkg.so API will not be stabilized until pkg-2.0 is released. -- again, purely pragmatic and to enable as rapid development as possible. Despite this, we anticipate that there are changes to pkgng and pkgng-related changes to the ports which we won't be able to introduce until around April 2014 and the EoL of 8.3-RELEASE, which will be the las= t pre-pkgng release to go and hence the earliest date at which pkg_tools support can be entirely ceased. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigCB3EF86E887AA713DE416D88 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDcNMsACgkQ8Mjk52CukIxJbQCeO6kZ9q07k687w3AEGaiU2E7l tGgAnRC/iZ5EBf934RHkFaJF/xbB+Sfq =EII0 -----END PGP SIGNATURE----- --------------enigCB3EF86E887AA713DE416D88-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 13:27:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22FF7F71 for ; Thu, 27 Dec 2012 13:27:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id E27748FC14 for ; Thu, 27 Dec 2012 13:27:47 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qBRDRfLv010083; Thu, 27 Dec 2012 05:27:41 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qBRDRe2X010082; Thu, 27 Dec 2012 05:27:40 -0800 (PST) (envelope-from david) Date: Thu, 27 Dec 2012 05:27:40 -0800 From: David Wolfskill To: Jack Raats Subject: Re: FreeBSD 9.1-PRERELEASE Message-ID: <20121227132740.GM2019@albert.catwhisker.org> References: <10CAB5BED66A49CBAF20A9DE02CAC3DD@jarasc430> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iUV/lbBrmPtUT9dM" Content-Disposition: inline In-Reply-To: <10CAB5BED66A49CBAF20A9DE02CAC3DD@jarasc430> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 13:27:48 -0000 --iUV/lbBrmPtUT9dM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [-questions@, as I'm not subscribed to it, and I don't see value in cross-posting this message -- dhw] On Thu, Dec 27, 2012 at 10:53:23AM +0100, Jack Raats wrote: > Hi, >=20 > In this mailinglist I'm reading a lot about problems (re)compiling the sy= stem. Well, I suspect that even if a small number of those of us who rebuild the system without problems were to post each time we did so, there would be a fair number of complaints from all of the noise. :-} > At this moment I'm running: > "FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047: Sun Dec 9 15:33:19 CET 2012" = without problems. Good. > Is it save to recompile the system with all patches? > ... OK; now I'm a bit confused. The version string you cite ("FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047") indicates that you have no modifications to the source tree -- so I'm unclear on what "patches" you are referencing. I have been tracking the stable/9 branch of FreeBSD (updating & rebuilding daily) on my laptop, then using it for my day-to-day activities. I have had very few problems with stable/9 -- I think there may have been as many as 3 times that I had trouble rebuilding since May. For reference, the most recent "uname -a" outputs for me are: FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #329 r= 244676M/244676: Tue Dec 25 05:04:52 PST 2012 root@g1-227.catwhisker.org= :/usr/obj/usr/src/sys/CANARY i386 FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #330 r= 244712M/244731: Thu Dec 27 04:24:05 PST 2012 root@g1-227.catwhisker.org= :/usr/obj/usr/src/sys/CANARY i386 (Note that while I did rebuild yesterday (Wed 26 Dec), the uname output was unchanged, as the only changes in the sources was to "userland" (vs. the kernel).) Finally, note that stable/9 is a *development* branch of FreeBSD; as such, it gets updated often; the "safety" of rebuilding is difficult to estimate absent knowledge of both your environment and the point to which you are considering updating. The developers try to avoid breaking things (and that avoidance is much eaasier with SVN, vs. CVS (IMO)), but software development is fundamentally a human activity, and mistakes do happen from time to time. If that's a concern, I suggest that you try such an update on a system that is less critical than most, but which you are able to subject to significant testing. If that works for you, you might consider upgrading somewhat more-critical systems to the same point. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --iUV/lbBrmPtUT9dM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDcTMsACgkQmprOCmdXAD0ULgCdGVHfJ6+pQ6Vlm7hKhYMr9vr8 3+IAni/uFvHy8mIw6UXH8+XAs/ttFQIX =ZPA2 -----END PGP SIGNATURE----- --iUV/lbBrmPtUT9dM-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 13:34:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2EE21E7 for ; Thu, 27 Dec 2012 13:34:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 214A08FC0A for ; Thu, 27 Dec 2012 13:34:00 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBRDXthA005118; Thu, 27 Dec 2012 15:33:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBRDXthA005118 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBRDXt8K005117; Thu, 27 Dec 2012 15:33:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Dec 2012 15:33:55 +0200 From: Konstantin Belousov To: Andreas Longwitz Subject: Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup Message-ID: <20121227133355.GI82219@kib.kiev.ua> References: <50DC30F6.1050904@incore.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Op27XXJsWz80g3oF" Content-Disposition: inline In-Reply-To: <50DC30F6.1050904@incore.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 13:34:01 -0000 --Op27XXJsWz80g3oF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote: > On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed the > same behaviour as described for UFS+SU+J in > lists.freebsd.org/pipermail/freebsd-current/2012-January/030937.html. >=20 > The snapshot was initiated by amanda with > dump 3ubLshf 64 1048576 0 - /dev/mirror/gm0p10.journal (pid 50347) > and the process creating the snapshot is > /sbin/mksnap_ffs /home /home/.snap/dump_snapshot (pid 50350). >=20 > The process 50350 hangs and also all following processes that tried to > access the home partition, some of them work, but don't come to an end, > e.g. a shell after (Ctrl T): > load: 0.61 cmd: sh 52670 [suspfs] 43.46r 0.00u 0.00s 0% 2272k. >=20 > All write I/O's to all gjournaled partitions are stopped. Under normal > circumstances the snapshot is taken in five seconds, so I have definitiv > not the problem I have described in > lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html. >=20 > My system disk with root,var,usr and home is completely mirrored and > gjournaled with journals in extra partitions: > gpart show mirror/gm0 --> > =3D> 34 286749420 mirror/gm0 GPT (136G) > 34 128 1 freebsd-boot (64k) > 162 8601600 2 freebsd-swap (4.1G) > 8601762 2097152 3 freebsd-swap (1.0G) > 10698914 4194304 4 freebsd-swap (2.0G) > 14893218 4194304 5 freebsd-swap (2.0G) > 19087522 4194304 6 freebsd-swap (2.0G) > 23281826 2097152 7 freebsd-ufs (1.0G) > 25378978 8388608 8 freebsd-ufs (4.0G) > 33767586 67108864 9 freebsd-ufs (32G) > 100876450 185873004 10 freebsd-ufs (88G) > df -h -t ufs --> > Filesystem Size Used Avail Capacity Mounted on > /dev/mirror/gm0p7.journal 989M 313M 596M 34% / > /dev/mirror/gm0p8.journal 3.9G 2.2G 1.4G 61% /var > /dev/mirror/gm0p9.journal 31G 8.6G 19G 30% /usr > /dev/mirror/gm0p10.journal 85G 17G 62G 22% /home > gmirror status --> > Name Status Components > mirror/gm0 COMPLETE da6 (ACTIVE) > da7 (ACTIVE) > gjournal status --> > Name Status Components > mirror/gm0p7.journal N/A mirror/gm0p3 > mirror/gm0p7 > mirror/gm0p8.journal N/A mirror/gm0p4 > mirror/gm0p8 > mirror/gm0p9.journal N/A mirror/gm0p5 > mirror/gm0p9 > mirror/gm0p10.journal N/A mirror/gm0p6 > mirror/gm0p10 >=20 > I got some information from the hanging system with DDB: > KDB: enter: Break to debugger > [thread pid 11 tid 100004 ] > Stopped at kdb_enter+0x3b: movq $0,0x483332(%rip) > db> show pcpu > cpuid =3D 2 > dynamic pcpu =3D 0xffffff807f7d0080 > curthread =3D 0xffffff000235c000: pid 11 "idle: cpu2" > curpcb =3D 0xffffff8000051d00 > fpcurthread =3D none > idlethread =3D 0xffffff000235c000: tid 100004 "idle: cpu2" > curpmap =3D 0xffffffff80889170 > tssp =3D 0xffffffff808f65d0 > commontssp =3D 0xffffffff808f65d0 > rsp0 =3D 0xffffff8000051d00 > gs32p =3D 0xffffffff808f5408 > ldt =3D 0xffffffff808f5448 > tss =3D 0xffffffff808f5438 > db> show allpcpu > Current CPU: 2 >=20 > cpuid =3D 0 > dynamic pcpu =3D 0x449080 > curthread =3D 0xffffff0002368470: pid 11 "idle: cpu0" > curpcb =3D 0xffffff800005bd00 > fpcurthread =3D none > idlethread =3D 0xffffff0002368470: tid 100006 "idle: cpu0" > curpmap =3D 0xffffffff80889170 > tssp =3D 0xffffffff808f6500 > commontssp =3D 0xffffffff808f6500 > rsp0 =3D 0xffffff800005bd00 > gs32p =3D 0xffffffff808f5338 > ldt =3D 0xffffffff808f5378 > tss =3D 0xffffffff808f5368 >=20 > cpuid =3D 1 > dynamic pcpu =3D 0xffffff807f7c9080 > curthread =3D 0xffffff00023688e0: pid 11 "idle: cpu1" > curpcb =3D 0xffffff8000056d00 > fpcurthread =3D none > idlethread =3D 0xffffff00023688e0: tid 100005 "idle: cpu1" > curpmap =3D 0xffffffff80889170 > tssp =3D 0xffffffff808f6568 > commontssp =3D 0xffffffff808f6568 > rsp0 =3D 0xffffff8000056d00 > gs32p =3D 0xffffffff808f53a0 > ldt =3D 0xffffffff808f53e0 > tss =3D 0xffffffff808f53d0 >=20 > cpuid =3D 2 > dynamic pcpu =3D 0xffffff807f7d0080 > curthread =3D 0xffffff000235c000: pid 11 "idle: cpu2" > curpcb =3D 0xffffff8000051d00 > fpcurthread =3D none > idlethread =3D 0xffffff000235c000: tid 100004 "idle: cpu2" > curpmap =3D 0xffffffff80889170 > tssp =3D 0xffffffff808f65d0 > commontssp =3D 0xffffffff808f65d0 > rsp0 =3D 0xffffff8000051d00 > gs32p =3D 0xffffffff808f5408 > ldt =3D 0xffffffff808f5448 > tss =3D 0xffffffff808f5438 >=20 > cpuid =3D 3 > dynamic pcpu =3D 0xffffff807f7d7080 > curthread =3D 0xffffff000235c470: pid 11 "idle: cpu3" > curpcb =3D 0xffffff800004cd00 > fpcurthread =3D none > idlethread =3D 0xffffff000235c470: tid 100003 "idle: cpu3" > curpmap =3D 0xffffffff80889170 > tssp =3D 0xffffffff808f6638 > commontssp =3D 0xffffffff808f6638 > rsp0 =3D 0xffffff800004cd00 > gs32p =3D 0xffffffff808f5470 > ldt =3D 0xffffffff808f54b0 > tss =3D 0xffffffff808f54a0 >=20 > db> trace > Tracing pid 11 tid 100004 td 0xffffff000235c000 > kdb_enter() at kdb_enter+0x3b > kdb_alt_break_internal() at kdb_alt_break_internal+0x8a > uart_intr() at uart_intr+0x2cd > intr_event_handle() at intr_event_handle+0x62 > intr_execute_handlers() at intr_execute_handlers+0x5f > lapic_handle_intr() at lapic_handle_intr+0x37 > Xapic_isr1() at Xapic_isr1+0xa5 > --- interrupt, rip =3D 0xffffffff805ae2c6, rsp =3D 0xffffff8000051b10, rb= p =3D > 0xffffff8000051b20 --- > acpi_cpu_c1() at acpi_cpu_c1+0x6 > acpi_cpu_idle() at acpi_cpu_idle+0x20a > sched_idletd() at sched_idletd+0x11f > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff8000051cf0, rbp =3D 0 --- >=20 > db> show lock Giant > class: sleep mutex > name: Giant > flags: {DEF, RECURSE} > state: {UNOWNED} >=20 > db> show lockedvnods > Locked vnodes >=20 > 0xffffff012a730588: tag ufs, type VREG > usecount 1, writecount 0, refcount 2 mountedhere 0 > flags (VV_SYSTEM) > lock type snaplk: EXCL by thread 0xffffff00847cc000 (pid 50350) > with exclusive waiters pending > ino 23552, on dev mirror/gm0p10.journal >=20 > db> show lockchain > thread 100004 (pid 11, idle: cpu2) running on CPU 2 >=20 > db> show sleepchain > thread 100004 (pid 11, idle: cpu2) running on CPU 2 >=20 > db> show thread > Thread 100004 at 0xffffff000235c000: > proc (pid 11): 0xffffff000235a470 > name: idle: cpu2 > stack: 0xffffff800004e000-0xffffff8000051fff > flags: 0x50024 pflags: 0x200000 > state: RUNNING (CPU 2) > priority: 255 > container lock: sched lock 2 (0xffffffff80894d80) >=20 > db> show proc 50350 > Process 50350 (mksnap_ffs) at 0xffffff00847b68e0: > state: NORMAL > uid: 0 gids: 5 > parent: pid 50347 at 0xffffff00842d48e0 > ABI: FreeBSD ELF64 > arguments: /sbin/mksnap_ffs > threads: 1 > 100215 D suspfs 0xffffff0002f2907c mksnap_ffs >=20 > db> show threads > 100111 (0xffffff0002d85000) (stack 0xffffff8245057000) sched_switch() > at sched_switch+0xde > 100166 (0xffffff0002f6b000) (stack 0xffffff824516a000) sched_switch() > at sched_switch+0xde > 100622 (0xffffff006a8d2000) (stack 0xffffff8245a52000) sched_switch() > at sched_switch+0xde > .... > 100215 (0xffffff00847cc000) (stack 0xffffff824525f000) sched_switch() > at sched_switch+0xde > .... >=20 > It seems there is a deadlock on the suspfs lock, but I could not figure > out who holds this lock. > Any hints how to get better diagnostic information for next time the > error occurs are welcome. The http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html provides the instructions. The suspfs is owned by the snapshot creator. The question is, where is it blocked. --Op27XXJsWz80g3oF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ3E5BAAoJEJDCuSvBvK1BkYYP/1jFnmAbMv+p7NYqZJD8jH+b To1OFkKq5+Q1L0n2NVW5bkrQukHnwrygriuaPtxzZuvUKo5QrD467CKPh1V/2YUv PbvOukRD0uI3/pgJzfr8c5loNpw/+2UqoGCYGGYOBQ1sSvvOcUxviG9NVs+JhFv5 /LUSLrq7k7b/AIpw2EyTJKeuViWVfTr2D0uTNgXA8Kol4Anwm9cwqSXRYRiNsiTl NZv8/DWPV2FmCf3tszHdQawhULEUsmwZEt528F5ERiIwrkBm3sanqYgAqAYE1OlP cLsuLXVwKfYPxqZs6hIeFH5pnFezQejKvQy8t28zsK27LPaJoBNGGNyen5uP+i07 UM+hbw9fHYagL4k2zqGAeLA9stsVJHTd/Od5j8PpD7YUsYapuddpyw+RyfHjkMMR liiZdtZsbDT546DAsQgMJVpOdjaMHs3wuTwiaoaMIELY22oivj8MRsticyVmVBZn xN5SidM4RQ0WAOahvmtk67fdG9TwZ/+czPC+fV8VA7bcyozt//0E/ZNRvn3N+Vlj AxquS1KlPb4h7IdJHflyiat+PCQR7jpUSQFTeW6zlZqH7lzK5eSwWkDaTiANKwMU obZMDlvM779Cqi6i9Bq9bPZHQ4jMYFX8rUEtMksJQ+X824fbkCyartOBoq6REckw 3DdEX+PYiJradlr7yfbs =lYy0 -----END PGP SIGNATURE----- --Op27XXJsWz80g3oF-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 13:34:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D8AF2E7; Thu, 27 Dec 2012 13:34:27 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mx1.freebsd.org (Postfix) with ESMTP id B9F1A8FC0A; Thu, 27 Dec 2012 13:34:26 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm2so5356478wib.4 for ; Thu, 27 Dec 2012 05:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y9PTL3VHwExZsPnT0jPW+QSVQBMSF5ZwSzAD1thAFng=; b=UQsXXN6a5KjPGQ8p/4rqW9CgCQzB10oWb/JpUv4Niky/fvIWUpPAQL9xpfZXf+Dv6M LGh2P7K6G7Tjpn24OiDIlx/1VlnoM1zTbHXV52km6X8eDmc3cOGS2K/V7y1p7iQbd5LC 5DJNCwbMVhKvXEhSbZmNlO/qKmniVrhQEtbS4hY3tvvqzqvRU6JCSfbm2NA/0ExrCcKp XxQUAYOAXp9d0wNs0eRP3eng8OpS4RvhSgCjbpkmQZ3P+BKEs0uUHXB4GHOvXWohA1dk khlgIlNPQQijeuHE2czSnReGLQ74xEdGWVk7ps5YvA+R1ddnPGDlscvid3cAS0SYp9rq ocFQ== MIME-Version: 1.0 Received: by 10.194.21.70 with SMTP id t6mr48871511wje.42.1356615260283; Thu, 27 Dec 2012 05:34:20 -0800 (PST) Received: by 10.216.172.197 with HTTP; Thu, 27 Dec 2012 05:34:20 -0800 (PST) In-Reply-To: <10CAB5BED66A49CBAF20A9DE02CAC3DD@jarasc430> References: <10CAB5BED66A49CBAF20A9DE02CAC3DD@jarasc430> Date: Thu, 27 Dec 2012 15:34:20 +0200 Message-ID: Subject: Re: FreeBSD 9.1-PRERELEASE From: Kimmo Paasiala To: Jack Raats Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 13:34:27 -0000 On Thu, Dec 27, 2012 at 11:53 AM, Jack Raats wrote: > Hi, > > In this mailinglist I'm reading a lot about problems (re)compiling the system. At this moment I'm running: > "FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047: Sun Dec 9 15:33:19 CET 2012" without problems. > > Is it save to recompile the system with all patches? > > Thanks > Jack Raats > _______________________________________________ You're seeing just the "tip of the iceberg" meaning only those who do have problems building the OS from sources and are following the mailing lists post on them. There's potentially thousands or even much more of those who are following 9-STABLE and never encounter a problem they can not solve on their own. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 15:00:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2615AD40 for ; Thu, 27 Dec 2012 15:00:18 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id D1C378FC08 for ; Thu, 27 Dec 2012 15:00:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qBRF0HZb066408; Thu, 27 Dec 2012 08:00:17 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qBRF0HJw066405; Thu, 27 Dec 2012 08:00:17 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 27 Dec 2012 08:00:17 -0700 (MST) From: Warren Block To: CeDeROM Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 27 Dec 2012 08:00:17 -0700 (MST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 15:00:18 -0000 On Thu, 27 Dec 2012, CeDeROM wrote: > Hello :-) > > I have found some issues with 9.1-RC3 packages/configuration using > binary packages: > > 1. xorg-input-mouse is old driver (?) that has the issue mentioned on > the list (current?) - the mouse is not always detected at first xorg > run. Please make sure 9.1-RELEASE use new mouse driver that has this > issue fixed (?) and/or update default configuration to use > AllowEmptyInput properly (Off). Use AutoAddDevices Off instead. AEI is prone to problems. http://www.wonkity.com/~wblock/docs/html/aei.html From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 15:09:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C207F90 for ; Thu, 27 Dec 2012 15:09:03 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nskntmtas05p.mx.bigpond.com (nskntmtas05p.mx.bigpond.com [61.9.168.149]) by mx1.freebsd.org (Postfix) with ESMTP id B630D8FC0A for ; Thu, 27 Dec 2012 15:09:02 +0000 (UTC) Received: from nskntcmgw06p ([61.9.169.166]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20121227150901.GTLG24726.nskntmtas05p.mx.bigpond.com@nskntcmgw06p> for ; Thu, 27 Dec 2012 15:09:01 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nskntcmgw06p with BigPond Outbound id gf901k00J5LKYmq01f908t; Thu, 27 Dec 2012 15:09:01 +0000 X-Authority-Analysis: v=2.0 cv=FNSZNpUs c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=k4yzAXmc-yEA:10 a=kj9zAlcOel0A:10 a=GHIR_BbyAAAA:8 a=TAcuXy0nRCgA:10 a=6I5d2MoRAAAA:8 a=CYnwQQe7J6bBVM6tXFYA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from black (black.hs [10.0.5.1]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id qBRF5SgU051399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Dec 2012 02:05:29 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Konstantin Belousov'" References: <20121208010109.GH3013@kib.kiev.ua> Subject: RE: nullfs changes MFC Date: Fri, 28 Dec 2012 02:05:28 +1100 Message-ID: <5489CBA00ADE464EA61432CBBEB58964@black> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20121208010109.GH3013@kib.kiev.ua> Thread-Index: Ac3U35ZqBdYeNThKTl2mGzBL3W/wegNimc0g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 15:09:03 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of > Konstantin Belousov > Sent: Saturday, 8 December 2012 12:01 PM > To: fs@freebsd.org > Cc: stable@freebsd.org > Subject: nullfs changes MFC > > Hi, > I am going to merge latest batch of the nullfs improvements > into stable/9. This will bring up significant performance > enchancements due to use of the shared locks for lookups if > the lower layer supports it, much better caching on the > nullfs layer, and proper handling of the text segments on the > nullfs. Also, it should improve the error recovery and some > corner cases with locking. > > Unfortunately, the merge would break KBI for VFS, since it > needs 5 new VOP slots, and only three spares are left. We > already are very liberal with the VFS KBI, so I do not feel > that the merge is not acceptable, due to the benefits it > brings to the nullfs. > > The merge is available at > http://people.freebsd.org/~kib/misc/nullfs_9.1.patch > Konstantin, Thank-you for these improvements. I've been running this patchset on test and build servers for a few weeks and the systems remained stable and reliable. On some fairly complex jail and nullfs environments there has been an improvement in the order of 3 to 8% for large sequential writes. Regards, Dewayne PS I've reversed out the patches now they've migrated to RELENG_9 From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 15:10:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CF9F21B for ; Thu, 27 Dec 2012 15:10:02 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBE48FC13 for ; Thu, 27 Dec 2012 15:10:01 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id e4so12460903lag.38 for ; Thu, 27 Dec 2012 07:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=a7T937Gq7VINmSa4WAC/+KQPVYEBt7ifvzJIU1fIkbI=; b=IrQAYkS80elHMzfakrNWfPRqoWmVCxuS0hBcONOOqJDr0dyVrMLAReMjoBNFacZEts kHUqKA1DZZXedzCiQl6bGx1q61tLADjdzRiRKFF0mbOillfyRwvHGkNL+oaGA+HQJzq1 gSgueU1Leaq8UVw1/Bze/szXy8Pk0/L/qC8mp2Jdied5ckOuuUzFoSlWNooFPiVLsZEZ pKKr8vIqiem/iL49UQptjNYhVrWG+HpikEkeIoYHz5ywNCTks4Q5Krr41MP0fSLdb67r OypROeBhH6Z7j0ST+sp8vZPqCMqyV67A2dJKbo8DN2UPBSNZ9QSwg76u2pei69kJngsa 0lhQ== MIME-Version: 1.0 Received: by 10.112.87.40 with SMTP id u8mr12269437lbz.50.1356620993442; Thu, 27 Dec 2012 07:09:53 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.11.165 with HTTP; Thu, 27 Dec 2012 07:09:53 -0800 (PST) In-Reply-To: References: Date: Thu, 27 Dec 2012 16:09:53 +0100 X-Google-Sender-Auth: YCQYSbxFTs2_X2Mmk-VAsOOmj7U Message-ID: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel From: CeDeROM To: Warren Block Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 15:10:02 -0000 Hello Warren :-) I did so. I also talked about that problem some time ago. I think 1.7.2 xorg mouse driver has this fix and no manual configuration is necessary. It would be nice to include 1.7.2 in the release packages :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 16:22:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD9627D8 for ; Thu, 27 Dec 2012 16:22:59 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 054388FC12 for ; Thu, 27 Dec 2012 16:22:58 +0000 (UTC) Received: (qmail 19292 invoked by uid 89); 27 Dec 2012 16:22:57 -0000 Received: by simscan 1.4.0 ppid: 19287, pid: 19289, t: 0.1287s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:16139 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 27 Dec 2012 16:22:57 -0000 Date: Thu, 27 Dec 2012 17:22:56 +0100 From: Rainer Duffner To: freebsd-stable@freebsd.org Subject: Anothe pkgng question: signing a repository Message-ID: <20121227172256.647c6728@suse3> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 16:22:59 -0000 Hi, I'm creating my own repository and have created a key for it. I've created a CSR for it and used that to generate a certificate via our internal CA. Because there was no other information available, I used the profile that we use to generate SSL-certificates for web servers. I copied the certificate to the server and adjusted pkg.conf, but when I want to query the repository, I get: root@server:/etc/ssl/cert # pkg install net-snmpd Updating repository catalogue repo.txz 100% 219KB 219.5KB/s 219.5KB/s 00:00 pkg: error reading public key(/etc/ssl/pkg.conf): error:0906D06C:PEM routines:PEM_read_bio:no start line pkg: Invalid signature, removing repository. What does pkg expect to be in this file? openssl x509 displays the data for the certificate correctly, so I really don't know what's missing. I ktraced pkg and it is indeed reading the file. Best Regards Rainer From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 17:07:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E30B0485 for ; Thu, 27 Dec 2012 17:07:54 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id BC0D88FC12 for ; Thu, 27 Dec 2012 17:07:53 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1ToGvq-0007yI-Q0 for freebsd-stable@freebsd.org; Thu, 27 Dec 2012 09:07:46 -0800 Date: Thu, 27 Dec 2012 09:07:46 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1356628066796-5772624.post@n5.nabble.com> In-Reply-To: References: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 17:07:54 -0000 There is nothing going into "release" what was not in ports tree. (There is no release packages at all, apart from ports that's just happened to be in regular tree at release time. Followed by port tree slush.) xf86-input-mouse-1.8.1 is in dev trunk xorg tree. (see -x11). -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RC3-xorg-input-mouse-xfce4-panel-tp5772549p5772624.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 17:13:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6E356C1 for ; Thu, 27 Dec 2012 17:13:22 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id AFF658FC08 for ; Thu, 27 Dec 2012 17:13:22 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1ToH1F-0008K4-Uh for freebsd-stable@freebsd.org; Thu, 27 Dec 2012 09:13:21 -0800 Date: Thu, 27 Dec 2012 09:13:21 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1356628401942-5772627.post@n5.nabble.com> In-Reply-To: References: <10CAB5BED66A49CBAF20A9DE02CAC3DD@jarasc430> Subject: Re: FreeBSD 9.1-PRERELEASE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 17:13:22 -0000 Is ORAC some kind of patchset? Unless you see flow of tinderbox errors, -STABLE is buildable almost always. -- View this message in context: http://freebsd.1045724.n5.nabble.com/FreeBSD-9-1-PRERELEASE-tp5772515p5772627.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 17:47:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8B0411B for ; Thu, 27 Dec 2012 17:47:08 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 4ADC88FC08 for ; Thu, 27 Dec 2012 17:47:08 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 5ED075C346; Thu, 27 Dec 2012 18:47:07 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id 3UNQndxsVKYv; Thu, 27 Dec 2012 18:47:05 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id ABBDF5C342; Thu, 27 Dec 2012 18:47:05 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id A057B50851; Thu, 27 Dec 2012 18:47:05 +0100 (CET) Message-ID: <50DC8999.8000708@incore.de> Date: Thu, 27 Dec 2012 18:47:05 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup References: <50DC30F6.1050904@incore.de> <20121227133355.GI82219@kib.kiev.ua> In-Reply-To: <20121227133355.GI82219@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 17:47:08 -0000 Konstantin Belousov wrote: > On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote: >> On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed the >> same behaviour as described for UFS+SU+J in >> lists.freebsd.org/pipermail/freebsd-current/2012-January/030937.html. >> >> The snapshot was initiated by amanda with >> dump 3ubLshf 64 1048576 0 - /dev/mirror/gm0p10.journal (pid 50347) >> and the process creating the snapshot is >> /sbin/mksnap_ffs /home /home/.snap/dump_snapshot (pid 50350). >> >> The process 50350 hangs and also all following processes that tried to >> access the home partition, some of them work, but don't come to an end, >> e.g. a shell after (Ctrl T): >> load: 0.61 cmd: sh 52670 [suspfs] 43.46r 0.00u 0.00s 0% 2272k. >> >> All write I/O's to all gjournaled partitions are stopped. Under normal >> circumstances the snapshot is taken in five seconds, so I have definitiv >> not the problem I have described in >> lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html. >> >> ..... >> >> It seems there is a deadlock on the suspfs lock, but I could not figure >> out who holds this lock. >> Any hints how to get better diagnostic information for next time the >> error occurs are welcome. > > The > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > provides the instructions. > > The suspfs is owned by the snapshot creator. The question is, where is it > blocked. Thanks for answer. In the meantime I can reproduce the problem and got some more information. It looks that there is a deadlock between the two processes with pid 18 (g_journal switcher) and pid 7126 (/sbin/mksnap_ffs /home /home/.snap/my_snapshot): 0 18 0 0 45 0 0 16 snaplk DL ?? 4:40,34 [g_journal switcher] 0 7126 1933 0 50 0 5836 1176 suspfs D ?? 0:00,44 /sbin/mksnap_ffs /home /home/.snap/my_snapshot procstat -t 18 --> PID TID COMM TDNAME CPU PRI STATE WCHAN 18 100076 g_journal switcher g_journal switch 0 129 sleep snaplk procstat -t 7126 --> PID TID COMM TDNAME CPU PRI STATE WCHAN 7126 100157 mksnap_ffs - 1 134 sleep suspfs procstat -kk 18 --> PID TID COMM TDNAME KSTACK 18 100076 g_journal switcher g_journal switch mi_switch+0x186 sleepq_wait+0x42 __lockmgr_args+0x49b ffs_copyonwrite +0x19a ffs_geom_strategy+0x1b5 bufwrite+0xe9 ffs_sbupdate+0x12a g_journal_ufs_clean+0x3e g_journal_switcher+0xe5e fork _exit+0x11f fork_trampoline+0xe procstat -kk 7126 --> PID TID COMM TDNAME KSTACK 7126 100157 mksnap_ffs - mi_switch+0x186 sleepq_wait+0x42 _sleep+0x373 vn_start_write+0xdf ffs_s napshot+0xe2b ffs_mount+0x65a vfs_donmount+0xdc5 nmount+0x63 amd64_syscall+0x1f4 Xfast_syscall+0xfc >From DDB: db> show lockedvnods Locked vnodes 0xffffff012281a938: tag ufs, type VREG usecount 1, writecount 0, refcount 3339 mountedhere 0 flags (VV_SYSTEM) lock type snaplk: EXCL by thread 0xffffff000807a470 (pid 7126) with exclusive waiters pending ino 23552, on dev mirror/gm0p10.journal db> show lockedbufs buf at 0xffffff81efa73320 b_flags = 0xa0000020 b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0 b_bufobj = (0xffffff00080564c8), b_data = 0xffffff81f659e000, b_blkno = 12000, b_dep = 0 b_npages = 2, pages(OBJ, IDX, PA): (0xffffff000805c000, 0x5dc, 0x4a78000),(0xffffff000805c000, 0x5dd, 0x4a79000) lock type bufwait: EXCL by thread 0xffffff0002bd5000 (pid 18) buf at 0xffffff81f0485070 b_flags = 0x80000020 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xffffff012281aa50), b_data = 0xffffff8207896000, b_blkno = 462144, b_dep = 0 b_npages = 4, pages(OBJ, IDX, PA): (0, 0xffffff8207896, 0x118bd9000),(0, 0xffffff8207897, 0x118bda000),(0, 0xffffff820 7898, 0x118bdb000),(0, 0xffffff8207899, 0x118bdc000) lock type bufwait: EXCL by thread 0xffffff000807a470 (pid 7126) buf at 0xffffff81f0df9f98 b_flags = 0xa0000020 b_error = 0, b_bufsize = 2048, b_bcount = 2048, b_resid = 0 b_bufobj = (0xffffff00080564c8), b_data = 0xffffff8217ad2000, b_blkno = 128, b_dep = 0 b_npages = 1, pages(OBJ, IDX, PA): (0xffffff000805c000, 0x10, 0x4a7a000) lock type bufwait: EXCL by thread 0xffffff0002bd5000 (pid 18) db> alltrace (pid 18 and 7126) Tracing command g_journal switcher pid 18 tid 100076 td 0xffffff0002bd5000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x42 __lockmgr_args() at __lockmgr_args+0x49b ffs_copyonwrite() at ffs_copyonwrite+0x19a ffs_geom_strategy() at ffs_geom_strategy+0x1b5 bufwrite() at bufwrite+0xe9 ffs_sbupdate() at ffs_sbupdate+0x12a g_journal_ufs_clean() at g_journal_ufs_clean+0x3e g_journal_switcher() at g_journal_switcher+0xe5e fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8242ca8cf0, rbp = 0 --- Tracing command mksnap_ffs pid 7126 tid 100157 td 0xffffff000807a470 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x42 _sleep() at _sleep+0x373 vn_start_write() at vn_start_write+0xdf ffs_snapshot() at ffs_snapshot+0xe2b ffs_mount() at ffs_mount+0x65a vfs_donmount() at vfs_donmount+0xdc5 nmount() at nmount+0x63 amd64_syscall() at amd64_syscall+0x1f4 Xfast_syscall() at Xfast_syscall+0xfc --- syscall (378, FreeBSD ELF64, nmount), rip = 0x18069e35c, rsp = 0x7fffffffe358, rbp = 0x7fffffffedc7 --- There are a lot of other - but later started than pid 7126 - processes sitting on the suspfs lock, most of them hang on a close with a stack like this: Tracing command cat pid 17726 tid 100387 td 0xffffff012e4bd470 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x42 _sleep() at _sleep+0x373 vn_start_write() at vn_start_write+0xdf vn_close() at vn_close+0x5b vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x45 kern_close() at kern_close+0x163 amd64_syscall() at amd64_syscall+0x1f4 Xfast_syscall() at Xfast_syscall+0xfc --- syscall (6, FreeBSD ELF64, close), rip = 0x18073f07c, rsp = 0x7fffffffeb68, rbp = 0 --- If more information is necessary to catch this problem, I can try to reproduce the problem with a suitable debug kernel. -- Andreas Longwitz From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 19:41:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D826E9A9; Thu, 27 Dec 2012 19:41:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 47AF48FC08; Thu, 27 Dec 2012 19:41:50 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBRJfjEG051356; Thu, 27 Dec 2012 21:41:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBRJfjEG051356 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBRJfjwi051355; Thu, 27 Dec 2012 21:41:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Dec 2012 21:41:45 +0200 From: Konstantin Belousov To: Andreas Longwitz Subject: Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup Message-ID: <20121227194145.GM82219@kib.kiev.ua> References: <50DC30F6.1050904@incore.de> <20121227133355.GI82219@kib.kiev.ua> <50DC8999.8000708@incore.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zHDeOHGDnzKksZSU" Content-Disposition: inline In-Reply-To: <50DC8999.8000708@incore.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 19:41:50 -0000 --zHDeOHGDnzKksZSU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 27, 2012 at 06:47:05PM +0100, Andreas Longwitz wrote: > Konstantin Belousov wrote: > > On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote: > >> On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed t= he > >> same behaviour as described for UFS+SU+J in > >> lists.freebsd.org/pipermail/freebsd-current/2012-January/030937.html. > >> > >> The snapshot was initiated by amanda with > >> dump 3ubLshf 64 1048576 0 - /dev/mirror/gm0p10.journal (pid 50347) > >> and the process creating the snapshot is > >> /sbin/mksnap_ffs /home /home/.snap/dump_snapshot (pid 50350). > >> > >> The process 50350 hangs and also all following processes that tried to > >> access the home partition, some of them work, but don't come to an end, > >> e.g. a shell after (Ctrl T): > >> load: 0.61 cmd: sh 52670 [suspfs] 43.46r 0.00u 0.00s 0% 2272k. > >> > >> All write I/O's to all gjournaled partitions are stopped. Under normal > >> circumstances the snapshot is taken in five seconds, so I have definit= iv > >> not the problem I have described in > >> lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html. > >> > >> ..... > >> > >> It seems there is a deadlock on the suspfs lock, but I could not figure > >> out who holds this lock. > >> Any hints how to get better diagnostic information for next time the > >> error occurs are welcome. > >=20 > > The > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke= rneldebug-deadlocks.html > > provides the instructions. > >=20 > > The suspfs is owned by the snapshot creator. The question is, where is = it > > blocked. >=20 > Thanks for answer. >=20 > In the meantime I can reproduce the problem and got some more > information. It looks that there is a deadlock between the two processes > with pid 18 (g_journal switcher) and pid 7126 (/sbin/mksnap_ffs /home > /home/.snap/my_snapshot): >=20 > 0 18 0 0 45 0 0 16 snaplk DL ?? 4:40,34 > [g_journal switcher] > 0 7126 1933 0 50 0 5836 1176 suspfs D ?? 0:00,44 > /sbin/mksnap_ffs /home /home/.snap/my_snapshot >=20 > procstat -t 18 --> > PID TID COMM TDNAME CPU PRI STATE WCHAN > 18 100076 g_journal switcher g_journal switch 0 129 sleep snaplk > procstat -t 7126 --> > PID TID COMM TDNAME CPU PRI STATE WCHAN > 7126 100157 mksnap_ffs - 1 134 sleep suspfs > procstat -kk 18 --> > PID TID COMM TDNAME KSTACK > 18 100076 g_journal switcher g_journal switch mi_switch+0x186 > sleepq_wait+0x42 __lockmgr_args+0x49b ffs_copyonwrite > +0x19a ffs_geom_strategy+0x1b5 bufwrite+0xe9 ffs_sbupdate+0x12a > g_journal_ufs_clean+0x3e g_journal_switcher+0xe5e fork > _exit+0x11f fork_trampoline+0xe > procstat -kk 7126 --> > PID TID COMM TDNAME KSTACK > 7126 100157 mksnap_ffs - mi_switch+0x186 > sleepq_wait+0x42 _sleep+0x373 vn_start_write+0xdf ffs_s > napshot+0xe2b ffs_mount+0x65a vfs_donmount+0xdc5 nmount+0x63 > amd64_syscall+0x1f4 Xfast_syscall+0xfc >=20 > >From DDB: > db> show lockedvnods > Locked vnodes >=20 > 0xffffff012281a938: tag ufs, type VREG > usecount 1, writecount 0, refcount 3339 mountedhere 0 > flags (VV_SYSTEM) > lock type snaplk: EXCL by thread 0xffffff000807a470 (pid 7126) > with exclusive waiters pending > ino 23552, on dev mirror/gm0p10.journal =2E.. > db> alltrace (pid 18 and 7126) >=20 > Tracing command g_journal switcher pid 18 tid 100076 td 0xffffff0002bd5000 > sched_switch() at sched_switch+0xde > mi_switch() at mi_switch+0x186 > sleepq_wait() at sleepq_wait+0x42 > __lockmgr_args() at __lockmgr_args+0x49b > ffs_copyonwrite() at ffs_copyonwrite+0x19a > ffs_geom_strategy() at ffs_geom_strategy+0x1b5 > bufwrite() at bufwrite+0xe9 > ffs_sbupdate() at ffs_sbupdate+0x12a > g_journal_ufs_clean() at g_journal_ufs_clean+0x3e > g_journal_switcher() at g_journal_switcher+0xe5e > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff8242ca8cf0, rbp =3D 0 --- >=20 > Tracing command mksnap_ffs pid 7126 tid 100157 td 0xffffff000807a470 > sched_switch() at sched_switch+0xde > mi_switch() at mi_switch+0x186 > sleepq_wait() at sleepq_wait+0x42 > _sleep() at _sleep+0x373 > vn_start_write() at vn_start_write+0xdf > ffs_snapshot() at ffs_snapshot+0xe2b Can you look up the line number for the ffs_snapshot+0xe2b ? I think the bug is that vn_start_write() is called while the snaplock is owned, after the out1 label in ffs_snapshot() (I am looking at the HEAD code). > ffs_mount() at ffs_mount+0x65a > vfs_donmount() at vfs_donmount+0xdc5 > nmount() at nmount+0x63 > amd64_syscall() at amd64_syscall+0x1f4 > Xfast_syscall() at Xfast_syscall+0xfc > --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x18069e35c, rsp =3D > 0x7fffffffe358, rbp =3D 0x7fffffffedc7 --- >=20 > There are a lot of other - but later started than pid 7126 - processes > sitting on the suspfs lock, most of them hang on a close with a stack > like this: >=20 > Tracing command cat pid 17726 tid 100387 td 0xffffff012e4bd470 > sched_switch() at sched_switch+0xde > mi_switch() at mi_switch+0x186 > sleepq_wait() at sleepq_wait+0x42 > _sleep() at _sleep+0x373 > vn_start_write() at vn_start_write+0xdf > vn_close() at vn_close+0x5b > vn_closefile() at vn_closefile+0x5a > _fdrop() at _fdrop+0x23 > closef() at closef+0x45 > kern_close() at kern_close+0x163 > amd64_syscall() at amd64_syscall+0x1f4 > Xfast_syscall() at Xfast_syscall+0xfc > --- syscall (6, FreeBSD ELF64, close), rip =3D 0x18073f07c, rsp =3D > 0x7fffffffeb68, rbp =3D 0 --- >=20 >=20 > If more information is necessary to catch this problem, I can try to > reproduce the problem with a suitable debug kernel. >=20 > --=20 > Andreas Longwitz --zHDeOHGDnzKksZSU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ3KR4AAoJEJDCuSvBvK1BOTEP/RIsmiLgE2r+ansViY7TGdv9 a/P0lQK/+a/+TZ2K24h+J5/sqBHFNnBq9mxD+8OwLBdGjYtoKb4uDio2DyS/xjBd r1nP+XZxL5DS9cHTE7gzFJvX4i6T+g77L9PQkWaux1LhY06NW0gW/XytzWUcMl27 gQ66zXgpzvxC6IrQHOm8CN1F94N2wmu6o+3/mpP9XzbvShljkx+t2u7CqZpwQ7US ItqSLMo6oUzfYYcWXskTud2BFbfcDaZXZ4ZwNt5MwmpnGBti+Cxq9D04NDNy5TYa 0zEsELjWv7DHxSOviD2YNdQR1o3dYPtHrWrnnFTMOL2ZFOao/XoDQmT8oR1qbUoB I2BfpPBJ7rb52nS5oota19H3bjYqpTwQU/JFTQfoq9vkrt0WgktDPf+bgJdltw+y Iaeq5osr2pdLjbdTiPve0UGgbFD4ayQVuRUOYJ/2dwC/eSQ+suMVhFgwx37o+TfQ qKms7hpu3IuYKHBA+Von4RBB+g58PKbvEfAI9VY3D6xGj9hZ3R5wrh5GXvW3dI5U 4mBjPFaJXolubmwAgmJWNPcb5mNuJhEj0fhs/9XtN5V+bux6szt3cZdEN68zjA9F k8hkP+FfvOa3VqGCdF6EfjcItcyUXw/l2vYJcmWzcSmP+EO8geyiE/DYtcKANvQd hBoR2RLQOYj541So28Xd =ywrw -----END PGP SIGNATURE----- --zHDeOHGDnzKksZSU-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 20:27:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B985910 for ; Thu, 27 Dec 2012 20:27:25 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by mx1.freebsd.org (Postfix) with ESMTP id AFE838FC0A for ; Thu, 27 Dec 2012 20:27:24 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id hm11so7968854wib.14 for ; Thu, 27 Dec 2012 12:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9BNZzQJHuG3zGyc8IXq/wVfqOK1FA/vjxeVlbmWarUg=; b=U0hUm+5slo4aA8czW+ZNEN2AdD34pKkQ+1fxQSiqlfsCuyd6fmmb+nDd7oqAqRnksX /YzMyeSRfnNSNzmAa8nGanSaJw64VXrIrzKOCSj2izfNLOkPCvQJKxs6ZQ2qOqnbgdvy kCBcyC0o9tdRMYLOCSDCGUVDLFJJ8EfDyRyY0+CgewJT5pIRnUaaFJd8GFS15XwzX/CY V/x08E6fLSGgrNqIylwzzxzp1IpzgIv1EPMZvvi2m3YplSLcXOWgKd7ymOiGdapIETSN cre8n1yYuz09UmrvAkX501X7S2TAlqbN59PbtDuMlnTVNYucsLzzaTKYyQy+7KwIq89h gKQA== MIME-Version: 1.0 Received: by 10.194.9.162 with SMTP id a2mr50495773wjb.33.1356640038217; Thu, 27 Dec 2012 12:27:18 -0800 (PST) Received: by 10.216.172.197 with HTTP; Thu, 27 Dec 2012 12:27:18 -0800 (PST) In-Reply-To: <20121227172256.647c6728@suse3> References: <20121227172256.647c6728@suse3> Date: Thu, 27 Dec 2012 22:27:18 +0200 Message-ID: Subject: Re: Anothe pkgng question: signing a repository From: Kimmo Paasiala To: Rainer Duffner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 20:27:25 -0000 On Thu, Dec 27, 2012 at 6:22 PM, Rainer Duffner wrote: > Hi, > > I'm creating my own repository and have created a key for it. > > I've created a CSR for it and used that to generate a certificate via > our internal CA. Because there was no other information available, I > used the profile that we use to generate SSL-certificates for web > servers. > > I copied the certificate to the server and adjusted pkg.conf, but when I > want to query the repository, I get: > > root@server:/etc/ssl/cert # pkg install net-snmpd > Updating repository catalogue > repo.txz > 100% 219KB 219.5KB/s 219.5KB/s 00:00 pkg: error reading public > key(/etc/ssl/pkg.conf): error:0906D06C:PEM routines:PEM_read_bio:no > start line pkg: Invalid signature, removing repository. > > > What does pkg expect to be in this file? > > > openssl x509 displays the data for the certificate correctly, so I > really don't know what's missing. > > I ktraced pkg and it is indeed reading the file. > > > > > Best Regards > Rainer See Glen Barber's page about "Maintaining your own pkgng repository". https://glenbarber.us/2012/06/11/Maintaining-Your-Own-pkgng-Repository.html HTH -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 21:01:45 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F05EA3D8 for ; Thu, 27 Dec 2012 21:01:45 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id A162E8FC0A for ; Thu, 27 Dec 2012 21:01:45 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id qBRL1iCp016549; Thu, 27 Dec 2012 16:01:44 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id qBRL1hXP016548; Thu, 27 Dec 2012 16:01:43 -0500 (EST) (envelope-from wollman) Date: Thu, 27 Dec 2012 16:01:43 -0500 (EST) From: Garrett Wollman Message-Id: <201212272101.qBRL1hXP016548@hergotha.csail.mit.edu> To: rainer@ultra-secure.de Subject: Re: Anothe pkgng question: signing a repository In-Reply-To: <20121227162311$64db@grapevine.csail.mit.edu> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 27 Dec 2012 16:01:44 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,LOTS_OF_MONEY autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 21:01:46 -0000 In article <20121227162311$64db@grapevine.csail.mit.edu>, rainer@ultra-secure.de writes: >I'm creating my own repository and have created a key for it. [...] >What does pkg expect to be in this file? A public key. It does not use X.509 (nor is there any reason why it should, although I suppose it could be made to at the cost of significant added complexity and a bootstrapping problem). -GAWollman From owner-freebsd-stable@FreeBSD.ORG Thu Dec 27 21:42:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54AEFE45; Thu, 27 Dec 2012 21:42:51 +0000 (UTC) (envelope-from schors@gmail.com) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by mx1.freebsd.org (Postfix) with ESMTP id 92BE18FC0A; Thu, 27 Dec 2012 21:42:50 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id z14so12949836lag.16 for ; Thu, 27 Dec 2012 13:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rY4/kRfhW/8nWiUep3wxXOGt1IDoKwm2LwaiuDnPk2Y=; b=nhioA1NeZTaSYaSxe7QufuYFTcY8fpfbJdeEgeHkr7bC+GJZrKCTvobtYTIlksA/p9 /Nl2Kzwl+6Ppy6jo35SNU9+iC+X745B3NU99204s5dyhGwGw4X8/W9OYE+75lF21wTDQ wzB9LiUG9u4RSGjbGDtrWYDw5kHA6mj/eMRLQ8AEiWiiulYh++5X00sCz6yf/NovV2l0 EYquWhY38nMjVyMg30de5ZfUNqMOiOwDXTNlLqzPOt3BqE82AQPKqProgqnCeIzZa4i7 0rYeb02Xrnx6N436Wnhi4buBHr2BrjiL6cjXaJwiGMsROm4uJ66+I14Bub6UTnxLYJ0f kN+g== MIME-Version: 1.0 Received: by 10.112.99.197 with SMTP id es5mr9433383lbb.30.1356644568930; Thu, 27 Dec 2012 13:42:48 -0800 (PST) Received: by 10.114.5.138 with HTTP; Thu, 27 Dec 2012 13:42:48 -0800 (PST) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> Date: Fri, 28 Dec 2012 01:42:48 +0400 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Phil Kulin To: Kimmo Paasiala Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 21:42:51 -0000 2012/12/26 Kimmo Paasiala : > I've revised the patch again and updated it at gihub, > https://gist.github.com/4362018. It can now be applied at top level > of sources (/usr/src typically). It now does the deconfiguration in > reverse order of the configuration, meaning the aliases configured > with ipv6_addrs_IF are removed before the ones configured with > ifconfig_IF_aliasN="inet6 ...". Adapted for FreeBSD 8.2, works fine: --- network.subr.orig 2011-02-17 05:19:39.000000000 +0300 +++ network.subr 2012-12-28 00:46:38.000000000 +0400 @@ -312,6 +312,12 @@ afexists() # 1 otherwise. ipv6if() { + # Test for $ipv6_addrs_IF. If it exists then the + # interface should be configured for IPv6 + _tmpargs=$(get_if_var $_if ipv6_addrs_IF) + if [ -n "${_tmpargs}" ]; then + return 0 + fi if ! checkyesno ipv6_enable; then return 1 fi @@ -948,7 +954,12 @@ network6_interface_setup() rtsol_interface=no ifconfig $i inet6 ${ipv6_ifconfig} alias fi - + ipv6_addrs=`get_if_var $i ipv6_addrs_IF` + if [ -n "${ipv6_addrs}" ]; then + rtsol_available=no + rtsol_interface=no + ipv6_addrs_common ${i} alias + fi # Wireless NIC cards are virtualized through the wlan interface if ! is_wired_interface ${i}; then case "${i}" in @@ -1178,3 +1189,39 @@ network6_getladdr() esac done } + +ipv6_addrs_common() +{ + local _ret _if _action _ip6prefix _ip6prefixes + local _ip6addr _prefixlen + local _range _ip6net _ip6low _ip6high + _ret=1 + _if=$1 + _action=$2 + # get the prefixes from ipv6_addrs_IF variable + _ip6prefixes=`get_if_var $_if ipv6_addrs_IF` + for _ip6prefix in ${_ip6prefixes}; do + _ip6addr=${_ip6prefix%%/*} + _prefixlen=${_ip6prefix##*/} + _range=${_ip6addr##*:} + _ip6net=${_ip6addr%:*} + _ip6low=${_range%-*} + _ip6high=${_range#*-} + # If deleting an alias, set _prefixlen to null string. + if [ "${_action}" = "-alias" ]; then + _prefixlen="" + else + _prefixlen="prefixlen $_prefixlen" + fi + _ip6high=$(("0x${_ip6high}")) + _ip6count=$(("0x${_ip6low}")) + while [ "${_ip6count}" -le "${_ip6high}" ]; do + # Re-uses the _ip6addr variable from above + _ip6addr=$(printf "%x" "${_ip6count}") + eval "ifconfig ${_if} inet6 ${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}" + _ip6count=$((${_ip6count}+1)) + _ret=0 + done + done + return $_ret +} -- Non nobis Domine non nobis sed Nomini Tuo da gloriam Phil Kulin From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 02:22:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3DECE61 for ; Fri, 28 Dec 2012 02:22:57 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id CC5928FC08 for ; Fri, 28 Dec 2012 02:22:57 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 7C07B56078; Thu, 27 Dec 2012 20:22:50 -0600 (CST) Date: Thu, 27 Dec 2012 20:22:50 -0600 From: Mark Linimon To: Zoran Kolic Subject: Re: 9.1 minimal ram requirements Message-ID: <20121228022250.GA9064@lonesome.com> References: <20121225151532.GA1404@faust.sbb.rs> <20121226170233.GA1408@faust.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121226170233.GA1408@faust.sbb.rs> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 02:22:58 -0000 On Wed, Dec 26, 2012 at 06:02:33PM +0100, Zoran Kolic wrote: > > Seeing 9.1-RELEASE instead 9.1-PRERELASE > > or 9.1-RC4 is also a bad suprise for me... > > I assume it does not look like release is the lack > of packages. What you are seeing is behind-the-scenes preparation. The release is official when, and only when, a security-signed email is sent to freebsd-announce@FreeBSD.org from the Release Engineering team. mcl From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 09:19:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DC51803; Fri, 28 Dec 2012 09:19:34 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id D3CAA8FC12; Fri, 28 Dec 2012 09:19:33 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id D880A5C36A; Fri, 28 Dec 2012 10:19:32 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id rwPEqDXUl2Da; Fri, 28 Dec 2012 10:19:32 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 001015C36E; Fri, 28 Dec 2012 10:19:31 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id EA0615083F; Fri, 28 Dec 2012 10:19:31 +0100 (CET) Message-ID: <50DD6423.5090305@incore.de> Date: Fri, 28 Dec 2012 10:19:31 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup References: <50DC30F6.1050904@incore.de> <20121227133355.GI82219@kib.kiev.ua> <50DC8999.8000708@incore.de> <20121227194145.GM82219@kib.kiev.ua> In-Reply-To: <20121227194145.GM82219@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 09:19:34 -0000 Konstantin Belousov wrote: >>> On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote: >> db> alltrace (pid 18 and 7126) >> >> Tracing command g_journal switcher pid 18 tid 100076 td 0xffffff0002bd5000 >> sched_switch() at sched_switch+0xde >> mi_switch() at mi_switch+0x186 >> sleepq_wait() at sleepq_wait+0x42 >> __lockmgr_args() at __lockmgr_args+0x49b >> ffs_copyonwrite() at ffs_copyonwrite+0x19a >> ffs_geom_strategy() at ffs_geom_strategy+0x1b5 >> bufwrite() at bufwrite+0xe9 >> ffs_sbupdate() at ffs_sbupdate+0x12a >> g_journal_ufs_clean() at g_journal_ufs_clean+0x3e >> g_journal_switcher() at g_journal_switcher+0xe5e >> fork_exit() at fork_exit+0x11f >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffff8242ca8cf0, rbp = 0 --- >> >> Tracing command mksnap_ffs pid 7126 tid 100157 td 0xffffff000807a470 >> sched_switch() at sched_switch+0xde >> mi_switch() at mi_switch+0x186 >> sleepq_wait() at sleepq_wait+0x42 >> _sleep() at _sleep+0x373 >> vn_start_write() at vn_start_write+0xdf >> ffs_snapshot() at ffs_snapshot+0xe2b > Can you look up the line number for the ffs_snapshot+0xe2b ? (kgdb) list *ffs_snapshot+0xe2b 0xffffffff8056287b is in ffs_snapshot (/usr/src/sys/ufs/ffs/ffs_snapshot.c:676). 671 /* 672 * Resume operation on filesystem. 673 */ 674 vfs_write_resume(vp->v_mount); 675 vn_start_write(NULL, &wrtmp, V_WAIT); 676 if (collectsnapstats && starttime.tv_sec > 0) { 677 nanotime(&endtime); 678 timespecsub(&endtime, &starttime); 679 printf("%s: suspended %ld.%03ld sec, redo %ld of %d\n", 680 vp->v_mount->mnt_stat.f_mntonname, (long)endtime.tv_sec, > I think the bug is that vn_start_write() is called while the snaplock > is owned, after the out1 label in ffs_snapshot() (I am looking at the > HEAD code). You are right, the vn_start_write() is just after the out1 label. >> ffs_mount() at ffs_mount+0x65a >> vfs_donmount() at vfs_donmount+0xdc5 >> nmount() at nmount+0x63 >> amd64_syscall() at amd64_syscall+0x1f4 >> Xfast_syscall() at Xfast_syscall+0xfc >> --- syscall (378, FreeBSD ELF64, nmount), rip = 0x18069e35c, rsp = >> 0x7fffffffe358, rbp = 0x7fffffffedc7 --- -- Andreas Longwitz From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 11:27:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07BC8F61; Fri, 28 Dec 2012 11:27:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 514388FC0A; Fri, 28 Dec 2012 11:27:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBSBROYj042785; Fri, 28 Dec 2012 13:27:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBSBROYj042785 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBSBRO4f042784; Fri, 28 Dec 2012 13:27:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 28 Dec 2012 13:27:24 +0200 From: Konstantin Belousov To: Andreas Longwitz Subject: Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup Message-ID: <20121228112724.GR82219@kib.kiev.ua> References: <50DC30F6.1050904@incore.de> <20121227133355.GI82219@kib.kiev.ua> <50DC8999.8000708@incore.de> <20121227194145.GM82219@kib.kiev.ua> <50DD6423.5090305@incore.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r7tUYVWcdYzDJoZW" Content-Disposition: inline In-Reply-To: <50DD6423.5090305@incore.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: pho@freebsd.org, freebsd-stable@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 11:27:31 -0000 --r7tUYVWcdYzDJoZW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 28, 2012 at 10:19:31AM +0100, Andreas Longwitz wrote: > Konstantin Belousov wrote: > >>> On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote: > >> db> alltrace (pid 18 and 7126) > >> > >> Tracing command g_journal switcher pid 18 tid 100076 td 0xffffff0002bd= 5000 > >> sched_switch() at sched_switch+0xde > >> mi_switch() at mi_switch+0x186 > >> sleepq_wait() at sleepq_wait+0x42 > >> __lockmgr_args() at __lockmgr_args+0x49b > >> ffs_copyonwrite() at ffs_copyonwrite+0x19a > >> ffs_geom_strategy() at ffs_geom_strategy+0x1b5 > >> bufwrite() at bufwrite+0xe9 > >> ffs_sbupdate() at ffs_sbupdate+0x12a > >> g_journal_ufs_clean() at g_journal_ufs_clean+0x3e > >> g_journal_switcher() at g_journal_switcher+0xe5e > >> fork_exit() at fork_exit+0x11f > >> fork_trampoline() at fork_trampoline+0xe > >> --- trap 0, rip =3D 0, rsp =3D 0xffffff8242ca8cf0, rbp =3D 0 --- > >> > >> Tracing command mksnap_ffs pid 7126 tid 100157 td 0xffffff000807a470 > >> sched_switch() at sched_switch+0xde > >> mi_switch() at mi_switch+0x186 > >> sleepq_wait() at sleepq_wait+0x42 > >> _sleep() at _sleep+0x373 > >> vn_start_write() at vn_start_write+0xdf > >> ffs_snapshot() at ffs_snapshot+0xe2b > > Can you look up the line number for the ffs_snapshot+0xe2b ? >=20 > (kgdb) list *ffs_snapshot+0xe2b > 0xffffffff8056287b is in ffs_snapshot > (/usr/src/sys/ufs/ffs/ffs_snapshot.c:676). > 671 /* > 672 * Resume operation on filesystem. > 673 */ > 674 vfs_write_resume(vp->v_mount); > 675 vn_start_write(NULL, &wrtmp, V_WAIT); > 676 if (collectsnapstats && starttime.tv_sec > 0) { > 677 nanotime(&endtime); > 678 timespecsub(&endtime, &starttime); > 679 printf("%s: suspended %ld.%03ld sec, redo %ld of %d\n", > 680 vp->v_mount->mnt_stat.f_mntonname, (long)endtime.tv_sec, >=20 > > I think the bug is that vn_start_write() is called while the snaplock > > is owned, after the out1 label in ffs_snapshot() (I am looking at the > > HEAD code). >=20 > You are right, the vn_start_write() is just after the out1 label. Please try the following patch. It is against HEAD, might need some adjustments for 8. I do the resume and write accounting atomically, not allowing other suspension to intervent between. diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index 3f65b05..cf49ecb 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -1434,6 +1434,40 @@ vn_closefile(fp, td) * proceed. If a suspend request is in progress, we wait until the * suspension is over, and then proceed. */ +static int +vn_start_write_locked(struct mount *mp, int flags) +{ + int error; + + mtx_assert(MNT_MTX(mp), MA_OWNED); + error =3D 0; + + /* + * Check on status of suspension. + */ + if ((curthread->td_pflags & TDP_IGNSUSP) =3D=3D 0 || + mp->mnt_susp_owner !=3D curthread) { + while ((mp->mnt_kern_flag & MNTK_SUSPEND) !=3D 0) { + if (flags & V_NOWAIT) { + error =3D EWOULDBLOCK; + goto unlock; + } + error =3D msleep(&mp->mnt_flag, MNT_MTX(mp), + (PUSER - 1) | (flags & PCATCH), "suspfs", 0); + if (error) + goto unlock; + } + } + if (flags & V_XSLEEP) + goto unlock; + mp->mnt_writeopcount++; +unlock: + if (error !=3D 0 || (flags & V_XSLEEP) !=3D 0) + MNT_REL(mp); + MNT_IUNLOCK(mp); + return (error); +} + int vn_start_write(vp, mpp, flags) struct vnode *vp; @@ -1470,30 +1504,7 @@ vn_start_write(vp, mpp, flags) if (vp =3D=3D NULL) MNT_REF(mp); =20 - /* - * Check on status of suspension. - */ - if ((curthread->td_pflags & TDP_IGNSUSP) =3D=3D 0 || - mp->mnt_susp_owner !=3D curthread) { - while ((mp->mnt_kern_flag & MNTK_SUSPEND) !=3D 0) { - if (flags & V_NOWAIT) { - error =3D EWOULDBLOCK; - goto unlock; - } - error =3D msleep(&mp->mnt_flag, MNT_MTX(mp), - (PUSER - 1) | (flags & PCATCH), "suspfs", 0); - if (error) - goto unlock; - } - } - if (flags & V_XSLEEP) - goto unlock; - mp->mnt_writeopcount++; -unlock: - if (error !=3D 0 || (flags & V_XSLEEP) !=3D 0) - MNT_REL(mp); - MNT_IUNLOCK(mp); - return (error); + return (vn_start_write_locked(mp, flags)); } =20 /* @@ -1639,8 +1650,7 @@ vfs_write_suspend(mp) * Request a filesystem to resume write operations. */ void -vfs_write_resume(mp) - struct mount *mp; +vfs_write_resume_flags(struct mount *mp, int flags) { =20 MNT_ILOCK(mp); @@ -1652,10 +1662,25 @@ vfs_write_resume(mp) wakeup(&mp->mnt_writeopcount); wakeup(&mp->mnt_flag); curthread->td_pflags &=3D ~TDP_IGNSUSP; + if ((flags & VR_START_WRITE) !=3D 0) { + MNT_REF(mp); + mp->mnt_writeopcount++; + } MNT_IUNLOCK(mp); VFS_SUSP_CLEAN(mp); - } else + } else if ((flags & VR_START_WRITE) !=3D 0) { + MNT_REF(mp); + vn_start_write_locked(mp, 0); + } else { MNT_IUNLOCK(mp); + } +} + +void +vfs_write_resume(struct mount *mp) +{ + + vfs_write_resume_flags(mp, 0); } =20 /* diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index 42f9e5f..4371b40 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -392,6 +392,8 @@ extern int vttoif_tab[]; #define V_NOWAIT 0x0002 /* vn_start_write: don't sleep for suspend */ #define V_XSLEEP 0x0004 /* vn_start_write: just return after sleep */ =20 +#define VR_START_WRITE 0x0001 /* vfs_write_resume: start write atomically = */ + #define VREF(vp) vref(vp) =20 #ifdef DIAGNOSTIC @@ -701,6 +703,7 @@ int vn_io_fault_uiomove(char *data, int xfersize, struc= t uio *uio); int vfs_cache_lookup(struct vop_lookup_args *ap); void vfs_timestamp(struct timespec *); void vfs_write_resume(struct mount *mp); +void vfs_write_resume_flags(struct mount *mp, int flags); int vfs_write_suspend(struct mount *mp); int vop_stdbmap(struct vop_bmap_args *); int vop_stdfsync(struct vop_fsync_args *); diff --git a/sys/ufs/ffs/ffs_snapshot.c b/sys/ufs/ffs/ffs_snapshot.c index e528509..25ad79c 100644 --- a/sys/ufs/ffs/ffs_snapshot.c +++ b/sys/ufs/ffs/ffs_snapshot.c @@ -687,8 +687,7 @@ out1: /* * Resume operation on filesystem. */ - vfs_write_resume(vp->v_mount); - vn_start_write(NULL, &wrtmp, V_WAIT); + vfs_write_resume_flags(vp->v_mount, VR_START_WRITE); if (collectsnapstats && starttime.tv_sec > 0) { nanotime(&endtime); timespecsub(&endtime, &starttime); --r7tUYVWcdYzDJoZW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ3YIbAAoJEJDCuSvBvK1BencP/0168lx07OvV4T7toyComatr aMz0nFicRqIkTzK52yDACCt8XMarnzV87EzkHfirRbtu4xwjxF27BHIgowDUCeDW U4Cne6f9wt8zVX/9NkGYmbJAZ5Osuz22nAUz5AAd9H6S05IC4HJ/+ovsWw57riEU ljWNkCS+tRs8uFjAK6aKUiE7c5eoaL+IXVCrdAVW2Puc48eJ9B6dl9NesYdbCqEs RkTD6RyG0qdHPEsBpYmyxq+uklJVlrm3uxEzKhbmbCEcfrwynXvb/wR0d4Kfmyb2 tje334D/C7+nv6oITdMOqfkdbBDJuKGMR9aWh+8lkuCgZnK7SLC3tYsEOGhk3EBy /mo1W7DpcWu2qciEDsJDBCQQ1r8ZJXFT8Rtx0c2KzioNbsGriTiVkcghJBMzvUMi nNbUkoGu/37w9J4t+kxbDgLtRiPI9P5YfOEUHJgGnVP3o/4JQkmcDnDiKZnw6NhF s1qXtk7pVFHgrJ2sN40NkX2rIZvE4Ih/Ueti83UWmWwr9p9sF/O/0TIDXMmImNAa MYnGvTx8pPgmXFjfGKkAc2EYG24PAuXhSD1oXZjY+z2m3UKgXpQ01oCLv2i6kkRL XCSuN6b/vQ6VyDvUCnZt1u+gbg7hgiM3htHnXHjDlRu/QaY/EiJHcUFWljpClb63 Po93TZJCvHxewZsuu1Kf =EJ0n -----END PGP SIGNATURE----- --r7tUYVWcdYzDJoZW-- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 11:33:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65613301 for ; Fri, 28 Dec 2012 11:33:29 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by mx1.freebsd.org (Postfix) with ESMTP id CF8788FC08 for ; Fri, 28 Dec 2012 11:33:28 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id ej20so648412lab.7 for ; Fri, 28 Dec 2012 03:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hRGMHRMRN12zfm7q/STBOIuUXucX6/CgVLOapKf0Zk0=; b=eGMnzQQFsPMoYrhpvqbB218phw085bb7niFaPHgpUz3HjZuId60HHp5hs1Y4cqwrhL l80MG+wYToGYzCcg6xZkGA+MxSGt5XqfWVRtK+dhO3nszM+HM5AmBCkyLu1ogNfgihX5 slHnxuWhj6IlLCTFacfUtJQAupWUmDIhr0EIa64217201aUx1ldDZHjaNs9NmMbzPisj EtP/A50q1Bj7zak4WMQE0wLfqG6KRPvTOBleQHIquxElmBkjyVBINlK5W+/ysW6NveBX WwxuTwteXtkle6sco38F85V51HHMXYgxc7+huhtUbkP/JwXk3cUK/sPFPzoygCL4Ynq3 QQUQ== MIME-Version: 1.0 Received: by 10.112.51.175 with SMTP id l15mr12881569lbo.5.1356694407338; Fri, 28 Dec 2012 03:33:27 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.11.165 with HTTP; Fri, 28 Dec 2012 03:33:27 -0800 (PST) In-Reply-To: <1356628066796-5772624.post@n5.nabble.com> References: <1356628066796-5772624.post@n5.nabble.com> Date: Fri, 28 Dec 2012 12:33:27 +0100 X-Google-Sender-Auth: 0nfvfcOM_bZneICQOoStNAR73Ik Message-ID: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel From: CeDeROM To: Jakub Lach Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 11:33:29 -0000 On Thu, Dec 27, 2012 at 6:07 PM, Jakub Lach wrote: > xf86-input-mouse-1.8.1 is in dev trunk xorg tree. (see -x11). This is the only sensible solution to use new driver. HAL and AllowEmptyInput are EXCLUSIVE and cause very strange behavior - I have just noticed that again on another desktop - screen is refreshed AFTER mouse is moved heh... Still I cannot see the new 1.8.1 driver after updating the port tree... cannot wait to see that one, still I think this is a must for a "release package" :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 11:41:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 171EC444 for ; Fri, 28 Dec 2012 11:41:40 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id E2E5C8FC08 for ; Fri, 28 Dec 2012 11:41:39 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1ToYJm-0000Ph-IP for freebsd-stable@freebsd.org; Fri, 28 Dec 2012 03:41:38 -0800 Date: Fri, 28 Dec 2012 03:41:38 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1356694898559-5772781.post@n5.nabble.com> In-Reply-To: References: <1356628066796-5772624.post@n5.nabble.com> Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 11:41:40 -0000 1.8.1 is in staging area (dev trunk). It will be not in packages distributed with 9.1. They were just apps which happened to be in ports tree at packages building for release time. There is only one branch of ports. hal is less and less used/supported and it was never meant to be used with AllowEmptyInput... http://wiki.freebsd.org/Xorg -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RC3-xorg-input-mouse-xfce4-panel-tp5772549p5772781.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 11:42:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1881F558 for ; Fri, 28 Dec 2012 11:42:54 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9C25A8FC0C for ; Fri, 28 Dec 2012 11:42:53 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id r6so4966938wey.10 for ; Fri, 28 Dec 2012 03:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=piJN3KwxZUETd8Vmx1eAZYpjbKlsJfOKR6AnQzvmJZI=; b=aTGlcZZDD1wpUs8uOa9J8a53/gyXLSq8DEwrzRR4aF7jYglXz1N6KqrxNx0IlVF16F 2WkIGLUyMtDv7Ol/sj8cvov/YK/sxjXCvghP1iX5tAazE3lFAaQdhPBsavXoa4Rk1AMa y+hn7bbsM7Uu5MSHzHXGojiJtiYwoYanO/GfG4hh29o7cxxrTzqn39w9H+Xz1q98UbLV vF2GOlcZBHJZAgNtmvtmqzfLMK8h97HvFhHP8x05xHvxeSWywxp76ecR32lOZxkdEnsb ijRz+lkYm8kKpmiPbQ1JaXgSLAZrE7vAgRs07T6AV0X8vPGQh5wWqDvDtyVFWwtYzXyr YNXg== MIME-Version: 1.0 Received: by 10.194.21.70 with SMTP id t6mr53212454wje.42.1356694972456; Fri, 28 Dec 2012 03:42:52 -0800 (PST) Received: by 10.216.172.197 with HTTP; Fri, 28 Dec 2012 03:42:52 -0800 (PST) In-Reply-To: References: <1356628066796-5772624.post@n5.nabble.com> Date: Fri, 28 Dec 2012 13:42:52 +0200 Message-ID: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel From: Kimmo Paasiala To: CeDeROM Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Jakub Lach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 11:42:54 -0000 On Fri, Dec 28, 2012 at 1:33 PM, CeDeROM wrote: > On Thu, Dec 27, 2012 at 6:07 PM, Jakub Lach wrote: >> xf86-input-mouse-1.8.1 is in dev trunk xorg tree. (see -x11). > > This is the only sensible solution to use new driver. HAL and > AllowEmptyInput are EXCLUSIVE and cause very strange behavior - I have > just noticed that again on another desktop - screen is refreshed AFTER > mouse is moved heh... > > Still I cannot see the new 1.8.1 driver after updating the port > tree... cannot wait to see that one, still I think this is a must for > a "release package" :-) > > Best regards :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info You're misunderstanding a few things. There are no "release packages" for any release of FreeBSD. What you have on the install discs are just "snapshot" packages built from the ports tree as it happened to be at the time of the release was made. If you want to see the newer mouse driver in ports help the xorg developers by testing their experimental tree. There's nothing to be done about the 9.1-RELEASE, the packages on the install discs will not have any experimental content. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 11:51:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E2867FF for ; Fri, 28 Dec 2012 11:51:38 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mx1.freebsd.org (Postfix) with ESMTP id 999678FC0A for ; Fri, 28 Dec 2012 11:51:37 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id fj20so684194lab.38 for ; Fri, 28 Dec 2012 03:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JimxZqH2vRjQscBTzsz/fiVkJkv/vbg+14Dfr1rducM=; b=dtyFF6uOyJO9QsE9aWCm7icyuVD3ErgZEj4gnKccPXFRft+dP5D48dQ5kOHfPjub4J dAffg1ZJhQZUb+nLSzr3poMXYwajRBZ+n4PQRtNVXycBGMnTuKiA2abz55113uRncj1X zeRilGvEBANCaq3xSWGrH7vn95MB92psXbkbFmpxGxeCvo94k7uMSKvEcSwiWo5M5gJJ epIYQ29h+1xL9TzJvqELagRAQnV+azmNy0UvdVJ2NJWVOS0+LZUosPD4GjltbxaraQbT k4KHrIgtRXlYnydnTKRAFSS6Eay8ZOnvMme5seggEK5IhZSJTM+0h2c0Y3THdUeEO9JF IuDg== MIME-Version: 1.0 Received: by 10.112.100.195 with SMTP id fa3mr13568499lbb.38.1356695496030; Fri, 28 Dec 2012 03:51:36 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.11.165 with HTTP; Fri, 28 Dec 2012 03:51:35 -0800 (PST) In-Reply-To: References: <1356628066796-5772624.post@n5.nabble.com> Date: Fri, 28 Dec 2012 12:51:35 +0100 X-Google-Sender-Auth: Pe-AUyk9ALAprtvNLzi01ruuy4o Message-ID: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel From: CeDeROM To: Kimmo Paasiala Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Jakub Lach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 11:51:38 -0000 On Fri, Dec 28, 2012 at 12:42 PM, Kimmo Paasiala wrote: > You're misunderstanding a few things. There are no "release packages" > for any release of FreeBSD. What you have on the install discs are > just "snapshot" packages built from the ports tree as it happened (...) I know, I hoped 1.7.2 driver or 1.8.1 can get into a port tree before packages for 9.1 are built and released. When I applied a patch (some structure fields initialization) from 1.7.2 on current 1.7.1 driver problem of detection and strange mouse behavior was gone. If 1.7.1 gets into the packages lots of people will report this issue... thats all. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 11:59:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 647759D2; Fri, 28 Dec 2012 11:59:31 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from mail.clearchain.com (leo.clearchain.com [199.73.29.74]) by mx1.freebsd.org (Postfix) with ESMTP id 258EF8FC0A; Fri, 28 Dec 2012 11:59:30 +0000 (UTC) Received: from [192.168.155.199] ([101.113.53.201]) (authenticated bits=0) by mail.clearchain.com (8.14.5/8.14.5) with ESMTP id qBSBiolU097918 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 28 Dec 2012 22:15:00 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <50DD8635.8020300@clearchain.com> Date: Fri, 28 Dec 2012 22:14:53 +1030 From: Benjamin Close User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Kenneth D. Merry" Subject: Re: usb port issue in 9.1-Prerelease (Possibly Cam related) References: <504DED78.2010203@clearchain.com> <20121008153546.GA7850@nargothrond.kdm.org> In-Reply-To: <20121008153546.GA7850@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.clearchain.com [199.73.29.74]); Fri, 28 Dec 2012 22:15:02 +1030 (CST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 11:59:31 -0000 On 9/10/2012 2:05 AM, Kenneth D. Merry wrote: > On Mon, Sep 10, 2012 at 23:09:04 +0930, Benjamin Close wrote: >> Hi Folks, >> I've facing an intermittent hang with a USB port which seems cam >> related: >> >> Event's that happen are: >> >> o USB modem (HUAWEI E220) plugged into PC >> >> ugen3.2: at usbus3 >> u3g0: <3G Modem> on usbus3 >> u3g0: Found 3 ports. >> umass0: on usbus3 >> umass0: SCSI over Bulk-Only; quirks = 0x0000 >> umass0:6:0:-1: Attached to scbus6 >> umass1: on usbus3 >> umass1: SCSI over Bulk-Only; quirks = 0x0000 >> umass1:7:1:-1: Attached to scbus7 >> cd1 at umass-sim0 bus 0 scbus6 target 0 lun 0 >> cd1: Removable CD-ROM SCSI-2 device >> cd1: 1.000MB/s transfers >> cd1: Attempt to query device size failed: NOT READY, Medium not present >> da0 at umass-sim1 bus 1 scbus7 target 0 lun 0 >> da0: Removable Direct Access SCSI-2 device >> da0: 1.000MB/s transfers >> da0: Attempt to query device size failed: NOT READY, Medium not present >> >> >> o Time Elapses....many packets passed, no da0 or cd1 used. >> >> >> o USB Modem drops off the bus >> (It does this occasionally as it resets itself) >> >> o Causes USB bus to lose devices >> >> ugen3.2: at usbus3 (disconnected) >> u3g0: at uhub3, port 1, addr 2 (disconnected) >> (cd1:umass-sim0:0:0:0): lost device, 1 refs >> (cd1:umass-sim0:0:0:0): removing device entry >> (pass4:umass-sim0:0:0:0): passdevgonecb: devfs entry is gone >> (da0:umass-sim1:1:0:0): lost device - 0 outstanding, 1 refs >> (da0:umass-sim1:1:0:0): removing device entry >> (pass5:umass-sim1:1:0:0): passdevgonecb: devfs entry is gone >> umass0: at uhub3, port 1, addr 2 (disconnected) >> >> >> At this point that particular USB port is effectively useless. Plugging >> anything into the ports shows no device showing up. >> >> Running usbconfig hangs with: >> >> PID TID COMM TDNAME KSTACK >> 48562 101874 usbconfig - mi_switch+0x186 >> sleepq_wait+0x42 _sx_xlock_hard+0x426 usbd_enum_lock+0xac >> usb_ref_device+0x21c usb_open+0xc7 devfs_open+0x197 vn_open_cred+0x2ff >> kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7 >> >> Controller is: >> >> uhci0@pci0:0:26:0: class=0x0c0300 card=0x02091028 chip=0x28348086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801H (ICH8 Family) USB UHCI Controller' >> class = serial bus >> subclass = USB >> uhci1@pci0:0:26:1: class=0x0c0300 card=0x02091028 chip=0x28358086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801H (ICH8 Family) USB UHCI Controller' >> class = serial bus >> subclass = USB >> ehci0@pci0:0:26:7: class=0x0c0320 card=0x02091028 chip=0x283a8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801H (ICH8 Family) USB2 EHCI Controller' >> class = serial bus >> subclass = USB >> >> It does however seem related to cam as looking at the various threads >> for the usb hub I find: >> >> (kgdb) bt >> #0 sched_switch (td=0xfffffe0002650000, newtd=0xfffffe000227f000, >> flags=Variable "flags" is not available. >> ) at /usr/src/sys/kern/sched_ule.c:1927 >> #1 0xffffffff808f34c6 in mi_switch (flags=260, newtd=0x0) at >> /usr/src/sys/kern/kern_synch.c:485 >> #2 0xffffffff8092bfd2 in sleepq_wait (wchan=0xfffffe001ec2a900, pri=92) >> at /usr/src/sys/kern/subr_sleepqueue.c:623 >> #3 0xffffffff808f3c69 in _sleep (ident=0xfffffe001ec2a900, >> lock=0xfffffe00371e9210, priority=Variable "priority" is not available. >> ) at /usr/src/sys/kern/kern_synch.c:250 >> #4 0xffffffff802bea02 in cam_sim_free (sim=0xfffffe001ec2a900, >> free_devq=1) at /usr/src/sys/cam/cam_sim.c:112 >> #5 0xffffffff8074f8ba in umass_detach (dev=Variable "dev" is not available. >> ) at /usr/src/sys/dev/usb/storage/umass.c:2183 >> #6 0xffffffff8091a054 in device_detach (dev=0xfffffe001ec2e900) at >> device_if.h:214 >> #7 0xffffffff8075c458 in usb_detach_device (udev=0xfffffe0007ce8800, >> iface_index=32 ' ', flag=Variable "flag" is not available. >> ) at /usr/src/sys/dev/usb/usb_device.c:1065 >> #8 0xffffffff8075c5f4 in usb_unconfigure (udev=0xfffffe0007ce8800, >> flag=Variable "flag" is not available. >> ) at /usr/src/sys/dev/usb/usb_device.c:455 >> #9 0xffffffff8075c88e in usb_free_device (udev=0xfffffe0007ce8800, >> flag=Variable "flag" is not available. >> ) at /usr/src/sys/dev/usb/usb_device.c:2093 >> #10 0xffffffff80764e5e in uhub_explore (udev=0xfffffe0007353800) at >> /usr/src/sys/dev/usb/usb_hub.c:358 >> #11 0xffffffff8074f536 in usb_bus_explore (pm=Variable "pm" is not >> available. >> ) at /usr/src/sys/dev/usb/controller/usb_controller.c:359 >> #12 0xffffffff80769173 in usb_process (arg=Variable "arg" is not available. >> ) at /usr/src/sys/dev/usb/usb_process.c:170 >> #13 0xffffffff808bc2df in fork_exit (callout=0xffffffff807690a0 >> , arg=0xffffff80007c0e88, frame=0xffffff804743cc40) at >> /usr/src/sys/kern/kern_fork.c:992 >> #14 0xffffffff80bc216e in fork_trampoline () at >> /usr/src/sys/amd64/amd64/exception.S:602 >> >> >> From: cam_sim_free(struct cam_sim *sim, int free_devq) >> >> (kgdb) l >> 107 { >> 108 int error; >> 109 >> 110 sim->refcount--; >> 111 if (sim->refcount > 0) { >> >> 112 error = msleep(sim, sim->mtx, PRIBIO, "simfree", 0); >> >> 113 KASSERT(error == 0, ("invalid error value for >> msleep(9)")); >> 114 } >> 115 >> 116 KASSERT(sim->refcount == 0, ("sim->refcount == 0")); >> >> >> It almost appears as if the cam layer is trying to finalise a write of >> some sort but the physical device has already gone. >> >> (kgdb) p sim->refcount >> $1 = 1 >> >> Not sure why refcount is still ==1. >> >> The same device in a box running 9.0-Stable (as of about 3 months ago) >> with a ICH9 controller works as expected. >> >> Any suggestions? > Do you happen to have 'camcontrol devlist -v' output for the above > scenario? > > I have attached a patch for the pass(4) driver that might help things > somewhat. The pass(4) driver won't go away completely if there is a > context that has the driver open when the underlying device goes away. > > That might be what is holding up the SIM refcount, although I'm not > certain. > > Ken Following up on a now very old thread. Whilst I didn't find a chance to test the given patch, I can confirm that this bug is fixed in 9.1-PRERELEASE. Cheers, Benjamin From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:02:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8742BD27; Fri, 28 Dec 2012 12:02:34 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by mx1.freebsd.org (Postfix) with ESMTP id DBC5D8FC0A; Fri, 28 Dec 2012 12:02:33 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id 15so4907514wgd.16 for ; Fri, 28 Dec 2012 04:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WGsELXJbBWI976biOvOGMPh6kqJ44aD8zrHcZT5NRec=; b=gYj84zYyDdpeVHyP9Gxl+Df84nv0YJS8N+T7Wc8tBrWMbMlFJHcdEu+1tIGu7bs4Qy cZ9n8KnFYnjpy2X1NTCKb3WqhHU97yHohGOKhF2+sqTHMEMHuPp+qLAbdEiqaSYsC7jE n51ZjLWoUJIQh8JNsT1U/m9DVkBWMRjphIBp9D2M8ttMZakCqTZl8yJPGBPmL5aBT+D7 rOBHtBclGlp/DUB073+Mns9WLp5XbaI4nG75AGulTEhKr6aVUXaD5rpYUkwZ7VW47SzV nb3G5knlJSDl7rKftf6v/hE1WKawOlZBFTLu4pK40lyoF1TlVnURgObK1HM0dcNzHUa8 EGHw== MIME-Version: 1.0 Received: by 10.180.93.133 with SMTP id cu5mr43986407wib.32.1356696147415; Fri, 28 Dec 2012 04:02:27 -0800 (PST) Received: by 10.216.172.197 with HTTP; Fri, 28 Dec 2012 04:02:27 -0800 (PST) In-Reply-To: References: <1356628066796-5772624.post@n5.nabble.com> Date: Fri, 28 Dec 2012 14:02:27 +0200 Message-ID: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel From: Kimmo Paasiala To: CeDeROM Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Jakub Lach , freebsd-ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 12:02:34 -0000 On Fri, Dec 28, 2012 at 1:51 PM, CeDeROM wrote: > On Fri, Dec 28, 2012 at 12:42 PM, Kimmo Paasiala wrote: >> You're misunderstanding a few things. There are no "release packages" >> for any release of FreeBSD. What you have on the install discs are >> just "snapshot" packages built from the ports tree as it happened (...) > > I know, I hoped 1.7.2 driver or 1.8.1 can get into a port tree before > packages for 9.1 are built and released. When I applied a patch (some > structure fields initialization) from 1.7.2 on current 1.7.1 driver > problem of detection and strange mouse behavior was gone. If 1.7.1 > gets into the packages lots of people will report this issue... thats > all. > > Best regards :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Related to this, It doesn't look like the FreeBSD ports SVN repository is used to its full potential. SVN allows branching and creation of experimental versions of the tree very easily and cheaply, yet all the experimental repositories references so far are stored in some external repositories, github or elsewhere. What gives? From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:08:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 513D7F79; Fri, 28 Dec 2012 12:08:20 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by mx1.freebsd.org (Postfix) with ESMTP id 90C378FC0A; Fri, 28 Dec 2012 12:08:19 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fk20so700524lab.36 for ; Fri, 28 Dec 2012 04:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jxZQZAyc5CE7PI97wt/ypgVcOUUrA/3Y9f9ormsp360=; b=DNEJ5BktEgSSsu5T+2G/D/dz9VhSwN4P0mRXYlhOqmXO5sSJa/TnpjLXp39hquxUlO 04AUIpNeAAvjv+jTlZ02nviFiH2bXcIaCkmqFO8HrbXmSW08+o5JflStr5pppxLpQ7bJ Wi8RQdTTLzMI3ZoUCZETOCZn6Po+ArMJX9ITCOzqTpyKw00wD1JO1wpF9n3B9b78AHaZ +s9cfoOi6LpikJ/Ce/iBor7UjUrP8xWxRqMXXlpxl7LKSFQ1RGg8G0+An7HaCsGkqgFJ sfnOBMLjcdueFYcZR9HsSZvOh9Os5h4QOlVe6mIhwPc0enj2h5GalwFqQtrtAd1DbsP0 YHWw== MIME-Version: 1.0 Received: by 10.152.105.103 with SMTP id gl7mr30691552lab.10.1356696496693; Fri, 28 Dec 2012 04:08:16 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.11.165 with HTTP; Fri, 28 Dec 2012 04:08:16 -0800 (PST) In-Reply-To: References: <1356628066796-5772624.post@n5.nabble.com> Date: Fri, 28 Dec 2012 13:08:16 +0100 X-Google-Sender-Auth: oesGRbd2GomeMxkheNwF2BJco40 Message-ID: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel From: CeDeROM To: Kimmo Paasiala Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Jakub Lach , freebsd-ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 12:08:20 -0000 On Fri, Dec 28, 2012 at 1:02 PM, Kimmo Paasiala wrote: > It doesn't look like the FreeBSD ports SVN repository is used to its > full potential. (...) Yea, btw why FreeBSD does not use GIT? I have been using it for some time and I have not seen better source code revision utility. GIT is really amazing, SVN/CVS seems to be a file revision control, while GIT is the source code revision control, this tool surprises me all the time with its great features :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:10:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64E121D6; Fri, 28 Dec 2012 12:10:54 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by mx1.freebsd.org (Postfix) with ESMTP id BD3E38FC14; Fri, 28 Dec 2012 12:10:53 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u3so4751603wey.2 for ; Fri, 28 Dec 2012 04:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hV+0Zc5dJuL1A9v9KxceMrn8IGhgTNLdXJHQhO6N3hc=; b=CshHMQQ+aFRxGgAzu7PNCZ/qsByV0Mg1T5BdoA6JmOMfw/IK96r3FT6kTWNQBe+oIL C5MZ5D24IuhetQQFKyq0oHjQZz00MVd9gRmtfNnPTXumTw1Hbd+33rpk2AQSewk137+r U+TLh0ZXYgHsT9wvWIskHaIcUV+Dpl0KRnkkbzMHSDR+RD+N9DswDWkMfw5LDKwv+U0a qe/RpYlNgzHjkROOgJoS5HDTxF1+MWhgZuEVqHG3q83c9e9eOt9DyFbqCN9aJlzRWXfz YhYhWDYGTHe9CiG/N4OlVJX0bRLIiOzHbx1PUXvspXTO3269gjUuJbBPPppMAC0BK3DR +O3A== MIME-Version: 1.0 Received: by 10.194.23.37 with SMTP id j5mr53282819wjf.28.1356696647091; Fri, 28 Dec 2012 04:10:47 -0800 (PST) Received: by 10.216.172.197 with HTTP; Fri, 28 Dec 2012 04:10:46 -0800 (PST) In-Reply-To: References: <1356628066796-5772624.post@n5.nabble.com> Date: Fri, 28 Dec 2012 14:10:46 +0200 Message-ID: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel From: Kimmo Paasiala To: CeDeROM Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Jakub Lach , freebsd-ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 12:10:54 -0000 On Fri, Dec 28, 2012 at 2:08 PM, CeDeROM wrote: > On Fri, Dec 28, 2012 at 1:02 PM, Kimmo Paasiala wrote: >> It doesn't look like the FreeBSD ports SVN repository is used to its >> full potential. (...) > > Yea, btw why FreeBSD does not use GIT? I have been using it for some > time and I have not seen better source code revision utility. GIT is > really amazing, SVN/CVS seems to be a file revision control, while GIT > is the source code revision control, this tool surprises me all the > time with its great features :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info I would personally use GIT but I'm ok with SVN too. I absolutely hate CVS :P My point is really that why not centralise all the development that happens around the ports tree. The infrastructure is there already. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:29:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16693507 for ; Fri, 28 Dec 2012 12:29:40 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id E09DD8FC0C for ; Fri, 28 Dec 2012 12:29:39 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1ToZ4F-00048D-Dd for freebsd-stable@freebsd.org; Fri, 28 Dec 2012 04:29:39 -0800 Date: Fri, 28 Dec 2012 04:29:39 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1356697779415-5772797.post@n5.nabble.com> In-Reply-To: References: <1356628066796-5772624.post@n5.nabble.com> Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 12:29:40 -0000 xorg trunk repo predates SVN for ports. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RC3-xorg-input-mouse-xfce4-panel-tp5772549p5772797.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 12:33:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6B27620 for ; Fri, 28 Dec 2012 12:33:10 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id BB4058FC12 for ; Fri, 28 Dec 2012 12:33:10 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1ToZ7e-0004Ic-9u for freebsd-stable@freebsd.org; Fri, 28 Dec 2012 04:33:10 -0800 Date: Fri, 28 Dec 2012 04:33:10 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1356697990297-5772798.post@n5.nabble.com> In-Reply-To: <1356697779415-5772797.post@n5.nabble.com> References: <1356628066796-5772624.post@n5.nabble.com> <1356697779415-5772797.post@n5.nabble.com> Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 12:33:11 -0000 http://wiki.freebsd.org/Git -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RC3-xorg-input-mouse-xfce4-panel-tp5772549p5772798.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 15:13:52 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22DBDD5A for ; Fri, 28 Dec 2012 15:13:52 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8728FC08 for ; Fri, 28 Dec 2012 15:13:50 +0000 (UTC) Received: (qmail 48810 invoked by uid 89); 28 Dec 2012 15:13:44 -0000 Received: by simscan 1.4.0 ppid: 48805, pid: 48807, t: 0.1341s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:16165 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 28 Dec 2012 15:13:43 -0000 Date: Fri, 28 Dec 2012 16:13:43 +0100 From: Rainer Duffner To: Garrett Wollman Subject: Re: Anothe pkgng question: signing a repository Message-ID: <20121228161343.059a6155@suse3> In-Reply-To: <201212272101.qBRL1hXP016548@hergotha.csail.mit.edu> References: <20121227162311$64db@grapevine.csail.mit.edu> <201212272101.qBRL1hXP016548@hergotha.csail.mit.edu> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 15:13:52 -0000 Am Thu, 27 Dec 2012 16:01:43 -0500 (EST) schrieb Garrett Wollman : > In article <20121227162311$64db@grapevine.csail.mit.edu>, > rainer@ultra-secure.de writes: > > >I'm creating my own repository and have created a key for it. > [...] > >What does pkg expect to be in this file? > > A public key. It does not use X.509 (nor is there any reason why it > should, although I suppose it could be made to at the cost of > significant added complexity and a bootstrapping problem). Ah, OK. When I hear "key", I sort of assume there must be a certificate and a CA involved. It works now ;-) Best Regards, Rainer From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 15:31:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47F47286 for ; Fri, 28 Dec 2012 15:31:32 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from mproxy7.sbb.rs (mproxy7.sbb.rs [89.216.2.97]) by mx1.freebsd.org (Postfix) with ESMTP id BCC368FC0A for ; Fri, 28 Dec 2012 15:31:31 +0000 (UTC) Received: from faust.localdomain (cable-178-148-102-129.dynamic.sbb.rs [178.148.102.129]) by mproxy7.sbb.rs (8.14.4/8.14.4) with ESMTP id qBSFKoIU008919; Fri, 28 Dec 2012 16:20:55 +0100 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at SBB mail Received: by faust.localdomain (Postfix, from userid 1001) id 77631A41E6A; Fri, 28 Dec 2012 16:19:00 +0100 (CET) Date: Fri, 28 Dec 2012 16:19:00 +0100 From: Zoran Kolic To: Mark Linimon Subject: Re: 9.1 minimal ram requirements Message-ID: <20121228151900.GA1327@faust.sbb.rs> References: <20121225151532.GA1404@faust.sbb.rs> <20121226170233.GA1408@faust.sbb.rs> <20121228022250.GA9064@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121228022250.GA9064@lonesome.com> X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy7.sbb.rs Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 15:31:32 -0000 > What you are seeing is behind-the-scenes preparation. > The release is official when, and only when, a security-signed email is > sent to freebsd-announce@FreeBSD.org from the Release Engineering team. Yeah, Mark. You're right. Further, I'm right too. What should I install on blank node? Beta? No beta on the site. RC1-3? No RC on the site. 9.0? I need kms at least on laptop. My simple question is: what is the file on the server? Please, no only-when, no wait-for-... I'm might be ignorant in many ways, but I expect freebsd site to content what it reads as a file name. So, do I have installed 9.1 on my desktop and laptop or some alien OS? Do I have to wait more and reinstall from the beginning, when official announcement comes? To be clear: freebsd is my only OS on computer for many years and I do not argue in any way. I just want to say that silence is not a good kind of communication. Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 17:28:50 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA64D84A for ; Fri, 28 Dec 2012 17:28:50 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 636DE8FC0C for ; Fri, 28 Dec 2012 17:28:50 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.6/8.14.5) with ESMTP id qBSHSjjA013260 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 28 Dec 2012 17:28:45 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.7.3 smtp.infracaninophile.co.uk qBSHSjjA013260 Authentication-Results: smtp.infracaninophile.co.uk/qBSHSjjA013260; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Message-ID: <50DDD6C6.3050606@FreeBSD.org> Date: Fri, 28 Dec 2012 17:28:38 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Wollman Subject: Re: Anothe pkgng question: signing a repository References: <201212272101.qBRL1hXP016548@hergotha.csail.mit.edu> In-Reply-To: <201212272101.qBRL1hXP016548@hergotha.csail.mit.edu> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB43379DFA8FF395CEF022909" X-Virus-Scanned: clamav-milter 0.97.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: stable@freebsd.org, rainer@ultra-secure.de X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 17:28:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB43379DFA8FF395CEF022909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27/12/2012 21:01, Garrett Wollman wrote: >> I'm creating my own repository and have created a key for it. > [...] >> >What does pkg expect to be in this file? > A public key. It does not use X.509 (nor is there any reason why it > should, although I suppose it could be made to at the cost of > significant added complexity and a bootstrapping problem). pkgng has a quite minimal signing setup -- it uses naked RSA public/private keys without committing to either of the two popular models for providing assurance on the validity of public keys (viz: PGP web of trust or X509 style certificate chains to some trusted root certificate). It's not clear at the moment if one or other or neither of those styles would be preferred in the future. Or it may well be the case that RFC6698 (DANE -- DNS-Based Authentication of Named Entities) via DNSSEC signed zone data[*] is preferred over either of the two means frequently used at the moment. Remember that there's really only one cryptographic signature needed for each architecture/OS version specific repository catalogue. So not a huge maintenance burden keeping the DNS up to date and signed even if a new repository catalogue is published each day. Cheers, Matthew [*] FreeBSD.org is not currently DNSSEC signed, so use of DANE will have to remain no more than a pipe-dream for the time being. --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigB43379DFA8FF395CEF022909 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDd1s0ACgkQ8Mjk52CukIzyzgCfaZh4H22FAy4VfZWUK4p4GaHK gTkAn3bAw4naA/+y32KEmoGaEG8tEde3 =pcPU -----END PGP SIGNATURE----- --------------enigB43379DFA8FF395CEF022909-- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 17:51:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2C02CB7 for ; Fri, 28 Dec 2012 17:51:27 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id BAB0E8FC0C for ; Fri, 28 Dec 2012 17:51:27 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 57E3156078; Fri, 28 Dec 2012 11:51:27 -0600 (CST) Date: Fri, 28 Dec 2012 11:51:27 -0600 From: Mark Linimon To: Zoran Kolic Subject: Re: 9.1 minimal ram requirements Message-ID: <20121228175127.GD5770@lonesome.com> References: <20121225151532.GA1404@faust.sbb.rs> <20121226170233.GA1408@faust.sbb.rs> <20121228022250.GA9064@lonesome.com> <20121228151900.GA1327@faust.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121228151900.GA1327@faust.sbb.rs> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 17:51:27 -0000 In an ideal world, the bits that will almost certainly become FreeBSD 9.1 would not appear on the masters, or any of the mirrors, until the same instant that the release announcement is set to freebsd-announce@FreeBSD.org. In practice this doesn't happen. If there is some clever way for that to happen, we haven't found it yet. It has happened in the past that even as the release bits were propogating, One Last Big Bug was found and those bits had to be pulled and re-done. It would have looked like you had FreeBSD Release X.Y but you wouldn't have had the final bits that everyone else did. I understand your frustration that this process takes days, and in general the frustration with this particular release -- more than you could possibly believe. However, until we figure out the process that would exist in an ideal world, this is what we have, and so if you need something that will be in 9.1, your options at this moment are: build an install from 9-STABLE; find one of the snapshots (and no, I am not the one to ask, sorry); or wait. Sorry, but that's the best I can offer right now. mcl From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 18:06:27 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6F97F36; Fri, 28 Dec 2012 18:06:27 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF618FC08; Fri, 28 Dec 2012 18:06:26 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id d17so5215378eek.11 for ; Fri, 28 Dec 2012 10:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=34DE1JQiJROgznRIRGy9KTEZoI1Wx7LeRvq9HZW8iOU=; b=ycP/E4ob8AvhCmbgiW0FUCEphSbUA1m52Es9d1UIfyc+a+UkMmg3reWYow+70Q2kVv PVzgw2yLK9QGfyIU1YsStWLQbbzo9izyMGzI9pXF2H9KLq1DqAvPv3yyOqpl1mL8CJDj cnpx05cUEKwk34qhaJB3RKw/kqIGCm9N4bsi1nvKF/s+pAE6pXFGNMffc87rZ44QOw0X Co1Ty7IG7LVsxx6bFVGgEsgB/a/co5OlsY5AFm/BYew8ZyBUvKMQ0Fnr30Y+t8j4qioC DKhq58xuPOnQ/lPUtg02BZjf3k1TtauRovXVQ24NKwha14A+DU6z79o9+GNNOrOgJbgx F2Tg== MIME-Version: 1.0 Received: by 10.14.2.196 with SMTP id 44mr87968638eef.25.1356717980025; Fri, 28 Dec 2012 10:06:20 -0800 (PST) Received: by 10.223.170.193 with HTTP; Fri, 28 Dec 2012 10:06:19 -0800 (PST) In-Reply-To: <50DDD6C6.3050606@FreeBSD.org> References: <201212272101.qBRL1hXP016548@hergotha.csail.mit.edu> <50DDD6C6.3050606@FreeBSD.org> Date: Fri, 28 Dec 2012 10:06:19 -0800 Message-ID: Subject: Re: Anothe pkgng question: signing a repository From: Kevin Oberman To: Matthew Seaman Content-Type: text/plain; charset=UTF-8 Cc: stable@freebsd.org, Garrett Wollman , rainer@ultra-secure.de X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 18:06:27 -0000 On Fri, Dec 28, 2012 at 9:28 AM, Matthew Seaman wrote: > On 27/12/2012 21:01, Garrett Wollman wrote: >>> I'm creating my own repository and have created a key for it. >> [...] >>> >What does pkg expect to be in this file? > >> A public key. It does not use X.509 (nor is there any reason why it >> should, although I suppose it could be made to at the cost of >> significant added complexity and a bootstrapping problem). > > pkgng has a quite minimal signing setup -- it uses naked RSA > public/private keys without committing to either of the two popular > models for providing assurance on the validity of public keys (viz: PGP > web of trust or X509 style certificate chains to some trusted root > certificate). It's not clear at the moment if one or other or neither > of those styles would be preferred in the future. > > Or it may well be the case that RFC6698 (DANE -- DNS-Based > Authentication of Named Entities) via DNSSEC signed zone data[*] is > preferred over either of the two means frequently used at the moment. > Remember that there's really only one cryptographic signature needed for > each architecture/OS version specific repository catalogue. So not a > huge maintenance burden keeping the DNS up to date and signed even if a > new repository catalogue is published each day. > > Cheers, > > Matthew > > [*] FreeBSD.org is not currently DNSSEC signed, so use of DANE will have > to remain no more than a pipe-dream for the time being. So why not? BIND 9.9 makes signing pretty easy and many registrars support it, though not all do. I think Tucows does, though I don't use them, so I might be wrong. With all of the concern over security after the intrusion, this seems like a good time to get started with signing. (Yes, I know everyone is really tied up with auditing things, but if it keeps getting delayed, ti will not happen.) And, yes, DANE is clearly preferable to either PGP (#2 choice, IMHO) or X.509 (too broken to be worth considering). -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 20:46:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96530CD0 for ; Fri, 28 Dec 2012 20:46:03 +0000 (UTC) (envelope-from greg.bonett@gmail.com) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by mx1.freebsd.org (Postfix) with ESMTP id 439088FC0A for ; Fri, 28 Dec 2012 20:46:03 +0000 (UTC) Received: by mail-vb0-f48.google.com with SMTP id fc21so10928255vbb.7 for ; Fri, 28 Dec 2012 12:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3FDT5TNEFSNrRH2CiTjbwN4pb2GbE1pmBj2KvZedef4=; b=u+rs5xGgAS3vGwqg3omVmrQBA5PO6BLNvCPS+qC18lifgZl6tOaJC7D0vhjY3+tL+n IxEReZCWro75JUKLm/7ofFvPYpLNXupdfx32j8q1EjB3Y90pDht/V7m3rT2H2yLoyoKE K7SsvSN+K6H1FxCFP9RpTvV8tQ9xKh3VjIEmpLIVHbSWN5LsVb3jo2MMBIMhzgT6eByX A8iChZsccvUi9ODZJBU4SZz5jl318VsvcsEue5fjnvKufo2qEmIjf1Hiz3nJVZgAC/UJ mX6q/tRZ9VGsclAEAAwPf47qIoD9XclhyGWckfrxYpGXC2SfKHUizNYKydmOYMofilL+ UFDw== MIME-Version: 1.0 Received: by 10.220.115.19 with SMTP id g19mr53099322vcq.69.1356727562478; Fri, 28 Dec 2012 12:46:02 -0800 (PST) Received: by 10.58.40.33 with HTTP; Fri, 28 Dec 2012 12:46:02 -0800 (PST) Date: Fri, 28 Dec 2012 20:46:02 +0000 Message-ID: Subject: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick From: Greg Bonett To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 20:46:03 -0000 Many months ago, I believe some *very bad hardware* caused corruption of a file on one of my zfs file systems. I've isolated the corrupted file and can reliably induce a kernel panic with "touch bad.file", "rm bad.file", or "ls -l" in the bad.file's directory (ls in bad.file's dir doesn't cause panic, but "ls bad.file" does). This is a raidz zpool, but zpool scrub doesn't fix it - it eventually creates a kernel panic. My next plan is to attempt to get rid of this file by zfs destroy(ing) the entire filesystem. The corrupted file is on /tank, and I've copied all of the good data onto a new zfs file system, /tank/tempfs/. However, I can't figure out how to destroy the /tank filesystem without destroying /tank/tempfs (and the other /tank children). Is it possible to destroy a parent without destroying the children? Or, create a new parent zfs file system on the same zpool and move the /tank children there before destroying /tank? /tank and it's children are about 4.2 TB and I don't have the disk space readily available to copy the whole thing (but I can get the space if it's the only way to do this). Thanks in advance for the help. --Greg system info: FreeBSD 9.1-PRERELEASE #1 r243694 amd64 16GB ram 'zpool upgrade' gives: This system supports ZFS pool feature flags. All pools are formatted using feature flags. Every feature flags pool has all supported features enabled. 'zfs upgrade' gives: This system is currently running ZFS filesystem version 5. All filesystems are formatted with the current version. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 28 21:37:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8163DEFD; Fri, 28 Dec 2012 21:37:08 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 21C528FC0A; Fri, 28 Dec 2012 21:37:07 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 04DDD5C3A0; Fri, 28 Dec 2012 22:37:01 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id s91mKSocLEi5; Fri, 28 Dec 2012 22:36:59 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id C6BCD5C39D; Fri, 28 Dec 2012 22:36:59 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 09FEA5083F; Fri, 28 Dec 2012 22:36:58 +0100 (CET) Message-ID: <50DE10FA.30102@incore.de> Date: Fri, 28 Dec 2012 22:36:58 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup References: <50DC30F6.1050904@incore.de> <20121227133355.GI82219@kib.kiev.ua> <50DC8999.8000708@incore.de> <20121227194145.GM82219@kib.kiev.ua> <50DD6423.5090305@incore.de> <20121228112724.GR82219@kib.kiev.ua> In-Reply-To: <20121228112724.GR82219@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: pho@freebsd.org, freebsd-stable@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Dec 2012 21:37:08 -0000 Konstantin Belousov wrote: > > Please try the following patch. It is against HEAD, might need some > adjustments for 8. I do the resume and write accounting atomically, > not allowing other suspension to intervent between. > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index 3f65b05..cf49ecb 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -1434,6 +1434,40 @@ vn_closefile(fp, td) > * proceed. If a suspend request is in progress, we wait until the > * suspension is over, and then proceed. > */ > +static int > +vn_start_write_locked(struct mount *mp, int flags) > +{ > + int error; > + > + mtx_assert(MNT_MTX(mp), MA_OWNED); > + error = 0; > + > + /* > + * Check on status of suspension. > + */ > + if ((curthread->td_pflags & TDP_IGNSUSP) == 0 || > + mp->mnt_susp_owner != curthread) { > + while ((mp->mnt_kern_flag & MNTK_SUSPEND) != 0) { > + if (flags & V_NOWAIT) { > + error = EWOULDBLOCK; > + goto unlock; > + } > + error = msleep(&mp->mnt_flag, MNT_MTX(mp), > + (PUSER - 1) | (flags & PCATCH), "suspfs", 0); > + if (error) > + goto unlock; > + } > + } > + if (flags & V_XSLEEP) > + goto unlock; > + mp->mnt_writeopcount++; > +unlock: > + if (error != 0 || (flags & V_XSLEEP) != 0) > + MNT_REL(mp); > + MNT_IUNLOCK(mp); > + return (error); > +} > + > int > vn_start_write(vp, mpp, flags) > struct vnode *vp; > @@ -1470,30 +1504,7 @@ vn_start_write(vp, mpp, flags) > if (vp == NULL) > MNT_REF(mp); > > - /* > - * Check on status of suspension. > - */ > - if ((curthread->td_pflags & TDP_IGNSUSP) == 0 || > - mp->mnt_susp_owner != curthread) { > - while ((mp->mnt_kern_flag & MNTK_SUSPEND) != 0) { > - if (flags & V_NOWAIT) { > - error = EWOULDBLOCK; > - goto unlock; > - } > - error = msleep(&mp->mnt_flag, MNT_MTX(mp), > - (PUSER - 1) | (flags & PCATCH), "suspfs", 0); > - if (error) > - goto unlock; > - } > - } > - if (flags & V_XSLEEP) > - goto unlock; > - mp->mnt_writeopcount++; > -unlock: > - if (error != 0 || (flags & V_XSLEEP) != 0) > - MNT_REL(mp); > - MNT_IUNLOCK(mp); > - return (error); > + return (vn_start_write_locked(mp, flags)); > } > > /* > @@ -1639,8 +1650,7 @@ vfs_write_suspend(mp) > * Request a filesystem to resume write operations. > */ > void > -vfs_write_resume(mp) > - struct mount *mp; > +vfs_write_resume_flags(struct mount *mp, int flags) > { > > MNT_ILOCK(mp); > @@ -1652,10 +1662,25 @@ vfs_write_resume(mp) > wakeup(&mp->mnt_writeopcount); > wakeup(&mp->mnt_flag); > curthread->td_pflags &= ~TDP_IGNSUSP; > + if ((flags & VR_START_WRITE) != 0) { > + MNT_REF(mp); > + mp->mnt_writeopcount++; > + } > MNT_IUNLOCK(mp); > VFS_SUSP_CLEAN(mp); > - } else > + } else if ((flags & VR_START_WRITE) != 0) { > + MNT_REF(mp); > + vn_start_write_locked(mp, 0); > + } else { > MNT_IUNLOCK(mp); > + } > +} > + > +void > +vfs_write_resume(struct mount *mp) > +{ > + > + vfs_write_resume_flags(mp, 0); > } > > /* > diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h > index 42f9e5f..4371b40 100644 > --- a/sys/sys/vnode.h > +++ b/sys/sys/vnode.h > @@ -392,6 +392,8 @@ extern int vttoif_tab[]; > #define V_NOWAIT 0x0002 /* vn_start_write: don't sleep for suspend */ > #define V_XSLEEP 0x0004 /* vn_start_write: just return after sleep */ > > +#define VR_START_WRITE 0x0001 /* vfs_write_resume: start write atomically */ > + > #define VREF(vp) vref(vp) > > #ifdef DIAGNOSTIC > @@ -701,6 +703,7 @@ int vn_io_fault_uiomove(char *data, int xfersize, struct uio *uio); > int vfs_cache_lookup(struct vop_lookup_args *ap); > void vfs_timestamp(struct timespec *); > void vfs_write_resume(struct mount *mp); > +void vfs_write_resume_flags(struct mount *mp, int flags); > int vfs_write_suspend(struct mount *mp); > int vop_stdbmap(struct vop_bmap_args *); > int vop_stdfsync(struct vop_fsync_args *); > diff --git a/sys/ufs/ffs/ffs_snapshot.c b/sys/ufs/ffs/ffs_snapshot.c > index e528509..25ad79c 100644 > --- a/sys/ufs/ffs/ffs_snapshot.c > +++ b/sys/ufs/ffs/ffs_snapshot.c > @@ -687,8 +687,7 @@ out1: > /* > * Resume operation on filesystem. > */ > - vfs_write_resume(vp->v_mount); > - vn_start_write(NULL, &wrtmp, V_WAIT); > + vfs_write_resume_flags(vp->v_mount, VR_START_WRITE); > if (collectsnapstats && starttime.tv_sec > 0) { > nanotime(&endtime); > timespecsub(&endtime, &starttime); Your patch adjusted to FreeBSD Stable 8 works fine. Creating a snapshot every minute runs without errors for more than 6 hours now, without the patch my test machine hangs not later than one hour. -- Andreas Longwitz From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 03:35:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6037CA78 for ; Sat, 29 Dec 2012 03:35:18 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by mx1.freebsd.org (Postfix) with ESMTP id C2C288FC0C for ; Sat, 29 Dec 2012 03:35:17 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id ep20so1695129lab.18 for ; Fri, 28 Dec 2012 19:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=T533R3nMUYf5tVJGZwklvMTj2++kiXCU0jNmwkQE4j4=; b=USZS5GtyOL/1j8YQrdo5yWmquIZruglaNa6N77YdIQz5zA2trge8SBMKLhvGefka2B f1reIzEwMR29BBQsHFREUPm4v3C0mjPrEsnoJMe9pDNRaQRvJtN5BeRN//3QlMTk470W cocEVHbvLRVK6vtqiJc6Wn920PoLaciKm06uol5/j4eafK1H+sIqDTaSk+oIqGKF/GBU NMhd0fNaiBYeLePriWIqObjFNLjCR1dxWhAynbaI0FDYzqsTUioxNrKV5o+fd+tW6Opp JJvJHvZG6i7RvoFXGtMcapBaFZshGvc9fuytUphsTHzhzvsg25t6IyM3zJaM2Esq04qW 4/Kw== MIME-Version: 1.0 Received: by 10.112.23.234 with SMTP id p10mr14413169lbf.35.1356752116305; Fri, 28 Dec 2012 19:35:16 -0800 (PST) Sender: artemb@gmail.com Received: by 10.112.80.103 with HTTP; Fri, 28 Dec 2012 19:35:16 -0800 (PST) In-Reply-To: References: Date: Fri, 28 Dec 2012 19:35:16 -0800 X-Google-Sender-Auth: HlyCRPGOe87meoa4J1d04UQ1nPk Message-ID: Subject: Re: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick From: Artem Belevich To: Greg Bonett Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 03:35:18 -0000 On Fri, Dec 28, 2012 at 12:46 PM, Greg Bonett wrote: > However, I can't figure out how to destroy the /tank filesystem without > destroying /tank/tempfs (and the other /tank children). Is it possible to > destroy a parent without destroying the children? Or, create a new parent > zfs file system on the same zpool and move the /tank children there before > destroying /tank? > It is possible in case parent is not the top-most zfs filesystem (i.e tomp-most filesystem for the pool). I.e. if your zfs filesystem layout looked like zfs-pool/tank/tempfs, then you could simply do "zfs rename zfs-pool/tank/tempfs zfs-pool/tempfs" and then would be free to remove zfs-pool/tank. Alas this rename semantics breaks down when you can no longer rename sub-filesystem upward. I don't think ZFS would allow you to promote inner filesystem to a pool which is what you seem to want. --Artem From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 03:48:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E402BAE; Sat, 29 Dec 2012 03:48:10 +0000 (UTC) (envelope-from greg.bonett@gmail.com) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by mx1.freebsd.org (Postfix) with ESMTP id 789F48FC08; Sat, 29 Dec 2012 03:48:09 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id gb30so11236320vcb.40 for ; Fri, 28 Dec 2012 19:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ncjkxSAoOt2LrvynKH4eygO1vt7B50JQ9Knqs+YI06A=; b=paDCMMnwEP6eu/+tj9yGw0us8XQTZoskNPJ4iAv8/yYaT4itq43AofkGnFRoFgRvB8 8y6KrMLCvCWDVge18fH7hFrgEsVeR0tuYHHcLgBt4rHIjpuERjfN8FZ9Mg3btJGNcAgB UB6+0bN2EUkfeAc+pzmfxo2LgciKXcLLlmXx3WuN4uhq6trjyHofPeRVZgndq70HXtNu cCyxjiDSwK2WKBu9o4yAbG1M4TewKDg/Z7G47L8i3dxRWoa+7lcpgUyNGv3cLY2FcyO/ 8nRo7KhfeHI7BrPD9W8g6F+ZWk9eNCxHdnjTraHiau5vzfReud0LH7cXZHn8++ymijyO SwYw== MIME-Version: 1.0 Received: by 10.220.106.147 with SMTP id x19mr54354908vco.37.1356752882722; Fri, 28 Dec 2012 19:48:02 -0800 (PST) Received: by 10.58.40.33 with HTTP; Fri, 28 Dec 2012 19:48:02 -0800 (PST) In-Reply-To: References: Date: Sat, 29 Dec 2012 03:48:02 +0000 Message-ID: Subject: Re: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick From: Greg Bonett To: Artem Belevich Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 03:48:10 -0000 ahh, unfortunately the filesystem I want to destroy is the top-most file system for the pool. Does this mean I'll need to set up another pool with enough free space to move everything over? Any ideas for a way to remove the corrupted file without destroying the file system? thanks! On Sat, Dec 29, 2012 at 3:35 AM, Artem Belevich wrote: > > On Fri, Dec 28, 2012 at 12:46 PM, Greg Bonett wrote: > >> However, I can't figure out how to destroy the /tank filesystem without >> destroying /tank/tempfs (and the other /tank children). Is it possible to >> destroy a parent without destroying the children? Or, create a new parent >> zfs file system on the same zpool and move the /tank children there before >> destroying /tank? >> > > It is possible in case parent is not the top-most zfs filesystem (i.e > tomp-most filesystem for the pool). > > I.e. if your zfs filesystem layout looked like zfs-pool/tank/tempfs, then > you could simply do "zfs rename zfs-pool/tank/tempfs zfs-pool/tempfs" and > then would be free to remove zfs-pool/tank. Alas this rename semantics > breaks down when you can no longer rename sub-filesystem upward. I don't > think ZFS would allow you to promote inner filesystem to a pool which is > what you seem to want. > > --Artem > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 04:49:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE34D7EC for ; Sat, 29 Dec 2012 04:49:16 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from mproxy8.sbb.rs (mproxy8.sbb.rs [89.216.2.98]) by mx1.freebsd.org (Postfix) with ESMTP id 310AC8FC0A for ; Sat, 29 Dec 2012 04:49:15 +0000 (UTC) Received: from mycenae.localdomain (cable-178-148-96-34.dynamic.sbb.rs [178.148.96.34]) by mproxy8.sbb.rs (8.14.4/8.14.4) with ESMTP id qBT4n1eo013892; Sat, 29 Dec 2012 05:49:06 +0100 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at SBB mail Received: by mycenae.localdomain (Postfix, from userid 1001) id CE9B7301BC; Sat, 29 Dec 2012 05:46:27 +0100 (CET) Date: Sat, 29 Dec 2012 05:46:27 +0100 From: Zoran Kolic To: Mark Linimon Subject: Re: 9.1 minimal ram requirements Message-ID: <20121229044627.GA963@mycenae.sbb.rs> References: <20121225151532.GA1404@faust.sbb.rs> <20121226170233.GA1408@faust.sbb.rs> <20121228022250.GA9064@lonesome.com> <20121228151900.GA1327@faust.sbb.rs> <20121228175127.GD5770@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121228175127.GD5770@lonesome.com> X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy8.sbb.rs Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 04:49:16 -0000 > It has happened in the past that even as the release bits were propogating, > One Last Big Bug was found and those bits had to be pulled and re-done. It > would have looked like you had FreeBSD Release X.Y but you wouldn't have had > the final bits that everyone else did. I'm aware of this. I simply did not have alternative. > I understand your frustration that this process takes days, and in general > the frustration with this particular release -- more than you could possibly > believe. However, until we figure out the process that would exist in an > ideal world, this is what we have, and so if you need something that will be > in 9.1, your options at this moment are: build an install from 9-STABLE; find > one of the snapshots (and no, I am not the one to ask, sorry); or wait. I'm not fond of one-size fits all principle. If an image is correct, I'll stick with it, till next treshold. At the moment, I fill relaxed, since both systems work as the best machines I had in my life. As I stated before, I could stand bugs and do not expect "perfect" system anytime. Freebsd suits me. If I have a problem, I wait or go around, or forget the issue. My bad was that release problem sinchronized with my power surge issue. At any other time, I'd be patient and you'd never hear of me. > Sorry, but that's the best I can offer right now. Wrong. You made psychological thing and I could be not worried about state of OS. If this image differs from the final one, I do not care, if they are the same in parts that matter to me. I will upgrade at the next . Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 06:47:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E86071A9; Sat, 29 Dec 2012 06:47:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4ABEF8FC15; Sat, 29 Dec 2012 06:47:08 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id z2so5149113wey.18 for ; Fri, 28 Dec 2012 22:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z/uiZLsEYdeFYn4MXIllykM0LV4WpLNvzfG+twzzlxg=; b=W5fnD+0MIdfcDf3GBKicFBwSgtyafiyAcuR6Lx8Cq80R5LDXhd/BTVq/qfQ4p/ojUS nAj5TqjO7oLHPMVbiMPgI6QVrtJUirv8m1z9c2hcDVLxX+uT0wEyefDu2TMzi6aYjj+v 02/knNwyFfP9B3hi/k32esdtvS2Y3sKECPaiDngGq10oROhnbApgOV0q58ymekTl7zzS GJgftIomI+hMG6kFcR9KNEFUfRcsXrTspvWQCYX2kXSOLtpT5x+OyXqMrvi4Mht7OYVn vcJpPM9wRHEnYCz/zkEtXZ82cStbep0IWID6oKXgC4q+Lb7Dj9yqRKsOC9cT2u47uRez 4VYQ== MIME-Version: 1.0 Received: by 10.194.83.36 with SMTP id n4mr56646980wjy.59.1356763627982; Fri, 28 Dec 2012 22:47:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 28 Dec 2012 22:47:07 -0800 (PST) In-Reply-To: References: <1356628066796-5772624.post@n5.nabble.com> Date: Fri, 28 Dec 2012 22:47:07 -0800 X-Google-Sender-Auth: nAogkKbSorlp3p8aYWOvzkaqzjg Message-ID: Subject: Re: 9.1-RC3: xorg-input-mouse, xfce4-panel From: Adrian Chadd To: Kimmo Paasiala Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Jakub Lach , freebsd-ports , CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 06:47:10 -0000 On 28 December 2012 04:02, Kimmo Paasiala wrote: > It doesn't look like the FreeBSD ports SVN repository is used to its > full potential. SVN allows branching and creation of experimental > versions of the tree very easily and cheaply, yet all the experimental > repositories references so far are stored in some external > repositories, github or elsewhere. > > What gives? Because then people who wish to create experimental branches of a rather large ports SVN tree would end up populating the core SVN repo, which is reproduced on mirrors (both ours and whoever else wishes to mirror the SVN repository.) So the current method in src/ is to work out hacks in local mirrors of the repository (eg via svn -> git gateways) and then when it's time to start some public work - create a branch, do the hacking, merge it into HEAD when it's ready. That way it can also be worked on by non-FreeBSD contributors. Just like what people do for Linux, who don't have kernel.org accounts. I won't speak for the ports people but just keep that in mind. There's sometimes larger scale issues abound. :-) And before you say "but but but but but but git!" please keep in mind that there's no such thing as a central GIT repository that _everyone_ dumps their work in, like what would happen if one created an SVN branch for projects (in src, ports, doc, etc.) Everyone has their own git repository forks and they push patches to "more authoritative" trees over time. Adrian From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 07:47:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F96EAC9 for ; Sat, 29 Dec 2012 07:47:05 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) by mx1.freebsd.org (Postfix) with ESMTP id F22478FC08 for ; Sat, 29 Dec 2012 07:47:04 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id y25so9185262iay.5 for ; Fri, 28 Dec 2012 23:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y7Va5j9s6VVrth/jvEd9h+mllXoMXEesgHx8aXiugBE=; b=r6wvVOza026Qc39oKSAOklpj56WI7NCgNgL2r0AH3TSCwuoSGieAZ90rWm9Fr0LIk0 sj5l405Kf/mfG7ZhX/jxAhOF2bk1ijJuXunabxyAO+p8LUbFeROjY/Kbp6xNOivp6se1 E1RLnaOxORrcuL+jfStbzXjIJ05aXxWvB38zyCeH9w/AL2Mm4QtSkNLVNZEVfWsGdwvV bEpIYs+tMgD4CZ/Hpufjat0T0+1OEtCpobBe6SKgoMT1FQ9Tz2UgCRM4SNFsY0jCXeHL upU3fqD007BTJtajgCUWOuEln0D7DNq6D+Wwemm5GLce7C9XgP6d9fCqeTlcidTULOZC 4fdg== MIME-Version: 1.0 Received: by 10.50.91.168 with SMTP id cf8mr32015247igb.20.1356767218344; Fri, 28 Dec 2012 23:46:58 -0800 (PST) Received: by 10.50.192.167 with HTTP; Fri, 28 Dec 2012 23:46:58 -0800 (PST) In-Reply-To: References: Date: Sat, 29 Dec 2012 01:46:58 -0600 Message-ID: Subject: Re: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick From: Scot Hetzel To: Greg Bonett Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 07:47:05 -0000 On Fri, Dec 28, 2012 at 2:46 PM, Greg Bonett wrote: > Many months ago, I believe some *very bad hardware* caused corruption of a > file on one of my zfs file systems. I've isolated the corrupted file and > can reliably induce a kernel panic with "touch bad.file", "rm bad.file", or > "ls -l" in the bad.file's directory (ls in bad.file's dir doesn't cause > panic, but "ls bad.file" does). > Does: cat /dev/null > bad.file Cause a kernel panic? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 08:35:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 853CBF4A for ; Sat, 29 Dec 2012 08:35:11 +0000 (UTC) (envelope-from greg.bonett@gmail.com) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by mx1.freebsd.org (Postfix) with ESMTP id 266EB8FC0C for ; Sat, 29 Dec 2012 08:35:10 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id fr13so11330986vbb.23 for ; Sat, 29 Dec 2012 00:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0kdEmmMvPk3gjTdk6pl/9wz7xv9X14qM/6GfHVtgtWo=; b=vrsqgHOnEVBe9/O+KHwDHWgNjpWb89D85GGkMr5g1HFpZxopSJPJyaxQE/KdJSaaSV Iku7pLKwXd4/8yVSzZbcTgEgeffdhGOiHcpfX9MNqI9uH5Bfml3YhKFX/lSoznhb1Nm0 7fFdbkBb2XiuIFzgs/Ztk9uRaGXZ7+cpAVmZTtUC/FtqIP3Svqzc09Y61XIzjLjjgZ8u syGRqLBB6wdeosvTRmgcU03gnQ+UUxFGVtX2bV4MkHpjgwGHCCfKu58BxNc6B/a354x/ K4KGAlcTStK/9EnAw5UY9oGCeZggxfIFwS9/bJlf2yBpehpP+AKvoavrncnoEOXdhqa9 cXxg== MIME-Version: 1.0 Received: by 10.220.115.19 with SMTP id g19mr54835557vcq.69.1356770110193; Sat, 29 Dec 2012 00:35:10 -0800 (PST) Received: by 10.58.40.33 with HTTP; Sat, 29 Dec 2012 00:35:10 -0800 (PST) In-Reply-To: References: Date: Sat, 29 Dec 2012 08:35:10 +0000 Message-ID: Subject: Re: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick From: Greg Bonett To: Scot Hetzel Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 08:35:11 -0000 > > Does: > > cat /dev/null > bad.file > > Cause a kernel panic? > > > ah, sadly that does cause a kernel panic. I hadn't tried it though, thanks for the suggestion. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 11:46:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AD5D3B0 for ; Sat, 29 Dec 2012 11:46:47 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp2.insight.synacor.com [208.47.185.24]) by mx1.freebsd.org (Postfix) with ESMTP id E8C7F8FC0A for ; Sat, 29 Dec 2012 11:46:46 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=Z4Vu7QtA c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=mLk7NxnQG0AA:10 a=-FGs326eAAAA:8 a=6I5d2MoRAAAA:8 a=kurQqiNWJuq-8Ku42RMA:9 a=0Rv9XxPPRogA:10 a=SV7veod9ZcQA:10 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp02.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp02.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:57506] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 87/5C-07640-028DED05; Sat, 29 Dec 2012 06:46:40 -0500 Date: Sat, 29 Dec 2012 06:46:40 -0500 Message-ID: <87.5C.07640.028DED05@smtp02.insight.synacor.com> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: 9.1 minimal ram requirements Cc: Mark Linimon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 11:46:47 -0000 from Mark Linimon : > In an ideal world, the bits that will almost certainly become FreeBSD 9.1 > would not appear on the masters, or any of the mirrors, until the same > instant that the release announcement is set to freebsd-announce@FreeBSD.org. > In practice this doesn't happen. If there is some clever way for that to > happen, we haven't found it yet. > It has happened in the past that even as the release bits were propogating, > One Last Big Bug was found and those bits had to be pulled and re-done. It > would have looked like you had FreeBSD Release X.Y but you wouldn't have had > the final bits that everyone else did. > I understand your frustration that this process takes days, and in general > the frustration with this particular release -- more than you could possibly > believe. However, until we figure out the process that would exist in an > ideal world, this is what we have, and so if you need something that will be > in 9.1, your options at this moment are: build an install from 9-STABLE; find > one of the snapshots (and no, I am not the one to ask, sorry); or wait. > Sorry, but that's the best I can offer right now. > mcl So that's why I downloaded-updated source tree using svn, built and installed, and uname -a revealed 9.1-PRERELEASE. It seemed strange after 9.1-RELEASE became available on FTP servers December 5. Maybe they can do something to better document "device ctl" in GENERIC; I kept it because it was there, and one is led to think it is needed due to changes in FreeBSD. Tom From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 11:53:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09E25504 for ; Sat, 29 Dec 2012 11:53:47 +0000 (UTC) (envelope-from lists@internecto.net) Received: from mx1.internecto.net (polaris.internecto.net [176.9.245.29]) by mx1.freebsd.org (Postfix) with ESMTP id AE4CB8FC08 for ; Sat, 29 Dec 2012 11:53:46 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id E4EDA340003 for ; Sat, 29 Dec 2012 11:53:38 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.internecto.net Received: from mx1.internecto.net ([127.0.0.1]) by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeAIwnmdxiwg for ; Sat, 29 Dec 2012 11:53:37 +0000 (UTC) Received: from [192.168.2.10] (unknown [172.17.37.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lists@internecto.net) by mx1.internecto.net (Postfix) with ESMTPSA id 9B5B6340002 for ; Sat, 29 Dec 2012 11:53:37 +0000 (UTC) Message-ID: <50DED9BA.1000400@internecto.net> Date: Sat, 29 Dec 2012 12:53:30 +0100 From: Mark van Dijk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: FreeBSD 9 (amd64) buildworld stage 4.2 fails with clang: unknown target cpu i686 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 11:53:47 -0000 Hello everyone, I'm running FreeBSD 9.1-PRERELEASE and today I synchronised my /usr/src directory with the svn_stable_9 branch on gitorious [1]. I am using ccache. My /etc/make.conf contains the following: -------------------------8<------------------------- CPUTYPE?=native CFLAGS=-O3 -pipe COPTFLAGS=-O -fno-strict-aliasing -pipe MAKE_JOBS_NUMBER=4 CC=clang CXX=clang++ CPP=clang-cpp NO_WERROR= WERROR= MAKE_SHELL?=sh INSTALL=install -C # from ccache-howto-freebsd.txt .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) .if !defined(NOCCACHE) CC:=${CC:C,^clang,/usr/local/libexec/ccache/world/clang,1} CXX:=${CXX:C,^clang\+\+,/usr/local/libexec/ccache/world/clang++,1} CCACHE_DIR:=/usr/sysccache .endif .endif .if ${CC:T} == "clang" CFLAGS+= -Qunused-arguments .endif -------------------------8<------------------------- The output from make is too long to post inline so you can find the relevant portion here: http://sprunge.us/BfWJ I suspect that the error is caused by -march=native, my CPU is an Intel Core i5. I'll admit that I did modify my make.conf right before building. It already *did* contain the CC/CXX/CPP lines for clang but the ccache portion was slightly different. It used to contain the literal contents of ccache-howto-freebsd.txt: CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} Today I re-read that howto and it states: "You can replace cc and c++ with the compilers of your choice. (remember that only GCC and Clang can build world and kernel)" So I updated those two lines and replaced cc/c++ with clang/clang++. I didn't get the make errors before. So I moved those two lines back, did rm -rf /usr/obj/* and started another make buildworld which is still running. I always thought that specifying 'CPUTYPE?=' in the Makefile is the right way to prevent issues like this. So did I do something wrong, or is this some kind of ccache issue, or is this a legitimate bug? Please shed some light on this, thanks. Mark van Dijk the Netherlands [1] git://gitorious.org/freebsd/freebsd.git From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 11:59:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7998167E for ; Sat, 29 Dec 2012 11:59:47 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 09DFF8FC12 for ; Sat, 29 Dec 2012 11:59:46 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so4557534wgb.5 for ; Sat, 29 Dec 2012 03:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5cDa8cjVsja4xFoN/9RcSMRzRyrwVOilivIWiYkYnx8=; b=ULs+J3+qQ+eC/6s3qEqhlqgLR1BtA8+HA64iXvNlRl2mHGblcCrEfQXHKEAwy0q1Tb /uBRVZO7AxWFbkF5+nHbfZ8h/0g3tK8fOtz5A4JYcYe93mP0H8q4Mg8G7djKYDL0gsPK 8ESEIPDd/jZ7J4jnCwRnz33QjySgrxQZCO4dW3RXOl3NhEHIPs0XHB2DujHSFf7uxYsf uOtfVlt5o2LmTOt6PestiX7KrjMPt0mmOoOGZ99Ahqw7Ss/ONjvvz79f083SixTKIIM1 iEwhdYpTmnpFT1nTfgSdQZg/HHAMRA86BlrfhoIHNbPp5/cZQfwZm/a72wAczLUGK5gO CEfw== MIME-Version: 1.0 Received: by 10.180.81.39 with SMTP id w7mr56579449wix.15.1356782386206; Sat, 29 Dec 2012 03:59:46 -0800 (PST) Received: by 10.216.172.197 with HTTP; Sat, 29 Dec 2012 03:59:45 -0800 (PST) In-Reply-To: <87.5C.07640.028DED05@smtp02.insight.synacor.com> References: <87.5C.07640.028DED05@smtp02.insight.synacor.com> Date: Sat, 29 Dec 2012 13:59:45 +0200 Message-ID: Subject: Re: 9.1 minimal ram requirements From: Kimmo Paasiala To: Thomas Mueller Content-Type: text/plain; charset=UTF-8 Cc: Mark Linimon , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 11:59:47 -0000 On Sat, Dec 29, 2012 at 1:46 PM, Thomas Mueller wrote: > from Mark Linimon : > >> In an ideal world, the bits that will almost certainly become FreeBSD 9.1 >> would not appear on the masters, or any of the mirrors, until the same >> instant that the release announcement is set to freebsd-announce@FreeBSD.org. > >> In practice this doesn't happen. If there is some clever way for that to >> happen, we haven't found it yet. > >> It has happened in the past that even as the release bits were propogating, >> One Last Big Bug was found and those bits had to be pulled and re-done. It >> would have looked like you had FreeBSD Release X.Y but you wouldn't have had >> the final bits that everyone else did. > >> I understand your frustration that this process takes days, and in general >> the frustration with this particular release -- more than you could possibly >> believe. However, until we figure out the process that would exist in an >> ideal world, this is what we have, and so if you need something that will be >> in 9.1, your options at this moment are: build an install from 9-STABLE; find >> one of the snapshots (and no, I am not the one to ask, sorry); or wait. > >> Sorry, but that's the best I can offer right now. > >> mcl > > So that's why I downloaded-updated source tree using svn, built and installed, > and uname -a revealed 9.1-PRERELEASE. It seemed strange after 9.1-RELEASE > became available on FTP servers December 5. Maybe they can do something to > better document "device ctl" in GENERIC; I kept it because it was there, and > one is led to think it is needed due to changes in FreeBSD. > > > Tom Most likely you took the stable/9 aka 9-STABLE sources. They have internal name "9.1-PRERELEASE" until the 9.1-RELEASE goes out of the door. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 12:06:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 566D49C3 for ; Sat, 29 Dec 2012 12:06:36 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by mx1.freebsd.org (Postfix) with ESMTP id DA12F8FC08 for ; Sat, 29 Dec 2012 12:06:35 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id hn17so8596131wib.0 for ; Sat, 29 Dec 2012 04:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oYE2/k4KfdTBidxhxNyTeL4lNrJPRrxcLhivfHo0uJg=; b=UrVeJECt8QwK4dhO0NI75/J91sicB6A5vlWFMp5nUm/LroIhJODSFkkE3DFNVWL9l7 BUSq402c/lnuO5tkVw97XK6tRDgEP+PLLlgFR3eTK3I2FNH8kttIpQeYnAZqEInTJknX WAdZKEhsgiME5KK+g2wRm880Uk/aPqSkpuDQJSuUsfvb+wG0HyfrwA5pbsS2+COXC9Ir hPXJmXkGFtKMcQGQlDc26UnT9Qv1VpweNyQzK2mg1RVAzGA8bwLL3YKl9vVpRWri7rwv AhBM5lls/nAB+XXPTqIULQ122DPbiJoLkIs1AiR3aXkCcTRADi55UnJQEw/0T5wO/nq8 2hRQ== MIME-Version: 1.0 Received: by 10.180.93.40 with SMTP id cr8mr57052708wib.15.1356782789669; Sat, 29 Dec 2012 04:06:29 -0800 (PST) Received: by 10.216.172.197 with HTTP; Sat, 29 Dec 2012 04:06:29 -0800 (PST) In-Reply-To: References: <87.5C.07640.028DED05@smtp02.insight.synacor.com> Date: Sat, 29 Dec 2012 14:06:29 +0200 Message-ID: Subject: Re: 9.1 minimal ram requirements From: Kimmo Paasiala To: Thomas Mueller Content-Type: text/plain; charset=UTF-8 Cc: Mark Linimon , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 12:06:36 -0000 On Sat, Dec 29, 2012 at 1:59 PM, Kimmo Paasiala wrote: > On Sat, Dec 29, 2012 at 1:46 PM, Thomas Mueller wrote: >> from Mark Linimon : >> >>> In an ideal world, the bits that will almost certainly become FreeBSD 9.1 >>> would not appear on the masters, or any of the mirrors, until the same >>> instant that the release announcement is set to freebsd-announce@FreeBSD.org. >> >>> In practice this doesn't happen. If there is some clever way for that to >>> happen, we haven't found it yet. >> >>> It has happened in the past that even as the release bits were propogating, >>> One Last Big Bug was found and those bits had to be pulled and re-done. It >>> would have looked like you had FreeBSD Release X.Y but you wouldn't have had >>> the final bits that everyone else did. >> >>> I understand your frustration that this process takes days, and in general >>> the frustration with this particular release -- more than you could possibly >>> believe. However, until we figure out the process that would exist in an >>> ideal world, this is what we have, and so if you need something that will be >>> in 9.1, your options at this moment are: build an install from 9-STABLE; find >>> one of the snapshots (and no, I am not the one to ask, sorry); or wait. >> >>> Sorry, but that's the best I can offer right now. >> >>> mcl >> >> So that's why I downloaded-updated source tree using svn, built and installed, >> and uname -a revealed 9.1-PRERELEASE. It seemed strange after 9.1-RELEASE >> became available on FTP servers December 5. Maybe they can do something to >> better document "device ctl" in GENERIC; I kept it because it was there, and >> one is led to think it is needed due to changes in FreeBSD. >> >> >> Tom > > Most likely you took the stable/9 aka 9-STABLE sources. They have > internal name "9.1-PRERELEASE" until the 9.1-RELEASE goes out of the > door. Erm too little coffee this early... I should have written "IF" you are following stable/9 aka 9-STABLE the 9.1-PRERELEASE is what you will see as the internal name until 9.1-RELEASE is released. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 12:15:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C303E71 for ; Sat, 29 Dec 2012 12:15:31 +0000 (UTC) (envelope-from lists@internecto.net) Received: from mx1.internecto.net (polaris.internecto.net [176.9.245.29]) by mx1.freebsd.org (Postfix) with ESMTP id EF3888FC12 for ; Sat, 29 Dec 2012 12:15:30 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id BC2F0340003 for ; Sat, 29 Dec 2012 12:15:29 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.internecto.net Received: from mx1.internecto.net ([127.0.0.1]) by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCRZNNUiIbIM for ; Sat, 29 Dec 2012 12:15:29 +0000 (UTC) Received: from [192.168.2.10] (unknown [172.17.37.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lists@internecto.net) by mx1.internecto.net (Postfix) with ESMTPSA id 1A49C340002 for ; Sat, 29 Dec 2012 12:15:29 +0000 (UTC) Message-ID: <50DEDEDA.2050502@internecto.net> Date: Sat, 29 Dec 2012 13:15:22 +0100 From: Mark van Dijk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 (amd64) buildworld stage 4.2 fails with clang: unknown target cpu i686 References: <50DED9BA.1000400@internecto.net> In-Reply-To: <50DED9BA.1000400@internecto.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 12:15:31 -0000 On 29-12-12 12:53, Mark van Dijk wrote: > (...) > I'll admit that I did modify my make.conf right before building. It > already *did* contain the CC/CXX/CPP lines for clang but the ccache > portion was slightly different. It used to contain the literal contents > of ccache-howto-freebsd.txt: > > CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} > CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} > > Today I re-read that howto and it states: > "You can replace cc and c++ with the compilers of your choice. > (remember that only GCC and Clang can build world and kernel)" > > So I updated those two lines and replaced cc/c++ with clang/clang++. I > didn't get the make errors before. So I moved those two lines back, did > rm -rf /usr/obj/* and started another make buildworld which is still > running. Scratch the above, I received the same error again just now. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 13:30:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 726B91A9 for ; Sat, 29 Dec 2012 13:30:37 +0000 (UTC) (envelope-from gorshkov.pavel@gmail.com) Received: from imp01.mtu.ru (imp01.mtu.ru [62.5.255.10]) by mx1.freebsd.org (Postfix) with ESMTP id ADB5B8FC08 for ; Sat, 29 Dec 2012 13:30:36 +0000 (UTC) Received: from lifebook ([91.79.89.14]) by imp01.mtu.ru with bizsmtp id hRWZ1k01Y0JaWa301RWaFo; Sat, 29 Dec 2012 17:30:34 +0400 X-Spam-Flag: NO Received: from localhost (localhost [127.0.0.1]) by lifebook (8.14.5/8.14.5) with ESMTP id qBTDUYFq043193; Sat, 29 Dec 2012 17:30:34 +0400 (MSK) (envelope-from gorshkov.pavel@gmail.com) Date: Sat, 29 Dec 2012 17:30:34 +0400 From: Pavel Gorshkov To: Konstantin Belousov Subject: Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup Message-ID: <20121229133034.GA43182@localhost> References: <50DC30F6.1050904@incore.de> <20121227133355.GI82219@kib.kiev.ua> <50DC8999.8000708@incore.de> <20121227194145.GM82219@kib.kiev.ua> <50DD6423.5090305@incore.de> <20121228112724.GR82219@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121228112724.GR82219@kib.kiev.ua> X-Operating-System: FreeBSD 9.1-RELEASE amd64 X-Editor: Vim-703 http://www.vim.org User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 13:30:37 -0000 On Fri, Dec 28, 2012 at 01:27:24PM +0200, Konstantin Belousov wrote: > Please try the following patch. It is against HEAD, might need some > adjustments for 8. I do the resume and write accounting atomically, > not allowing other suspension to intervent between. So is this only limited to snapshot creation, or can it happen during some other relatively heavy disk activity, e.g. trying to build/install two ports simultaneously? Because I have just experienced a very similar hang - not sure about 'suspfs' though (couldn't run top). From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 14:35:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25DEABCC for ; Sat, 29 Dec 2012 14:35:01 +0000 (UTC) (envelope-from lists@internecto.net) Received: from mx1.internecto.net (polaris.internecto.net [176.9.245.29]) by mx1.freebsd.org (Postfix) with ESMTP id C7FF78FC0A for ; Sat, 29 Dec 2012 14:35:00 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id 82EBA340003 for ; Sat, 29 Dec 2012 14:34:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.internecto.net Received: from mx1.internecto.net ([127.0.0.1]) by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l98z3Q2dXTWt for ; Sat, 29 Dec 2012 14:34:51 +0000 (UTC) Received: from [192.168.2.10] (unknown [172.17.37.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lists@internecto.net) by mx1.internecto.net (Postfix) with ESMTPSA id 9D9E5340002 for ; Sat, 29 Dec 2012 14:34:51 +0000 (UTC) Message-ID: <50DEFF85.3030103@internecto.net> Date: Sat, 29 Dec 2012 15:34:45 +0100 From: Mark van Dijk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 (amd64) buildworld stage 4.2 fails with clang: unknown target cpu i686 References: <50DED9BA.1000400@internecto.net> In-Reply-To: <50DED9BA.1000400@internecto.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 14:35:01 -0000 On 29-12-12 12:53, Mark van Dijk wrote: > I suspect that the error is caused by -march=native, my CPU is an Intel > Core i5. Looks like I was correct. CPUTYPE?=core2 will build world fine so perhaps 'native' does not know about my processor yet. Apparently it falls back to assuming it's a i686. Mark From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 19:03:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7699B55A for ; Sat, 29 Dec 2012 19:03:06 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 382808FC13 for ; Sat, 29 Dec 2012 19:03:05 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so14004127iec.13 for ; Sat, 29 Dec 2012 11:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A5c+54RzkS/EeW6ufWAG57k4QoQx6zDxu3O5Tcx9Jo4=; b=0jZnhArqErbn6VS1N/8IPOT0aVVXu46lAocMfVuHpf4xxstv0DG3UWL560+oO0RTFE iOsn/K42Nmr6V8CsTU9J4NeCud+q4GkBHk3fGFtTgR1hUfWGUvjvrlENdr886bhDyrnL Tr7w31Gv7O3JTZu/edMLcbi/WpTdrfxESp3OVCcyNXzkLRYl3rAUnKeorjRURpN3F4I9 d+UwBt2MJ7KPKNYOUIDWO/W5DZQiV9cbP4bwtaFX/y0DHgh9+RjrWmmvruXJRdN3YdSa Bxv19KueLNw7nSUIe2cCNrfNQfvAD0OQpEDGMMnKeSThco+oNetq8wjQajfxFKFF+RzR kKBw== MIME-Version: 1.0 Received: by 10.50.91.168 with SMTP id cf8mr33068602igb.20.1356807778865; Sat, 29 Dec 2012 11:02:58 -0800 (PST) Received: by 10.50.192.167 with HTTP; Sat, 29 Dec 2012 11:02:58 -0800 (PST) In-Reply-To: <50DEFF85.3030103@internecto.net> References: <50DED9BA.1000400@internecto.net> <50DEFF85.3030103@internecto.net> Date: Sat, 29 Dec 2012 13:02:58 -0600 Message-ID: Subject: Re: FreeBSD 9 (amd64) buildworld stage 4.2 fails with clang: unknown target cpu i686 From: Scot Hetzel To: Mark van Dijk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 19:03:06 -0000 On Sat, Dec 29, 2012 at 8:34 AM, Mark van Dijk wrote: > On 29-12-12 12:53, Mark van Dijk wrote: >> I suspect that the error is caused by -march=native, my CPU is an Intel >> Core i5. > > Looks like I was correct. CPUTYPE?=core2 will build world fine so > perhaps 'native' does not know about my processor yet. Apparently it > falls back to assuming it's a i686. > Tha problem that src/share/mk/bsd.cpu.mk doesn't know how to handle CPUTYPE=native correctly. CPUTYPE=core2 i386: MACHINE_CPU = ssse3 sse3 sse2 sse i686 mmx i586 i486 amd64: MACHINE_CPU = ssse3 sse3 amd64 sse2 sse mmx CPUTYPE=native i386: MACHINE_CPU = i486 amd64: MACHINE_CPU = amd64 sse2 sse mmx See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/112997 for one possible fix. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 29 19:48:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D98B5E2F; Sat, 29 Dec 2012 19:48:20 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8BE548FC12; Sat, 29 Dec 2012 19:48:20 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2117:5ae5:2037:1400] (unknown [IPv6:2001:7b8:3a7:0:2117:5ae5:2037:1400]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E4E2C5C5A; Sat, 29 Dec 2012 20:48:12 +0100 (CET) Message-ID: <50DF4903.9070006@FreeBSD.org> Date: Sat, 29 Dec 2012 20:48:19 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Scot Hetzel Subject: Re: FreeBSD 9 (amd64) buildworld stage 4.2 fails with clang: unknown target cpu i686 References: <50DED9BA.1000400@internecto.net> <50DEFF85.3030103@internecto.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark van Dijk , freebsd-stable@freebsd.org, Jung-uk Kim X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Dec 2012 19:48:20 -0000 On 2012-12-29 20:02, Scot Hetzel wrote:> On Sat, Dec 29, 2012 at 8:34 AM, Mark van Dijk wrote: >> On 29-12-12 12:53, Mark van Dijk wrote: >>> I suspect that the error is caused by -march=native, my CPU is an Intel >>> Core i5. >> >> Looks like I was correct. CPUTYPE?=core2 will build world fine so >> perhaps 'native' does not know about my processor yet. Apparently it >> falls back to assuming it's a i686. >> > > Tha problem that src/share/mk/bsd.cpu.mk doesn't know how to handle > CPUTYPE=native correctly. Actually, CPUTYPE=native is simply not supported. Just specify one of the supported types that matches your CPU most closely. ... > See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/112997 for one possible fix. The fix there invokes the compiler and some other tools for each include of the .mk file, which is usually too much overhead. Also, from the compiler output it is not very easy to get the list of supported features. I would rather fix bsd.cpu.mk to explicitly reject any non-recognized CPUTYPE value.