From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 01:43:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5479CC96 for ; Sun, 13 Jan 2013 01:43:10 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 21EA7174 for ; Sun, 13 Jan 2013 01:43:09 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id B4887450DE; Sun, 13 Jan 2013 01:43:06 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk B4887450DE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1358041387; bh=EImotVA2hpwEDIHCZJjXbff3AZmpFf4iePwJbLi1gko=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=tG0RxUH7tWvmJLYOHRlds6nL2meQNFmUauoBTj6sY3WqQ+P4SD7NOAxsLNy4P1LEz 2y/4BSRVNalZABBMYSO2lTNpT/86lwL1UgyDNBZLisvFwT4k2p8j8vm2oxhGHOxbJQ J5ZYr0TNdampaTGB0LzrNb5u0kC6rGNPsi6ggAeE= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id C250E82C1; Sun, 13 Jan 2013 01:43:03 +0000 (GMT) Date: Sun, 13 Jan 2013 01:43:03 +0000 From: Ben Morrow To: mjguzik@gmail.com, freebsd-stable@freebsd.org Subject: Re: Determining which process needs to be restarted after update Message-ID: <20130113014256.GA6645@anubis.morrow.me.uk> References: <201467687.20130112121822@takeda.tk> <20130112232914.GA4922@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130112234704.GA5849@dft-labs.eu> X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk 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: Sun, 13 Jan 2013 01:43:10 -0000 Quoth Mateusz Guzik : > On Sat, Jan 12, 2013 at 11:29:14PM +0000, Ben Morrow wrote: > > Quoth Derek Kulinski : > > > > > > I personally really like OpenSuSE command which is: zypper ps > > > What it does is it lists all processes that have files opened that > > > currently don't exist (i.e. link count is 0). This helps tremendously > > > in determining which processes need to be restarted after an update. > > > > > > Is there something similar for FreeBSD? I was thinking of using > > > lsof +L1, but on FreeBSD that command is not capable of displaying > > > names of files that were deleted, many entries returned are for > > > example processes that have open sockets. It also does not list names > > > of the deleted/replaced files. > > > > > > Is there a tool that is capable to do such task, or maybe some > > > additional options to lsof? I'm not too familiar with it myself. > > > > procstat -fa, look for entries with 'v' in the 'T' column and '-' in the > > 'NAME' column (or get awk to look for you). You may also want to check > > the 'V' column: see the manpage for the codes. This won't tell you what > > the file used to be called before it was deleted: I don't think the > > kernel keeps that information. > > > > This has at least 2 problems: > - it will not show shared libraries (-v is required) That's a good point. > - it will report processes with open unlinked files, which is completely > normal Isn't that exactly what the OP wants to find? I agree that it happens for reasons other than a software update, but I don't see how that can be avoided. Presumably the SuSE tool mentioned would give the same false positives. > But even if we use -v, I don't think we can reliably distinguish > "regular" unlinked file mapping from shared library mapping (for > unlinked files we will get - as a name, just like in -f case). I didn't > dig into this though. A process currently running an unlinked shared library will have at least one procstat -v entry with 'x' in the 'PRT' column, 'vn' in the 'TP' column and nothing in the 'PATH' column. > Instead I would go upwards in package dependency tree and for each daemon > check if it is running (should be doable without much hackery). Checking > for all binaries may be more problematic. Yes, something like that might be better, though that will also get a lot of false positives. Ben From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 04:08:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3E673480 for ; Sun, 13 Jan 2013 04:08:55 +0000 (UTC) (envelope-from jsteckli@os.inf.tu-dresden.de) Received: from os.inf.tu-dresden.de (os.inf.tu-dresden.de [IPv6:2002:8d4c:3001:48::99]) by mx1.freebsd.org (Postfix) with ESMTP id F2DAE6C0 for ; Sun, 13 Jan 2013 04:08:54 +0000 (UTC) Received: from [178.8.112.56] (helo=android-44bda2b04415f5bf.fritz.box) by os.inf.tu-dresden.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.80.1) id 1TuEsP-0004KE-1I; Sun, 13 Jan 2013 05:08:53 +0100 User-Agent: Kaiten Mail In-Reply-To: <50F06A43.801@digiware.nl> References: <50ACA518.4050309@digiware.nl> <50AD0AC2.5070804@FreeBSD.org> <50AD0B29.6060602@FreeBSD.org> <50AD0F00.5020600@digiware.nl> <50AD13EE.8050901@digiware.nl> <50AD17E4.50104@FreeBSD.org> <50AD189D.4040902@digiware.nl> <50AD1941.2020108@FreeBSD.org> <50ADF362.2040803@FreeBSD.org> <20121123140932.3a6deff6@mr129166> <50AF88AA.1060003@FreeBSD.org> <50AFF419.3070604@digiware.nl> <50AFF7C1.2090405@FreeBSD.org> <50AFFB9C.8050101@digiware.nl> <20121126111052.68136d00@mr129166> <50B3421B.2010606@FreeBSD.org> <20121129094137.6829eae8@mr129166> <50B7229D.4090901@digiware.nl> <50B77A6A.9050604@FreeBSD.org> <50B77C3B.6070305@digiware.nl> <50B77D70.1000803@FreeBSD.org> <871udwgbya.fsf@os.inf.tu-dresden.de> <50F06A43.801@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: Some new hardware with 9.1 does not reboot easily From: Julian Stecklina Date: Sun, 13 Jan 2013 05:08:44 +0100 To: Willem Jan Withagen Message-ID: <77b65510-95af-4e64-b4db-42c44e1e71fc@email.android.com> 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, 13 Jan 2013 04:08:55 -0000 Hello, Willem Jan Withagen wrote: > >A reboot work around that works for me: > reboot -n > shutdown -n now >Of which the manual pages say: option should not be used. >But I have not yet found bad effects. Perhaps becuase I only have ZFS >fs-systems Thanks for the workaround! But as you said, it doesn't feel very safe... Julian -- Sent from Kaiten Mail. Please excuse my brevity. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 16:12:14 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85390450; Sun, 13 Jan 2013 16:12:14 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id BD015BF0; Sun, 13 Jan 2013 16:12:13 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so781170wib.7 for ; Sun, 13 Jan 2013 08:12:12 -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:content-type:content-transfer-encoding; bh=zCp+1ttWB41FJpQYpE96JJirx6wUC50vENTp/02CM+8=; b=eg2+4QWSu8F9znrWn8poYsMU7OR4geTwrSy2XvRxN9bxw8M8NARDNTb8yjs3P52MCy qWAt75/4GqFZHfS21kbShPBJ3XEoxCImJC5eaG1+BtqOWvO5QmQBSYW8HBJFut7bz/sv xjnqjI39jveBLUq4ke86e39mzvcn8Vz61OIe5u36/wXfM/lmmc9badz3gkw1ylcYwDLh QCv1j4MrZc1tTBZXC8MOZH4+OPhqQJPaUGjfS2SyXibCzhpSo5L/DgybzS9ClRjpSSAD fHCrBURzUvvSuwaSwihyrPeMLSzxeZpKax/VIorndyxs9PewrJKKM6sB2t3f6F094SiK PkMw== X-Received: by 10.194.23.37 with SMTP id j5mr130386295wjf.28.1358093532616; Sun, 13 Jan 2013 08:12:12 -0800 (PST) Received: from mkushnir.zapto.org (170-113-132-95.pool.ukrtel.net. [95.132.113.170]) by mx.google.com with ESMTPS id bw9sm8732248wib.5.2013.01.13.08.12.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 08:12:11 -0800 (PST) Message-ID: <50F2DCA1.8080208@gmail.com> Date: Sun, 13 Jan 2013 18:11:13 +0200 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: stable@freebsd.org Subject: VIDIOC_ENUM_FRAMESIZES in linux_ioctl.c Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: nox@freebsd.org, netchild@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, 13 Jan 2013 16:12:14 -0000 Hi, Any reason why LINUX_VIDIOC_ENUM_FRAMESIZES, LINUX_VIDIOC_ENUM_FRAMEINTERVALS, LINUX_VIDIOC_ENCODER_CMD, and LINUX_VIDIOC_TRY_ENCODER_CMD in compat/linux/linux_ioctl.c have been put under #ifdef VIDIOC_ENUM_FRAMESIZES (looks like it's been there since rev. 221426, when the v4l2 support was introduced) ? I've just hit an issue with the current Skypes in the ports tree (both 2.1.0.81 and 2.2.0.35) trying to call at least the LINUX_VIDIOC_ENUM_FRAMESIZES ioctl, so I re-built linux.ko with -DVIDIOC_ENUM_FRAMESIZES and found no visible issues on my desktop so far beyond that my skype started to send video. If there is some reason, it would be good to let people know why these ioctls are turned off by default. -- Thanks, Markiyan. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 16:32:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3E74A105 for ; Sun, 13 Jan 2013 16:32:32 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by mx1.freebsd.org (Postfix) with ESMTP id B715DDFE for ; Sun, 13 Jan 2013 16:32:31 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id x43so1644247wey.37 for ; Sun, 13 Jan 2013 08:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=SjP+5dUwHC5Z6U7/MnMKqjhH3n7QJ6NnLTq5AfsF720=; b=Zp7vFejdEug7OahHr4ip51QJLsp76Ha7Cu667cLjYewnIxFVFdoXWkUBnuzwbyLLLQ yhzD7vy1bg+bOpQ2uMMbfedEqPfC6VOCKbNsnLUFVttSaKCTfGVmixKK2R2TLYRPYX6g QJjQh2t0Bbp+Bnuvl8kEm5bIBWaiudInqnZq36D+y81ahO4fgzdi+Dn/fOEXAU5PF4AQ HHjcKLL0J7KQb7jFAzUwc6frvXB8upEo91AeUFzrq86lu9BlwFurDbOXBHrwz7NmzCRV O86uQ5cKZ1PpxqSStloNOk2k8RUrxS/8nZ/6hE7n/NPa6qfX56C1sdPTUyjhh9Dg2U/3 /OKg== X-Received: by 10.194.174.196 with SMTP id bu4mr130339284wjc.35.1358094745683; Sun, 13 Jan 2013 08:32:25 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id df2sm8825516wib.0.2013.01.13.08.32.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 13 Jan 2013 08:32:24 -0800 (PST) Date: Sun, 13 Jan 2013 17:32:12 +0100 From: Mateusz Guzik To: Ben Morrow Subject: Re: Determining which process needs to be restarted after update Message-ID: <20130113163212.GA20259@dft-labs.eu> References: <201467687.20130112121822@takeda.tk> <20130112232914.GA4922@anubis.morrow.me.uk> <20130113014256.GA6645@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130113014256.GA6645@anubis.morrow.me.uk> 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: Sun, 13 Jan 2013 16:32:32 -0000 On Sun, Jan 13, 2013 at 01:43:03AM +0000, Ben Morrow wrote: > Quoth Mateusz Guzik : > > On Sat, Jan 12, 2013 at 11:29:14PM +0000, Ben Morrow wrote: > > > Quoth Derek Kulinski : > > > > > > > > I personally really like OpenSuSE command which is: zypper ps > > > > What it does is it lists all processes that have files opened that > > > > currently don't exist (i.e. link count is 0). This helps tremendously > > > > in determining which processes need to be restarted after an update. > > > > > > > > Is there something similar for FreeBSD? I was thinking of using > > > > lsof +L1, but on FreeBSD that command is not capable of displaying > > > > names of files that were deleted, many entries returned are for > > > > example processes that have open sockets. It also does not list names > > > > of the deleted/replaced files. > > > > > > > > Is there a tool that is capable to do such task, or maybe some > > > > additional options to lsof? I'm not too familiar with it myself. > > > > > > procstat -fa, look for entries with 'v' in the 'T' column and '-' in the > > > 'NAME' column (or get awk to look for you). You may also want to check > > > the 'V' column: see the manpage for the codes. This won't tell you what > > > the file used to be called before it was deleted: I don't think the > > > kernel keeps that information. > > > > > > > This has at least 2 problems: > > - it will not show shared libraries (-v is required) > > That's a good point. > > > - it will report processes with open unlinked files, which is completely > > normal > > Isn't that exactly what the OP wants to find? I agree that it happens > for reasons other than a software update, but I don't see how that can > be avoided. Presumably the SuSE tool mentioned would give the same false > positives. > Actually dcache in linux is able to return names for unlinked files. Such entries have ' (deleted)' appended. And it looks like it is able to do that reliably. Another thing is that this tool should have list of updated files, so matching it with ' (deleted)' files is trivial. Note that I didn't check how zypper ps actually works, just answering your concerns in this area. I think this approach is incorrect anyway, see below. > > But even if we use -v, I don't think we can reliably distinguish > > "regular" unlinked file mapping from shared library mapping (for > > unlinked files we will get - as a name, just like in -f case). I didn't > > dig into this though. > > A process currently running an unlinked shared library will have at > least one procstat -v entry with 'x' in the 'PRT' column, 'vn' in the > 'TP' column and nothing in the 'PATH' column. > This does not allow you to distinguish from unlinked non-library file mmapped this way. > > Instead I would go upwards in package dependency tree and for each daemon > > check if it is running (should be doable without much hackery). Checking > > for all binaries may be more problematic. > > Yes, something like that might be better, though that will also get a > lot of false positives. > I don't see how it can produce false positives. It will miss processes running unpackaged stuff though. When it comes to updated files, the following may happen: 1. process is running old binary 2. process is running old libraries 3. process has old files opened 4. process read some old files and these are now closed So if you want to make sure that all processes are working with updated stuff dependency walk is the only way. And even if you want to ignore 4, since procstat does not give you names of delted inodes, you have to do dependency walk anyway. -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 16:56:38 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19ECAE6F; Sun, 13 Jan 2013 16:56:38 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id CAED2EEF; Sun, 13 Jan 2013 16:56:37 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id C27E91E00079; Sun, 13 Jan 2013 17:48:54 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.5/8.14.4) with ESMTP id r0DGmdIo073986; Sun, 13 Jan 2013 17:48:39 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.5/8.14.3/Submit) id r0DGmcFC073985; Sun, 13 Jan 2013 17:48:38 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sun, 13 Jan 2013 17:48:38 +0100 To: Markiyan Kushnir Subject: Re: VIDIOC_ENUM_FRAMESIZES in linux_ioctl.c Message-ID: <20130113164838.GA73810@triton8.kn-bremen.de> References: <50F2DCA1.8080208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F2DCA1.8080208@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: nox@freebsd.org, stable@freebsd.org, netchild@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, 13 Jan 2013 16:56:38 -0000 On Sun, Jan 13, 2013 at 06:11:13PM +0200, Markiyan Kushnir wrote: > Hi, > > Any reason why LINUX_VIDIOC_ENUM_FRAMESIZES, > LINUX_VIDIOC_ENUM_FRAMEINTERVALS, LINUX_VIDIOC_ENCODER_CMD, and > LINUX_VIDIOC_TRY_ENCODER_CMD in compat/linux/linux_ioctl.c have been put > under #ifdef VIDIOC_ENUM_FRAMESIZES (looks like it's been there since > rev. 221426, when the v4l2 support was introduced) ? > > I've just hit an issue with the current Skypes in the ports tree (both > 2.1.0.81 and 2.2.0.35) trying to call at least the > LINUX_VIDIOC_ENUM_FRAMESIZES ioctl, so I re-built linux.ko with > -DVIDIOC_ENUM_FRAMESIZES and found no visible issues on my desktop so > far beyond that my skype started to send video. > > If there is some reason, it would be good to let people know why these > ioctls are turned off by default. > IIRC netchild's concern was that these were not in Linux 2.6.16 that our Linuxolator defaults to emulating, so I put them under #ifdef. Did you find that skype video doesn't work without them? Back when I tested it it didn't seem to make a difference... (Tho I never could get skype 2.2.0.35 to work with video, I think because it tries to use inotify() which we don't emulate.) HTH, Juergen From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 17:55:41 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9903CC86 for ; Sun, 13 Jan 2013 17:55:41 +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 D4CB6171 for ; Sun, 13 Jan 2013 17:55:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0DHtRke073161; Sun, 13 Jan 2013 19:55:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0DHtRke073161 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0DHtRNZ073160; Sun, 13 Jan 2013 19:55:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Jan 2013 19:55:27 +0200 From: Konstantin Belousov To: Po-Li Soong Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1 Message-ID: <20130113175527.GB2561@kib.kiev.ua> References: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66DDB6@reactor.sldomain.com> <20130109234924.GM2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66E4F3@reactor.sldomain.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hTyD2MSx3HZlTIuF" Content-Disposition: inline In-Reply-To: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66E4F3@reactor.sldomain.com> 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: "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, 13 Jan 2013 17:55:41 -0000 --hTyD2MSx3HZlTIuF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 11, 2013 at 03:09:58PM +0000, Po-Li Soong wrote: > (kgdb) p/x *(struct vm_object *)0xffffffff81281580 > $1 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xffffffff80e54bbd, > lo_flags =3D 0x1430000, lo_data =3D 0x0, lo_witness =3D 0x0}, > mtx_lock =3D 0xfffffe0006f44000}, object_list =3D { > tqe_next =3D 0xffffffff81281240, tqe_prev =3D 0xffffffff812814a0}, > shadow_head =3D {lh_first =3D 0x0}, shadow_list =3D {le_next =3D 0x0, > le_prev =3D 0x0}, memq =3D {tqh_first =3D 0xfffffe00cfd3f880, > tqh_last =3D 0xfffffe00c9cac398}, root =3D 0xfffffe00cd733ab0, > size =3D 0x7ffffff, generation =3D 0x1, ref_count =3D 0x3f8, shadow_cou= nt =3D 0x0, > memattr =3D 0x6, type =3D 0x4, flags =3D 0x1000, pg_color =3D 0x0, pad1= =3D 0x0, > resident_page_count =3D 0x9b729, backing_object =3D 0x0, > backing_object_offset =3D 0x0, pager_object_list =3D {tqe_next =3D 0x0, > tqe_prev =3D 0x0}, rvq =3D {lh_first =3D 0xfffffe00c7dd2140}, cache = =3D 0x0, > handle =3D 0x0, un_pager =3D {vnp =3D {vnp_size =3D 0x0, writemappings = =3D 0x0}, > devp =3D {devp_pglist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, ops = =3D 0x0}, > sgp =3D {sgp_pglist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}}, swp = =3D { > swp_bcount =3D 0x0}}, cred =3D 0x0, charge =3D 0x0, paging_in_progr= ess =3D 0x1} >=20 > (kgdb) p/x *(struct vm_page *)0xfffffe00cd733ab0 > $2 =3D {pageq =3D {tqe_next =3D 0x0, tqe_prev =3D 0xfffffe00c7e7d678}, li= stq =3D { > tqe_next =3D 0xfffffe00cd733b28, tqe_prev =3D 0xfffffe00cd7331d8}, > left =3D 0xfffffe00c9b31c38, right =3D 0xfffffe00cd735c70, > object =3D 0xfffffffb81281580, pindex =3D 0x7495a, phys_addr =3D 0xbe95= a000, md =3D { > pv_list =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffffe00cd733af8}, > pat_mode =3D 0x6}, queue =3D 0xff, segind =3D 0x2, hold_count =3D 0x0, > order =3D 0xd, pool =3D 0x0, cow =3D 0x0, wire_count =3D 0x0, aflags = =3D 0x0, > flags =3D 0x0, oflags =3D 0x4, act_count =3D 0x0, busy =3D 0x0, valid = =3D 0xff, > dirty =3D 0x0} >=20 > (kgdb) list *vm_page_free_toq+0x45 > 0xffffffff80b506f5 is in vm_page_free_toq (/usr/src/sys/vm/vm_page.c:1878= ). > warning: Source file is more recent than executable. >=20 > 1873 > 1874 /* > 1875 * If fictitious remove object association and > 1876 * return, otherwise delay object association removal. > 1877 */ > 1878 if ((m->flags & PG_FICTITIOUS) !=3D 0) { > 1879 return; > 1880 } > 1881 > 1882 m->valid =3D 0; > (kgdb) This is strange. Can you disassemble your instance of the vm_page_free_toq() and show me the assembler listing ? The line you show has nothing to cause page fault if the m pointer itself is valid. >=20 >=20 > -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com]=20 > Sent: Wednesday, January 09, 2013 4:49 PM > To: Po-Li Soong > Cc: stable@FreeBSD.org > Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1 >=20 > On Wed, Jan 09, 2013 at 08:03:38PM +0000, Po-Li Soong wrote: > > Hi, > >=20 > > My name is Po-Li Soong. I ran into a crash not long after installing th= e 9.1 release on my home machine. I was performing a test run of file trans= fer with samba server running on the FreeBSD installation. The transfer rat= e was about 70-80 MB/sec. The core.txt is attached. If there are other cras= h dumps needed, please let me know. > >=20 > > I first discussed this panic with Justin Gibbs, a coworker of mine at S= pectra Logic. He referred me to this email address, suggesting that the inf= ormation should be relevant to you. Thanks for the help. > >=20 > > Regards, > >=20 > > Po-Li Soong > >=20 >=20 > > maestoso dumped core - see /var/crash/vmcore.0 > >=20 > > Sat Jan 5 19:53:24 MST 2013 > >=20 > > FreeBSD maestoso 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4= 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GE= NERIC amd64 > >=20 > > panic: page fault > >=20 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and=20 > > you are welcome to change it and/or distribute copies of it under certa= in conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "amd64-marcel-freebsd"... > >=20 > > Unread portion of the kernel message buffer: > >=20 > >=20 > > Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D= 01 > > fault virtual address =3D 0xfffffffb812815d8 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff80b50597 > > stack pointer =3D 0x28:0xffffff80fa3bc8d0 > > frame pointer =3D 0x28:0xffffff80fa3bc900 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 0 (zio_write_intr_5) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 3 > > KDB: stack backtrace: > > #0 0xffffffff809208a6 at kdb_backtrace+0x66 > > #1 0xffffffff808ea8be at panic+0x1ce > > #2 0xffffffff80bd8240 at trap_fatal+0x290 > > #3 0xffffffff80bd857d at trap_pfault+0x1ed > > #4 0xffffffff80bd8b9e at trap+0x3ce > > #5 0xffffffff80bc315f at calltrap+0x8 > > #6 0xffffffff80b506f5 at vm_page_free_toq+0x45 > > #7 0xffffffff80b4f276 at vm_object_page_remove+0x196 > > #8 0xffffffff80b46b06 at vm_map_delete+0x316 > > #9 0xffffffff80b46c11 at vm_map_remove+0x51 > > #10 0xffffffff80b3a70a at uma_large_free+0x3a > > #11 0xffffffff808d589a at free+0x5a > > #12 0xffffffff8169b4ce at zio_done+0x2ee > > #13 0xffffffff81699063 at zio_execute+0xc3 > > #14 0xffffffff8092cf55 at taskqueue_run_locked+0x85 > > #15 0xffffffff8092ded6 at taskqueue_thread_loop+0x46 > > #16 0xffffffff808bb9ef at fork_exit+0x11f > > #17 0xffffffff80bc368e at fork_trampoline+0xe > > Uptime: 3h19m34s > > Dumping 571 out of 3561=20 > > MB:..3%..12%..23%..31%..42%..51%..62%..73%..82%..93% > >=20 > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/k= ernel/zfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/zfs.ko Reading symbols from=20 > > /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensol= aris.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/opensolaris.ko > > #0 doadump (textdump=3DVariable "textdump" is not available. > > ) at pcpu.h:224 > > 224 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump (textdump=3DVariable "textdump" is not available. > > ) at pcpu.h:224 > > #1 0xffffffff808ea3a1 in kern_reboot (howto=3D260) > > at /usr/src/sys/kern/kern_shutdown.c:448 > > #2 0xffffffff808ea897 in panic (fmt=3D0x1
) > > at /usr/src/sys/kern/kern_shutdown.c:636 > > #3 0xffffffff80bd8240 in trap_fatal (frame=3D0xc, eva=3DVariable "eva"= is not available. > > ) > > at /usr/src/sys/amd64/amd64/trap.c:857 > > #4 0xffffffff80bd857d in trap_pfault (frame=3D0xffffff80fa3bc820, user= mode=3D0) > > at /usr/src/sys/amd64/amd64/trap.c:773 > > #5 0xffffffff80bd8b9e in trap (frame=3D0xffffff80fa3bc820) > > at /usr/src/sys/amd64/amd64/trap.c:456 > P > > #6 0xffffffff80bc315f in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:228 > > #7 0xffffffff80b50597 in vm_page_remove (m=3D0xfffffe00cd733ab0) > > at /usr/src/sys/vm/vm_page.c:975 > > #8 0xffffffff80b506f5 in vm_page_free_toq (m=3D0xfffffe00cd733ab0) > > at /usr/src/sys/vm/vm_page.c:1872 > > #9 0xffffffff80b4f276 in vm_object_page_remove (object=3D0xffffffff812= 81580,=20 > > start=3D477512, end=3D477539, options=3DVariable "options" is not a= vailable. > > ) at /usr/src/sys/vm/vm_object.c:1899 > > #10 0xffffffff80b46b06 in vm_map_delete (map=3D0xfffffe00020000e8, star= t=3DVariable "start" is not available. > > ) > > at /usr/src/sys/vm/vm_map.c:2739 > > #11 0xffffffff80b46c11 in vm_map_remove (map=3D0xfffffe00020000e8,=20 > > start=3D18446743525909626880, end=3D18446743525909737472) > > at /usr/src/sys/vm/vm_map.c:2871 > > #12 0xffffffff80b3a70a in uma_large_free (slab=3D0xfffffe00aceff8e0) > > at /usr/src/sys/vm/uma_core.c:3085 > > #13 0xffffffff808d589a in free (addr=3D0xffffff8074948000,=20 > > mtp=3D0xffffffff81747c20) at /usr/src/sys/kern/kern_malloc.c:572 > > #14 0xffffffff8169b4ce in zio_done (zio=3D0xfffffe007a9906e0) > > at=20 > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/ > > zfs/zio.c:2960 > > #15 0xffffffff81699063 in zio_execute (zio=3D0xfffffe007a9906e0) > > at=20 > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/ > > zfs/zio.c:1196 > > #16 0xffffffff8092cf55 in taskqueue_run_locked (queue=3D0xfffffe0006ed9= a00) > > at /usr/src/sys/kern/subr_taskqueue.c:308 > > #17 0xffffffff8092ded6 in taskqueue_thread_loop (arg=3DVariable "arg" i= s not available. > > ) > > at /usr/src/sys/kern/subr_taskqueue.c:497 > > #18 0xffffffff808bb9ef in fork_exit ( > > callout=3D0xffffffff8092de90 ,=20 > > arg=3D0xfffffe0006c072e0, frame=3D0xffffff80fa3bcc40) > > at /usr/src/sys/kern/kern_fork.c:992 > > #19 0xffffffff80bc368e in fork_trampoline () > > at /usr/src/sys/amd64/amd64/exception.S:602 > > #20 0x0000000000000000 in ?? () > > #21 0x0000000000000000 in ?? () > > #22 0x0000000000000000 in ?? () > > #23 0x0000000000000000 in ?? () > > #24 0x0000000000000000 in ?? () > > #25 0x0000000000000000 in ?? () > > #26 0x0000000000000000 in ?? () > > #27 0x0000000000000000 in ?? () > > #28 0x0000000000000000 in ?? () > > #29 0x0000000000000000 in ?? () > > #30 0x0000000000000000 in ?? () > > #31 0x0000000000000000 in ?? () > > #32 0x0000000000000000 in ?? () > > #33 0x0000000000000000 in ?? () > > #34 0x0000000000000000 in ?? () > > #35 0x0000000000000000 in ?? () > > #36 0x0000000000000000 in ?? () > > #37 0x0000000000000000 in ?? () > > #38 0x0000000000000000 in ?? () > > #39 0x0000000000000000 in ?? () > > #40 0x0000000000000000 in ?? () > > #41 0x0000000000000000 in ?? () > > #42 0x0000000000000000 in ?? () > > #43 0x0000000000000000 in ?? () > > #44 0xffffffff81242880 in tdq_cpu () > > #45 0xffffffff81242880 in tdq_cpu () > > #46 0xfffffe0006f44000 in ?? () > > #47 0x0000000000000000 in ?? () > > #48 0xffffff80fa3bc290 in ?? () > > #49 0xffffff80fa3bc238 in ?? () > > #50 0xfffffe00049a88e0 in ?? () > > #51 0xffffffff8091352e in sched_switch (td=3D0xffffffff812228a0,=20 > > newtd=3D0xfffffe0006c072e0, flags=3DVariable "flags" is not availab= le. > > ) at /usr/src/sys/kern/sched_ule.c:1921 > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) >=20 > Please, at the kgdb prompt, do > p/x *(struct vm_object *)0xffffffff81281580 p/x *(struct vm_page *)0xffff= fe00cd733ab0 list *vm_page_free_toq+0x45 --hTyD2MSx3HZlTIuF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8vUNAAoJEJDCuSvBvK1BQsAP/A51XZ9Yvs0gWK828YVaSuha we8+xDHCzH3u7OTi7zAj95P+lm3d+V6dw+7ihQAE+3OliXpdytW7bP/R8aJrByz5 DrvLsrdZFOGEEJR3LS60RR5wQzUFD5S/8wboiudoIzaI9RCqgssSbi7uoPYpf7vJ Y8Bo3dHRPhVJy4RXwJwhVi6DfCt+Hge037mnkYctS02DQHfbsOZRiPhKvvpirk4n 6xkO7mcOEA5zqy9M2QwGOjyWzr1ImEMzF5lDFr+v1O7Q98fyLBgQHIw7EjaK/kco KFIWFQacT1wwMy+b4cYocOb18KvNrO9xsbfZ4W3WXvSyiRgicGlijTO1uUifnsoi 0YBRl0CRKOxyIkfh+DsYfr7aAWpuINni37DKYhnE1qGlni8HphQAzfJBgtdgc1OI 78/h+mI8zrJVcGNApyGmqdvGSbnL13S+tYVQsiV+I5uSq7Wzo0LIYLSqVngsp4jF 2vR3VwDxwlXX0AyEouUhmDi9uIG+YCO052PwqeZiQsP1f3/Cygx1KZ/Du27Ake3T /p4nAQ/UMD/OE6QEpnG12pqNXuCNygSRernyMSK2gIhMk1dUf70XZvv0bXO+8wHI 29tauVgwTZSNRJ2thv5gAy3igchsyliq0hZLYOD7w6Qhx2lAaLUKXZWmKH9bDqWV Q7im8ewwqAinRfkMOCVS =hWUL -----END PGP SIGNATURE----- --hTyD2MSx3HZlTIuF-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 18:12:04 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B20ED41B; Sun, 13 Jan 2013 18:12:04 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07276242; Sun, 13 Jan 2013 18:12:03 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hn14so818035wib.9 for ; Sun, 13 Jan 2013 10:11:56 -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=AaNoFPQfKzUj5HpBH7mNx9KqzZWju5qAwJBJN9suKzU=; b=vvVqu7YIiZDxHMzXq02XXJwja/wOOHkdhFfts0iol7yrb/e+8eHTXUiFKx+3Jww7wC iEjpir5hlplyPN1szQdVJgxUJIN+hIrRaX9jyNh5trtJBzR2jaXmWe4TdPUgAQAgbd8F J2A1TK/je5CljtWewBV24li+7A1mKEnqkjiCIeVTfeln8GBmpaCsESi6S3hJQnUw8YJe Fr4392PZ5Cm3f+tfJdnfWNccrWnWz+QwGOiMGpaLyxwHZvlv/c1sALpc8tr+p/SlnIRw 0U8DBbuNyp1ftd2LEiXrTLR0imlX/Xvns6ZFcqrzcd6u/Yj0mj1cFb3uY3SNGqotcVlF 0FgQ== X-Received: by 10.180.84.131 with SMTP id z3mr8480986wiy.25.1358100716832; Sun, 13 Jan 2013 10:11:56 -0800 (PST) Received: from mkushnir.zapto.org (170-113-132-95.pool.ukrtel.net. [95.132.113.170]) by mx.google.com with ESMTPS id w5sm9191424wif.11.2013.01.13.10.11.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 10:11:56 -0800 (PST) Message-ID: <50F2F8B1.5010702@gmail.com> Date: Sun, 13 Jan 2013 20:10:57 +0200 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: Juergen Lock Subject: Re: VIDIOC_ENUM_FRAMESIZES in linux_ioctl.c References: <50F2DCA1.8080208@gmail.com> <20130113164838.GA73810@triton8.kn-bremen.de> In-Reply-To: <20130113164838.GA73810@triton8.kn-bremen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: nox@freebsd.org, stable@freebsd.org, netchild@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, 13 Jan 2013 18:12:04 -0000 On 13.01.2013 18:48, Juergen Lock wrote: > On Sun, Jan 13, 2013 at 06:11:13PM +0200, Markiyan Kushnir wrote: >> Hi, >> >> Any reason why LINUX_VIDIOC_ENUM_FRAMESIZES, >> LINUX_VIDIOC_ENUM_FRAMEINTERVALS, LINUX_VIDIOC_ENCODER_CMD, and >> LINUX_VIDIOC_TRY_ENCODER_CMD in compat/linux/linux_ioctl.c have been p= ut >> under #ifdef VIDIOC_ENUM_FRAMESIZES (looks like it's been there since >> rev. 221426, when the v4l2 support was introduced) ? >> >> I've just hit an issue with the current Skypes in the ports tree (both= >> 2.1.0.81 and 2.2.0.35) trying to call at least the >> LINUX_VIDIOC_ENUM_FRAMESIZES ioctl, so I re-built linux.ko with >> -DVIDIOC_ENUM_FRAMESIZES and found no visible issues on my desktop so >> far beyond that my skype started to send video. >> >> If there is some reason, it would be good to let people know why these= >> ioctls are turned off by default. >> > IIRC netchild's concern was that these were not in Linux 2.6.16 that > our Linuxolator defaults to emulating, so I put them under #ifdef. > Did you find that skype video doesn't work without them? Back when > I tested it it didn't seem to make a difference... (Tho I never > could get skype 2.2.0.35 to work with video, I think because it > tries to use inotify() which we don't emulate.) > ok, I see now. On my desktop, when trying to test skype video, I had=20 been getting: Jan 13 15:54:40 mkushnir kernel: linux: pid 48266 (skype): ioctl fd=3D44,= =20 cmd=3D0x564a ('V',74) is not implemented I was confused by that pwcview worked for me, but skype didn't. I found=20 that 0x564a is in that bunch of those under #ifdef ... I then recompiled the linux module with VIDIOC_ENUM_FRAMESIZES defined,=20 and skype started to send video. Yes, skype still tries to call=20 inotify_init() at startup, and one of its child processes dies desperatel= y: Jan 13 20:01:58 mkushnir kernel: linux: pid 84673 (skype): ioctl fd=3D26,= =20 cmd=3D0x8b01 ('=EF=BF=BD',1) is not implemented Jan 13 20:01:58 mkushnir last message repeated 9 times Jan 13 20:01:58 mkushnir kernel: linux: pid 84673 (skype): ioctl fd=3D27,= =20 cmd=3D0x8b01 ('=EF=BF=BD',1) is not implemented Jan 13 20:01:58 mkushnir last message repeated 9 times Jan 13 20:01:58 mkushnir kernel: linux: pid 84682 (skype): syscall=20 inotify_init not implemented Jan 13 20:01:59 mkushnir kernel: Failed to write core file for process=20 skype (error 14) Jan 13 20:01:59 mkushnir kernel: pid 84681 (skype), uid 1001: exited on=20 signal 6 but then video test passes OK, and I can actually send/receive video in=20 a session. I don't know if this breaks other things, so the ioctls probably should=20 be kept closed. -- Markiyan. > HTH, > Juergen > From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 21:57:48 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9117643F; Sun, 13 Jan 2013 21:57:48 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by mx1.freebsd.org (Postfix) with ESMTP id C4953F30; Sun, 13 Jan 2013 21:57:47 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b57so1646387eek.7 for ; Sun, 13 Jan 2013 13:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=8V6EMSvWZJHUHgX+nB2s8cmYorP75cnsxIo71lYpa9Q=; b=m5CkMLAzJXQ+DDnjIDKqi6G7ahaHL2Cs63ci9ZeOlEft71CYwjPOns1KQLtmte06/k G98GCiCDPuTww2Ry7EIOCBs9E4VuNCCiYSHVaiZMW7slfHNUPmkS2s/zDmBMCH3f9osh L7HMwL9zBlkfPPyU3q4jfGhHGMzg/GqxwcPsArNN33z1LWywuu50tBV0SjaYgIoj7Pqt 0NyGFcmWI/EVIgTiQXRWOu/KcFMuiBUGaMJ1Gu6pWhjqheH9Eh/6pEC58yQn8e3xPXvx bbVAjO5fqtVROlgFqOjsk4W2PeGEiBcjGmECDaCQku2SsfdOCDCeiRR+5xT4qb8zKtNn /UEQ== X-Received: by 10.14.204.70 with SMTP id g46mr198174046eeo.15.1358114261321; Sun, 13 Jan 2013 13:57:41 -0800 (PST) Received: from spongya (catv-80-98-246-83.catv.broadband.hu. [80.98.246.83]) by mx.google.com with ESMTPS id 6sm19115718eea.3.2013.01.13.13.57.39 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 13 Jan 2013 13:57:40 -0800 (PST) Sender: =?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?= Date: Sun, 13 Jan 2013 22:57:14 +0100 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report April-June, 2012 Message-ID: <20130113225714.0083627d@spongya> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; i386-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@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, 13 Jan 2013 21:57:48 -0000 FreeBSD Quarterly Status Report April-June, 2012 Introduction This report covers FreeBSD-related projects between April and June 2012. This quarter was highlighted by having a new Core Team elected, which took office on July 11th to start its work with a relatively high number of new members. Note that this is the second of the three reports planned for 2012. Thanks to all the reporters for the excellent work! This report contains 17 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between July and December 2012 is February 17th, 2013. __________________________________________________________________ Projects Userland Programs * FreeBSD Services Control (fsc) * Replacing the Regular Expression Code FreeBSD Team Reports * FreeBSD Documentation Project * The FreeBSD Core Team * The FreeBSD Port Management Team Kernel * FreeBSD/at91 Improvements Network Infrastructure * Multipath TCP (MPTCP) for FreeBSD * SMP-Friendly pf(4) Documentation * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/arm on ARM Fast Models Simulator for Cortex-A15 MPCore Processor Ports * BSD-licensed Sort Utility (GNU sort(1) Replacement) * FreeBSD Haskell Ports * KDE/FreeBSD * Portbuilder * Redports * Xorg on FreeBSD Miscellaneous * BSD-Day 2012 __________________________________________________________________ BSD-Day 2012 URL: http://bsdday.eu/2012 URL: http://www.youtube.com/playlist?list=3DPL13D5471D8ECF08C9 URL: https://picasaweb.google.com/116452848880746560170/BSDDay2012?authk= ey=3DGv1sRgCN3twLrxuaeongE Contact: G=C3=A1bor P=C3=A1li For this year, we moved the time of the event earlier by six months, so it was held on May 5, 2012 and it was co-located with the Austrian Linuxweeks (Linuxwochen =C3=96sterreich) in Vienna. We had many sponsors, like the freshly joined FreeBSD Foundation, iXsystems, FreeBSDMall, BSD Magazine, allBSD.de Projekt, that enabled us to continue our previously launched series of multi-project BSD developer summits all around Central Europe. To kick off, there was a "stammtisch" (local beer meetup) organized in the downtown of Vienna, at Kolar on the Friday evening before the event -- as usual. Then it was followed by the event on Saturday that brought many interesting topics from the world of FreeBSD, OpenBSD and NetBSD: running NetBSD as an embedded system for managing VOIP applications, introduction to the Capsicum security framework, relayd(8), the load balancer and proxy solution for OpenBSD, status update of the developments around the FreeBSD ports tree, using DVCSs in clouds, firewalling with pfSense, and mfsBSD. Please consult the links in the report for the details. __________________________________________________________________ BSD-licensed Sort Utility (GNU sort(1) Replacement) URL: http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/bsdsort/ URL: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html Contact: Oleg Moskalenko Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n BSD sort(1) has been made the default sort utility in 10-CURRENT. It is compatible with the latest GNU sort(1), version 8.15, except that the multi-threaded mode is not enabled by default. Open tasks: 1. When the track record of the BSD sort(1) allows, remove GNU sort(1) from -CURRENT. 2. Improve reliability of the multi-threaded sort and investigate the possibility of making it the default compilation mode. 3. Investigate possibility of factoring out the sort functionality into a standalone library so that other utilities can also make use of it. __________________________________________________________________ FreeBSD Documentation Project URL: http://wiki.freebsd.org/GoogleCodeIn/2011Status URL: http://wiki.freebsd.org/201208DevSummit URL: http://wiki.freebsd.org/DocIdeaList Contact: We continue to make progress in committing the work produced as part of Google Code-In 2011; an overview of the status is at http://wiki.freebsd.org/GoogleCodeIn/2011Status. Doc committers and GCIN mentors are encouraged to go through the list and help shepherd outstanding tasks into the tree. We are planning a full day of Documentation Summit on the day preceding the August 2012 DevSummit in Cambridge, UK. This follows a successful DocSummit day held at BSDCan in May 2012. Further details are available at: http://wiki.freebsd.org/201208DevSummit. A doc sprint took place over IRC (#bsddocs on EFnet) in early July, setting out plans for reviving the marketing team and a strong desire for a new, more organized website. A lot of progress and momentum has built up with creating and updating documentation and website content over the last few months. Also read the doceng report for the recent infrastructure improvements. Anyone wishing to help with this effort is welcome to join us and say hello either on the freebsd-doc mailing list, or #bsddocs on EFnet IRC. Open tasks: 1. Review the website content and remove outdated parts or update when applicable. 2. Go through the doc idea list on the wiki and start working them out. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.freebsd.org/Haskell URL: https://github.com/freebsd-haskell/freebsd-haskell/ Contact: G=C3=A1bor P=C3=81LI Contact: Ashish SHUKLA We are proud to announce that the FreeBSD Haskell Team has updated the Haskell Platform to 2012.2.0.0, GHC to 7.4.1 as well as updated existing ports to their latest stable versions. We also added a number of new Haskell ports, and their count in FreeBSD Ports tree is now 336. Open tasks: 1. Test GHC to work with clang/LLVM. 2. Add an option to the lang/ghc port to be able to build it with already installed GHC instead of requiring a separate GHC bootstrap tarball. 3. Commit pending Haskell ports to the FreeBSD Ports tree. 4. Add more ports to the Ports Collection. __________________________________________________________________ FreeBSD Services Control (fsc) Contact: Tom Rhodes FSC has been moved into the ports system (see sysutils/fsc) and continues to improve outside of the ports tree. Some interesting work is being done in the area of services control, system boot, and a simplification of the process. Stay tuned for more information in status reports that follow. Open tasks: 1. Test, test, test. Feedback is really important to this project. __________________________________________________________________ FreeBSD/arm on ARM Fast Models Simulator for Cortex-A15 MPCore Processor URL: http://www.arm.com/products/processors/cortex-a/cortex-a15.php URL: http://www.arm.com/products/tools/models/fast-models.php Contact: Zbigniew Bodek Contact: Rafal Jaworowski Contact: Tomasz Nowicki ARM Fast Models is platform which helps software developers debug systems in parallel with SoC design, speeding up and improving system development. This work is bringing up FreeBSD on ARM Fast Models system based on ARM Cortex-A15 and peripheral components. It works in single user mode, using a compiled-in kernel RAM disk minimal root file system. Current FreeBSD support includes: * L1, L2 cache, Branch Predictor * Dual-core (SMP) support setup in WB cache mode * Cortex-A15 integrated Generic Timer * Drivers for ARM peripheral components: + PL011 UART controller + PL390 GIC - Generic Interrupt Controller + SP804 Dual Timer Next steps: * Quad-core (SMP) support * Multi-user mode __________________________________________________________________ FreeBSD/at91 Improvements URL: http://wiki.freebsd.org/FreeBSDAtmel Contact: Warner Losh FreeBSD's Atmel support has languished for some time. A number of improvements were urgently needed as demand for newer SoCs has materialized. New SoC support is not hard, but it does wind up copying a lot of code. I have started down the path to make it easier to do. I had planned on making it table driven. But then I discovered with dts files that Atmel was producing. So, I plan on moving to using Atmel's .dsti files, or variations on them. They have .dsti files for all the AT91SAM9 parts. This should allow us to support new SoCs and boards faster. However, there are some challenges with this approach. Pin multiplexing seems undefined in Atmel's dts file. Only a few of the devices are well-defined at the present time. And the encoding seems to be immature. So we have a target-rich port that is quite ripe for refactoring. Open tasks: 1. Update the base system libfdt to a version that supports include. 2. Write a .dtsi for Atmel AT91RM9200. 3. Write .dti files for all supported boards. 4. Help sort out the pin multiplexing issue. 5. Refactor existing board files to make new ones easier in the interim. 6. Knock yourself out and implement board support for new CPUs. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The team has made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.8.3, 4.8.4 (in ports) and 4.8.95 (in area51) * Qt: 4.8.1, 4.8.2 * PyQt: 4.9.1; SIP: 4.13.2; QScintilla 2.6.1 * KDevelop: 2.3.1; KDevPlatform: 1.3.1 * Calligra: 2.4.2, 2.4.3 * Amarok: 2.5.90 (in area51) * CMake: 2.8.8 * Digikam (and KIPI-plugins): 2.6.0 As a result -- according to PortScout -- kde@ has 393 ports, of which 91% are up-to-date. The team is always looking for more testers and porters so please contact us and visit our home page. Open tasks: 1. Test KDE SC 4.8.95. 2. Test KDE PIM 4.8.95. 3. Update out-of-date ports, see PortScout for a list. __________________________________________________________________ Multipath TCP (MPTCP) for FreeBSD URL: http://caia.swin.edu.au/newtcp/mptcp/ URL: http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-09 URL: http://mptcp.info.ucl.ac.be/ Contact: Nigel Williams Contact: Lawrence Stewart Contact: Grenville Armitage Work is underway to create an IETF draft-compatible Multipath TCP implementation for the FreeBSD kernel. A key goal of the project is to create a research platform to investigate a range of multipath related transport issues including congestion control, retransmission strategy and packet scheduling policy. We also aim to provide full interoperability with the Linux kernel implementation being developed at Universit=C3=A9 catholique de Louvain. We expect to release code and results at the project's home page as it progresses. __________________________________________________________________ Portbuilder URL: https://github.com/DragonSA/portbuilder URL: https://github.com/DragonSA/portbuilder/blob/0.1.5.2/README URL: https://github.com/DragonSA/portbuilder/blob/0.1.5.2/TODO Contact: David Naylor Since the last update there has been 2 feature releases and 4 bug-fix releases. A highlight of the changes made: * Support has been added for: * -j: controlling concurrency per stage * pkgng: next generation package manager * installing packages via repository * dynamic defaults (loaded from /etc/make.conf) * new options framework (aka OptionsNG) Some of the fixes include: * correct assertions * correct build logic * retry when kevent receives EINTR * correctly detecting installed ports * many fixes in the build logic A benchmark was run timing portbuilder against a standard ports build of KDE (x11/kde4) in a clean chroot(8) environment. Portbuilder achieved a build time of 2:21:16 compared to ports build time of 4:47:21 for an decreased build time of 51% from using portbuilder. __________________________________________________________________ Redports URL: http://www.redports.org/ Contact: Bernhard Froehlich There was good progress in the last half a year and a lot of support from different parties to make redports a stable and fast service. A long known security concern within tinderbox was raised at the BSD-Day in Vienna which was addressed by beat. That improves security and isolation of the concurrent running jobs a lot and gives me peace of mind. We also recently got two beefy machines from the FreeBSD Foundation which increases computing power a lot. So no more backlogs and your jobs finish much quicker. But as usual now that we have enough power I was able to make another promise come true and integrated Ports QAT functionality into redports. Ports QAT was an automated services that did a buildtest after each commit to the official FreeBSD ports tree. If a build fails it sends out mails and logfiles to the committer. That finds bad commits quickly and allows the committer to fix it before the first user notices. The former service stopped about 2 years ago and we had no proper replacement for that task at hand. Now that this is fully integrated into redports it also gives us all the nice benefits of a common platform. Open tasks: 1. Automatic build incoming patches from Ports PRs in redports and send results to GNATS database. 2. People want an GCC testing environment on redports where all ports are build with lang/gcc47. To make that happen we need to patch the ports framework to handle that and correctly bootstrap with base GCC. This also gives us the possibility to build all our binary packages with a modern gcc and is easy to use for regular users. Contributors? __________________________________________________________________ Replacing the Regular Expression Code URL: http://laurikari.net/tre/ Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n It has been decided to implement the optimizations and extensions as a more isolated layer and not directly in TRE itself. Since the last report there has been some progress in this direction and the code has been significantly refactored. It does not work yet in this new form but it is close to a working state. Apart from this, the multiple pattern matching needs some debugging and some minor features are missing. Open tasks: 1. Finish multiple pattern heuristic regex matching. 2. Implement GNU-specific regex extensions. 3. Test performance, standard-compliance and correct behavior. __________________________________________________________________ SMP-Friendly pf(4) URL: http://svnweb.freebsd.org/base/projects/pf/head/ URL: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html Contact: Gleb Smirnoff The project is aimed at moving the pf(4) packet filter out of single mutex, as well as in general improving of its FreeBSD port. The project is near its finish, the code is planned to go into head after more testing and benchmarking. If you are interested in details, please see the corresponding email thread on freebsd-pf (see links). Open tasks: 1. Rewrite the pf(4) ioctl() interface so that it does not utilize in-kernel structures. That would make ABI more stable and ease future development. __________________________________________________________________ The FreeBSD Core Team URL: http://docs.FreeBSD.org/cgi/mid.cgi?1342030291.6001.80.camel Contact: Core Team The FreeBSD Project is pleased to announce the completion of the 2012 Core Team election. The FreeBSD Core Team acts as the project's "Board of Directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, et cetera), and making any other administrative or policy decisions as needed. The Core Team has been elected by FreeBSD developers every 2 years since 2000. Peter Wemm rejoins the Core Team after a two-year hiatus, with new members Thomas Abthorpe, Gavin Atkinson, David Chisnall, Attilio Rao and Martin Wilke joining incumbents John Baldwin, Konstantin Belousov and Hiroki Sato. The complete newly elected core team is: * Thomas Abthorpe * Gavin Atkinson * John Baldwin * Konstantin Belousov * David Chisnall * Attilio Rao * Hiroki Sato * Peter Wemm * Martin Wilke The new Core Team would like to thank outgoing members Wilko Bulte, Brooks Davis, Warner Losh, Pav Lucistnik, Colin Percival and Robert Watson for their service over the past two (and in some cases, many more) years. The Core Team would also especially like to thank Dag-Erling Sm=C3=B8rgr= av for running the election. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki Our translation work has slightly moved on to handbook from the www/ja (CVS) or htdocs (SVN) subtree, since almost translated web page contents were updated to the latest English counterparts. During this period, we translated the 8.3-RELEASE announcement and published it in a timely manner. Newsflash and some other updates in the English version were also translated as soon as possible. For FreeBSD Handbook, translation work of the "cutting-edge" and "printing" sections have been completed. Some updates in the "linuxemu" and "serialcomms" section were done. At this moment, "bsdinstall", "cutting-edge", "desktop", "install", "introduction", "kernelconfig", "mirrors", "multimedia", "pgpkeys", "ports", "printing", and "x11" chapters are synchronized with the English versions. Open tasks: 1. Further translation work of outdated documents in ja_JP.eucJP subtree. __________________________________________________________________ The FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree slowly approaches 24,000 ports. The PR count still is close to 1200. In Q2 we added 7 new committers and took in one commit bit for safe keeping. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * automake update * cmake update * xorg update * png update * Fix make reinstall * Implement USE_QT4 in bsd.ports.mk * KDE4 update * XFCE4 update * bison update * perl5.14 as default * ruby1.9 as default * ruby1.8 update * bsdsort regression test A lot of focus during this period was put into getting the ports tree into a ready state for FreeBSD 9.1. A significant step forward was the implementation of OptionsNG. A record number of Port Managers attended BSDCan 2012, with five being present to partake in the week of events, culminating in a portmgr PR closing session that dealt with 18 PRs in one day. You can see a group photo at . While you are there, please click on the "Like" icon. Beat Gaetzi has been doing ongoing tests with the ports tree to ensure a smooth transition from CVS to Subversion. The tree was successfully migrated the weekend of June 14, 2012. Open tasks: 1. Looking for help getting ports to build with clang. 2. Looking for help fixing ports broken on CURRENT. (List needs updating, too.) 3. Looking for help with Tier-2 architectures. 4. ports broken by src changes. 5. ports failing on pointyhat. 6. ports failing on pointyhat-west. 7. ports that are marked as BROKEN. 8. When did that port break? 9. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ Xorg on FreeBSD URL: http://wiki.freebsd.org/Xorg URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: Martin Wilke Contact: Koop Mast Contact: Niclas Zeising Contact: Eitan Adler During the beginning of this period, an update to the xorg distribution for FreeBSD was made, dubbed xorg 7.5.2. This update included a new flag, WITH_NEW_XORG, to get a more recent xorg distribution for those with modern hardware. To get KMS support for recent Intel graphics chipsets WITH_KMS must also be set. This requires a recent FreeBSD 10-CURRENT or FreeBSD 9-STABLE. Open tasks: 1. Switch to use FreeGLUT instead of libGLUT, since the latter is old and has there is no upstream support or releases any more. Work on this is mostly done. 2. Update the xorg distribution to what is in the development repository. The xorg project recently did a new release, and the development repository contains this release. It needs more testing before it can be merged, and a CFT was sent out in the beginning of June. Work on this is ongoing. 3. Decide how to handle the new and old xorg distributions. In recent xorg, a lot of legacy driver support has been dropped, therefore we need to maintain two xorg distributions to not loose a lot of hardware drivers. Currently, this is done by setting the flag WITH_NEW_XORG in /etc/make.conf, but a more practical solution is needed. This is especially important since the flag is not very user friendly, and since there currently will be no official packages for the new distribution. __________________________________________________________________ (c) 1995-2013 The FreeBSD Project. All rights reserved. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 06:27:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA63962D for ; Mon, 14 Jan 2013 06:27:03 +0000 (UTC) (envelope-from rmsltd2000@yahoo.com) Received: from nm7-vm3.bullet.mail.ne1.yahoo.com (nm7-vm3.bullet.mail.ne1.yahoo.com [98.138.91.137]) by mx1.freebsd.org (Postfix) with ESMTP id 944D0401 for ; Mon, 14 Jan 2013 06:27:03 +0000 (UTC) Received: from [98.138.226.178] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jan 2013 06:24:49 -0000 Received: from [98.138.88.107] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jan 2013 06:24:49 -0000 Received: from [127.0.0.1] by smtp124-mob.biz.mail.ne1.yahoo.com with NNFMP; 14 Jan 2013 06:24:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358144688; bh=zjh8rtaBELnT5zQ3FSy2QGD0YQmqrhdJjem01F6vsMU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Subject:From:Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version; b=ZYfJh6HttWfKr1RFM/wxZxht+2iL+FdUOTY/pkN3gL/TXDvHD0E1oJN6YlgFvPruvhnZodAbOP4KlYHFlhW8/yfsWgybOLK0qWzpXsfMTtC9p6VpNGErov0cE4yjuIiXaR3aBRSsZtqvuWbe83a7CuPUIVMXn4WQGlns5RCfqxo= X-Yahoo-Newman-Id: 989841.67517.bm@smtp124-mob.biz.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3c5RsekVM1lYvxWDN57wPYFXBrnlbg0KqgZlp8JNUPZ9sgW T05MVqUyCb2e..4FwSMR_O5Q77T1l9_mCstjANRENGKUQglxH4CvRi0KwbPf .rXZM2tC2w.voY392Or5T.EcybdtIoINt1.SB7i2yiIrLO.VdNw3YKkg.QZF OAt4e0IwT_2cmb8.xlLuNd1dNzMpzjVBjE7Jq63AUZW5wdrlwAmgJooFvnGF WGh_U0BDDgfSQRlYB831WQkluyui8chChtSkfZNQbjA0jQFpIbklWzYy3EMB YzAqkD40cTKBYw6qRoYXdsbTk73v2Hy1.N_.jACVHGtZ5So.RC8Lv4OyZBM8 3DSwV9ebvULEWWkC2tnmcK_1ogGuSgGJjV6hezhwLNa4ASKDWjAANCbyuFsF Jml5zcW9LzQBvGu1CYKXYgzC2cE.__6CXqNxEB3qEefQjeba_DFYu_KpjLt5 BT4s- X-Yahoo-SMTP: zIOj5gSswBARFX51rIgAT8HenZSes2U- Received: from [172.16.0.2] (rmsltd2000@98.242.216.212 with xymcookie) by smtp124-mob.biz.mail.ne1.yahoo.com with SMTP; 14 Jan 2013 06:24:48 +0000 UTC Subject: Your New Adult FriendFinder Login Information! From: Glen Rotterman Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (10A523) Message-Id: <521AE14B-27EF-4E7C-A3F0-3813C717068C@yahoo.com> Date: Mon, 14 Jan 2013 01:24:47 -0500 To: "freebsd-stable@freebsd.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) 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, 14 Jan 2013 06:27:04 -0000 Please unsubscribe me ASAP Sent from my iPad From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 18:00:42 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6D1AC9A for ; Mon, 14 Jan 2013 18:00:42 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) by mx1.freebsd.org (Postfix) with ESMTP id B3F9D99D for ; Mon, 14 Jan 2013 18:00:42 +0000 (UTC) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 2610CBDC25 for ; Mon, 14 Jan 2013 19:00:41 +0100 (CET) Received: from ogg.in.absolight.net (ogg.in.absolight.net [79.143.241.239]) by prod2.absolight.net (Postfix) with ESMTPA id 1E0B3BDC1F for ; Mon, 14 Jan 2013 19:00:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ogg.in.absolight.net (Postfix) with ESMTP id DC3CB4DD78AB for ; Mon, 14 Jan 2013 19:00:40 +0100 (CET) Date: Mon, 14 Jan 2013 19:00:40 +0100 From: Mathieu Arnold To: stable@freebsd.org Subject: Upgrade to 9.1 failing Message-ID: <13BA1B76EC845A57F6527036@ogg.in.absolight.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Mon, 14 Jan 2013 18:00:43 -0000 Hi, Today, I was trying to upgrade a 7.0-rel box to 9.1 with freebsd-update, and I get : # freebsd-update -r 9.1-RELEASE upgrade Looking up update.freebsd.org mirrors... 3 mirrors found. Fetching metadata signature for 7.0-RELEASE from update4.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic src/base src/bin src/cddl src/compat src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/dict world/doc world/games world/info world/manpages The following components of FreeBSD do not seem to be installed: world/catpages world/proflibs Does this look reasonable (y/n)? y Fetching metadata signature for 9.1-RELEASE from update4.FreeBSD.org... done. Fetching metadata index... done. The update metadata is correctly signed, but failed an integrity check. Cowardly refusing to proceed any further. # -- Mathieu Arnold From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 18:05:32 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E828C159; Mon, 14 Jan 2013 18:05:32 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD979F3; Mon, 14 Jan 2013 18:05:32 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TuoPb-000PY1-VE; Mon, 14 Jan 2013 19:05:31 +0100 Date: Mon, 14 Jan 2013 19:05:31 +0100 From: Kurt Jaeger To: Mathieu Arnold Subject: Re: Upgrade to 9.1 failing Message-ID: <20130114180531.GH8239@home.opsec.eu> References: <13BA1B76EC845A57F6527036@ogg.in.absolight.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13BA1B76EC845A57F6527036@ogg.in.absolight.net> 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, 14 Jan 2013 18:05:33 -0000 Hi! > Today, I was trying to upgrade a 7.0-rel box to 9.1 with freebsd-update, > and I get : [...] > The update metadata is correctly signed, but > failed an integrity check. > Cowardly refusing to proceed any further. You can not upgrade from 7.0 to 9.1 directly. Use two intermediate steps, 7.4 and 8.3 and try if this works. Add more intermediate steps, if one fails. -- pi@opsec.eu +49 171 3101372 7 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 18:27:00 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B695B7BE for ; Mon, 14 Jan 2013 18:27:00 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) by mx1.freebsd.org (Postfix) with ESMTP id 628B6B3C for ; Mon, 14 Jan 2013 18:27:00 +0000 (UTC) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 6F973BDC4C for ; Mon, 14 Jan 2013 19:26:59 +0100 (CET) Received: from ogg.in.absolight.net (ogg.in.absolight.net [79.143.241.239]) by prod2.absolight.net (Postfix) with ESMTPA id 330DDBDC25 for ; Mon, 14 Jan 2013 19:26:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ogg.in.absolight.net (Postfix) with ESMTP id BB3D44DD7D3E for ; Mon, 14 Jan 2013 19:26:58 +0100 (CET) Date: Mon, 14 Jan 2013 19:26:58 +0100 From: Mathieu Arnold To: stable@freebsd.org Subject: Re: Upgrade to 9.1 failing Message-ID: <603EB188CA36FE2EE2198CFE@ogg.in.absolight.net> In-Reply-To: <20130114180531.GH8239@home.opsec.eu> References: <13BA1B76EC845A57F6527036@ogg.in.absolight.net> <20130114180531.GH8239@home.opsec.eu> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Mon, 14 Jan 2013 18:27:00 -0000 +--On 14 janvier 2013 19:05:31 +0100 Kurt Jaeger wrote: | Hi! | |> Today, I was trying to upgrade a 7.0-rel box to 9.1 with freebsd-update, |> and I get : | [...] |> The update metadata is correctly signed, but |> failed an integrity check. |> Cowardly refusing to proceed any further. | | You can not upgrade from 7.0 to 9.1 directly. | | Use two intermediate steps, 7.4 and 8.3 and try if this works. Add | more intermediate steps, if one fails. Hum, sorry, but no, that's not the problem, I just tried and I can upgrade from 6.2, 6.3, 6.4, 7.1 and 7.2 to 9.1 with freebsd-update directly without problems. It gives an error on 7.0, which leads me to think that something's broken on that particular path. The file[1] that fails integrity check must have had something bad happening to it when it was created. 1: debug tells me it's 9.1-RELEASE/i386/m/d80b83818c81a090997460d48fb1f53eb14d43072a1d1a4a5ba16de4c5ae93b2.gz -- Mathieu Arnold From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 20:04:11 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A61D95D0 for ; Mon, 14 Jan 2013 20:04:11 +0000 (UTC) (envelope-from polis@spectralogic.com) Received: from mail5.spectralogic.com (mail5.spectralogic.com [8.30.156.6]) by mx1.freebsd.org (Postfix) with ESMTP id 714627A1 for ; Mon, 14 Jan 2013 20:04:11 +0000 (UTC) From: Po-Li Soong To: Konstantin Belousov Subject: RE: zio_done panic on unadulterated FreeBSD Release 9.1 Thread-Topic: zio_done panic on unadulterated FreeBSD Release 9.1 Thread-Index: Ac3unBKkFihILaX0Sve67eNiNL/vMAACD/RwABaTbgAAQ7h6sAB5FWCAACeQGyA= Date: Mon, 14 Jan 2013 20:04:04 +0000 Message-ID: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66EF0E@reactor.sldomain.com> References: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66DDB6@reactor.sldomain.com> <20130109234924.GM2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66E4F3@reactor.sldomain.com> <20130113175527.GB2561@kib.kiev.ua> In-Reply-To: <20130113175527.GB2561@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.6.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 14 Jan 2013 20:04:11 -0000 Konstantin, First of all, I agree with you that it would be very strange to have crashe= d at vm_page_free_toq+0x45, by which point m (in the register rbx. See belo= w for the assembly listing.) has been dereferenced a few times. However, th= ere is a discrepancy between the KDB backtrace and the annotated one just f= ew lines below. In the annotated backtrace, it appears that it is the vm_pa= ge_remove that runs into the panic at 0xffffffff80b50597, which is at line = 975. That source line looks a lot more probable for causing a panic than th= at in vm_page_free_toq. Listed below are the assembly listing of vm_page_fr= ee_toq and vm_page_remove in the proximity of places of concerns. Regards, Po-Li Soong Dump of assembler code for function vm_page_free_toq: 0xffffffff80b506b0 : push %rbp 0xffffffff80b506b1 : mov %rsp,%rbp 0xffffffff80b506b4 : sub $0x20,%rsp 0xffffffff80b506b8 : mov %rbx,-0x18(%rbp) 0xffffffff80b506bc : mov %r12,-0x10(%rbp) 0xffffffff80b506c0 : mov %rdi,%rbx 0xffffffff80b506c3 : mov %r13,-0x8(%rbp) 0xffffffff80b506c7 : incl %gs:0xac 0xffffffff80b506cf : testb $0x2,0x6d(%rdi) 0xffffffff80b506d3 : jne 0xffffffff80b50901 <= vm_page_free_toq+593> 0xffffffff80b506d9 : cmpb $0x0,0x71(%rdi) 0xffffffff80b506dd : jne 0xffffffff80b50912 <= vm_page_free_toq+610> 0xffffffff80b506e3 : testb $0x4,0x6e(%rdi) 0xffffffff80b506e7 : je 0xffffffff80b50863 <= vm_page_free_toq+435> 0xffffffff80b506ed : mov %rbx,%rdi 0xffffffff80b506f0 : callq 0xffffffff80b50540 <= vm_page_remove> 0xffffffff80b506f5 : movzbl 0x6d(%rbx),%eax 0xffffffff80b506f9 : test $0x4,%al 0xffffffff80b506fb : jne 0xffffffff80b50767 <= vm_page_free_toq+183> 0xffffffff80b506fd : mov 0x68(%rbx),%esi =20 =20 Dump of assembler code for function vm_page_remove: 0xffffffff80b50540 : push %rbp 0xffffffff80b50541 : mov %rsp,%rbp 0xffffffff80b50544 : push %r13 0xffffffff80b50546 : push %r12 0xffffffff80b50548 : push %rbx 0xffffffff80b50549 : mov %rdi,%rbx 0xffffffff80b5054c : sub $0x8,%rsp 0xffffffff80b50550 : mov 0x30(%rdi),%r13 0xffffffff80b50554 : movzwl 0x6e(%rdi),%eax 0xffffffff80b50558 : test %r13,%r13 0xffffffff80b5055b : je 0xffffffff80b50610 0xffffffff80b50561 : test $0x1,%al 0xffffffff80b50563 : jne 0xffffffff80b50635 0xffffffff80b50569 : mov 0x10(%rbx),%r12 0xffffffff80b5056d : test %r12,%r12 0xffffffff80b50570 : je 0xffffffff80b5057d 0xffffffff80b50572 : cmp %rbx,0x20(%r12) 0xffffffff80b50577 : je 0xffffffff80b50660 0xffffffff80b5057d : mov 0x18(%rbx),%rcx 0xffffffff80b50581 : mov 0x8(%rcx),%rsi 0xffffffff80b50585 : mov (%rsi),%rdx 0xffffffff80b50588 : test %rdx,%rdx 0xffffffff80b5058b : je 0xffffffff80b50597 0xffffffff80b5058d : cmp %rbx,0x28(%rdx) 0xffffffff80b50591 : je 0xffffffff80b50646 0xffffffff80b50597 : mov 0x58(%r13),%rsi ; <<-----= -------------- 0xffffffff80b5059b : cmp %rbx,%rsi 0xffffffff80b5059e : je 0xffffffff80b505a9 0xffffffff80b505a0 : mov 0x38(%rbx),%rdi 0xffffffff80b505a4 : callq 0xffffffff80b4fa90 <= vm_page_splay> 0xffffffff80b505a9 : mov 0x20(%rbx),%rax 0xffffffff80b505ad : test %rax,%rax 0xffffffff80b505b0 : mov %rax,%rdx 0xffffffff80b505b3 : je 0xffffffff80b50672 <= vm_page_remove+306> 0xffffffff80b505b9 : mov 0x28(%rbx),%rsi 0xffffffff80b505bd : test %rsi,%rsi -----Original Message----- From: Konstantin Belousov [mailto:kostikbel@gmail.com]=20 Sent: Sunday, January 13, 2013 10:55 AM To: Po-Li Soong Cc: stable@FreeBSD.org Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1 On Fri, Jan 11, 2013 at 03:09:58PM +0000, Po-Li Soong wrote: > (kgdb) p/x *(struct vm_object *)0xffffffff81281580 > $1 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xffffffff80e54bbd, > lo_flags =3D 0x1430000, lo_data =3D 0x0, lo_witness =3D 0x0}, > mtx_lock =3D 0xfffffe0006f44000}, object_list =3D { > tqe_next =3D 0xffffffff81281240, tqe_prev =3D 0xffffffff812814a0}, > shadow_head =3D {lh_first =3D 0x0}, shadow_list =3D {le_next =3D 0x0, > le_prev =3D 0x0}, memq =3D {tqh_first =3D 0xfffffe00cfd3f880, > tqh_last =3D 0xfffffe00c9cac398}, root =3D 0xfffffe00cd733ab0, > size =3D 0x7ffffff, generation =3D 0x1, ref_count =3D 0x3f8, shadow_cou= nt =3D 0x0, > memattr =3D 0x6, type =3D 0x4, flags =3D 0x1000, pg_color =3D 0x0, pad1= =3D 0x0, > resident_page_count =3D 0x9b729, backing_object =3D 0x0, > backing_object_offset =3D 0x0, pager_object_list =3D {tqe_next =3D 0x0, > tqe_prev =3D 0x0}, rvq =3D {lh_first =3D 0xfffffe00c7dd2140}, cache = =3D 0x0, > handle =3D 0x0, un_pager =3D {vnp =3D {vnp_size =3D 0x0, writemappings = =3D 0x0}, > devp =3D {devp_pglist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, ops = =3D 0x0}, > sgp =3D {sgp_pglist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}}, swp = =3D { > swp_bcount =3D 0x0}}, cred =3D 0x0, charge =3D 0x0, paging_in_progr= ess=20 > =3D 0x1} >=20 > (kgdb) p/x *(struct vm_page *)0xfffffe00cd733ab0 > $2 =3D {pageq =3D {tqe_next =3D 0x0, tqe_prev =3D 0xfffffe00c7e7d678}, li= stq =3D { > tqe_next =3D 0xfffffe00cd733b28, tqe_prev =3D 0xfffffe00cd7331d8}, > left =3D 0xfffffe00c9b31c38, right =3D 0xfffffe00cd735c70, > object =3D 0xfffffffb81281580, pindex =3D 0x7495a, phys_addr =3D 0xbe95= a000, md =3D { > pv_list =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffffe00cd733af8}, > pat_mode =3D 0x6}, queue =3D 0xff, segind =3D 0x2, hold_count =3D 0x0= , > order =3D 0xd, pool =3D 0x0, cow =3D 0x0, wire_count =3D 0x0, aflags = =3D 0x0, > flags =3D 0x0, oflags =3D 0x4, act_count =3D 0x0, busy =3D 0x0, valid = =3D 0xff, > dirty =3D 0x0} >=20 > (kgdb) list *vm_page_free_toq+0x45 > 0xffffffff80b506f5 is in vm_page_free_toq (/usr/src/sys/vm/vm_page.c:1878= ). > warning: Source file is more recent than executable. >=20 > 1873 > 1874 /* > 1875 * If fictitious remove object association and > 1876 * return, otherwise delay object association removal. > 1877 */ > 1878 if ((m->flags & PG_FICTITIOUS) !=3D 0) { > 1879 return; > 1880 } > 1881 > 1882 m->valid =3D 0; > (kgdb) This is strange. Can you disassemble your instance of the vm_page_free_toq() and show me the assembler listing ? The line you show ha= s nothing to cause page fault if the m pointer itself is valid. >=20 >=20 > -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > Sent: Wednesday, January 09, 2013 4:49 PM > To: Po-Li Soong > Cc: stable@FreeBSD.org > Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1 >=20 > On Wed, Jan 09, 2013 at 08:03:38PM +0000, Po-Li Soong wrote: > > Hi, > >=20 > > My name is Po-Li Soong. I ran into a crash not long after installing th= e 9.1 release on my home machine. I was performing a test run of file trans= fer with samba server running on the FreeBSD installation. The transfer rat= e was about 70-80 MB/sec. The core.txt is attached. If there are other cras= h dumps needed, please let me know. > >=20 > > I first discussed this panic with Justin Gibbs, a coworker of mine at S= pectra Logic. He referred me to this email address, suggesting that the inf= ormation should be relevant to you. Thanks for the help. > >=20 > > Regards, > >=20 > > Po-Li Soong > >=20 >=20 > > maestoso dumped core - see /var/crash/vmcore.0 > >=20 > > Sat Jan 5 19:53:24 MST 2013 > >=20 > > FreeBSD maestoso 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4= 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GE= NERIC amd64 > >=20 > > panic: page fault > >=20 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and=20 > > you are welcome to change it and/or distribute copies of it under certa= in conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "amd64-marcel-freebsd"... > >=20 > > Unread portion of the kernel message buffer: > >=20 > >=20 > > Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D= 01 > > fault virtual address =3D 0xfffffffb812815d8 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff80b50597 > > stack pointer =3D 0x28:0xffffff80fa3bc8d0 > > frame pointer =3D 0x28:0xffffff80fa3bc900 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 0 (zio_write_intr_5) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 3 > > KDB: stack backtrace: > > #0 0xffffffff809208a6 at kdb_backtrace+0x66 > > #1 0xffffffff808ea8be at panic+0x1ce > > #2 0xffffffff80bd8240 at trap_fatal+0x290 > > #3 0xffffffff80bd857d at trap_pfault+0x1ed > > #4 0xffffffff80bd8b9e at trap+0x3ce > > #5 0xffffffff80bc315f at calltrap+0x8 > > #6 0xffffffff80b506f5 at vm_page_free_toq+0x45 > > #7 0xffffffff80b4f276 at vm_object_page_remove+0x196 > > #8 0xffffffff80b46b06 at vm_map_delete+0x316 > > #9 0xffffffff80b46c11 at vm_map_remove+0x51 > > #10 0xffffffff80b3a70a at uma_large_free+0x3a > > #11 0xffffffff808d589a at free+0x5a > > #12 0xffffffff8169b4ce at zio_done+0x2ee > > #13 0xffffffff81699063 at zio_execute+0xc3 > > #14 0xffffffff8092cf55 at taskqueue_run_locked+0x85 > > #15 0xffffffff8092ded6 at taskqueue_thread_loop+0x46 > > #16 0xffffffff808bb9ef at fork_exit+0x11f > > #17 0xffffffff80bc368e at fork_trampoline+0xe > > Uptime: 3h19m34s > > Dumping 571 out of 3561 > > MB:..3%..12%..23%..31%..42%..51%..62%..73%..82%..93% > >=20 > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/k= ernel/zfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/zfs.ko Reading symbols from=20 > > /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensol= aris.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/opensolaris.ko > > #0 doadump (textdump=3DVariable "textdump" is not available. > > ) at pcpu.h:224 > > 224 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump (textdump=3DVariable "textdump" is not available. > > ) at pcpu.h:224 > > #1 0xffffffff808ea3a1 in kern_reboot (howto=3D260) > > at /usr/src/sys/kern/kern_shutdown.c:448 > > #2 0xffffffff808ea897 in panic (fmt=3D0x1
) > > at /usr/src/sys/kern/kern_shutdown.c:636 > > #3 0xffffffff80bd8240 in trap_fatal (frame=3D0xc, eva=3DVariable "eva"= is not available. > > ) > > at /usr/src/sys/amd64/amd64/trap.c:857 > > #4 0xffffffff80bd857d in trap_pfault (frame=3D0xffffff80fa3bc820, user= mode=3D0) > > at /usr/src/sys/amd64/amd64/trap.c:773 > > #5 0xffffffff80bd8b9e in trap (frame=3D0xffffff80fa3bc820) > > at /usr/src/sys/amd64/amd64/trap.c:456 > P > > #6 0xffffffff80bc315f in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:228 > > #7 0xffffffff80b50597 in vm_page_remove (m=3D0xfffffe00cd733ab0) > > at /usr/src/sys/vm/vm_page.c:975 > > #8 0xffffffff80b506f5 in vm_page_free_toq (m=3D0xfffffe00cd733ab0) > > at /usr/src/sys/vm/vm_page.c:1872 > > #9 0xffffffff80b4f276 in vm_object_page_remove (object=3D0xffffffff812= 81580,=20 > > start=3D477512, end=3D477539, options=3DVariable "options" is not a= vailable. > > ) at /usr/src/sys/vm/vm_object.c:1899 > > #10 0xffffffff80b46b06 in vm_map_delete (map=3D0xfffffe00020000e8, star= t=3DVariable "start" is not available. > > ) > > at /usr/src/sys/vm/vm_map.c:2739 > > #11 0xffffffff80b46c11 in vm_map_remove (map=3D0xfffffe00020000e8,=20 > > start=3D18446743525909626880, end=3D18446743525909737472) > > at /usr/src/sys/vm/vm_map.c:2871 > > #12 0xffffffff80b3a70a in uma_large_free (slab=3D0xfffffe00aceff8e0) > > at /usr/src/sys/vm/uma_core.c:3085 > > #13 0xffffffff808d589a in free (addr=3D0xffffff8074948000,=20 > > mtp=3D0xffffffff81747c20) at /usr/src/sys/kern/kern_malloc.c:572 > > #14 0xffffffff8169b4ce in zio_done (zio=3D0xfffffe007a9906e0) > > at > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f > > s/ > > zfs/zio.c:2960 > > #15 0xffffffff81699063 in zio_execute (zio=3D0xfffffe007a9906e0) > > at > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f > > s/ > > zfs/zio.c:1196 > > #16 0xffffffff8092cf55 in taskqueue_run_locked (queue=3D0xfffffe0006ed9= a00) > > at /usr/src/sys/kern/subr_taskqueue.c:308 > > #17 0xffffffff8092ded6 in taskqueue_thread_loop (arg=3DVariable "arg" i= s not available. > > ) > > at /usr/src/sys/kern/subr_taskqueue.c:497 > > #18 0xffffffff808bb9ef in fork_exit ( > > callout=3D0xffffffff8092de90 ,=20 > > arg=3D0xfffffe0006c072e0, frame=3D0xffffff80fa3bcc40) > > at /usr/src/sys/kern/kern_fork.c:992 > > #19 0xffffffff80bc368e in fork_trampoline () > > at /usr/src/sys/amd64/amd64/exception.S:602 > > #20 0x0000000000000000 in ?? () > > #21 0x0000000000000000 in ?? () > > #22 0x0000000000000000 in ?? () > > #23 0x0000000000000000 in ?? () > > #24 0x0000000000000000 in ?? () > > #25 0x0000000000000000 in ?? () > > #26 0x0000000000000000 in ?? () > > #27 0x0000000000000000 in ?? () > > #28 0x0000000000000000 in ?? () > > #29 0x0000000000000000 in ?? () > > #30 0x0000000000000000 in ?? () > > #31 0x0000000000000000 in ?? () > > #32 0x0000000000000000 in ?? () > > #33 0x0000000000000000 in ?? () > > #34 0x0000000000000000 in ?? () > > #35 0x0000000000000000 in ?? () > > #36 0x0000000000000000 in ?? () > > #37 0x0000000000000000 in ?? () > > #38 0x0000000000000000 in ?? () > > #39 0x0000000000000000 in ?? () > > #40 0x0000000000000000 in ?? () > > #41 0x0000000000000000 in ?? () > > #42 0x0000000000000000 in ?? () > > #43 0x0000000000000000 in ?? () > > #44 0xffffffff81242880 in tdq_cpu () > > #45 0xffffffff81242880 in tdq_cpu () > > #46 0xfffffe0006f44000 in ?? () > > #47 0x0000000000000000 in ?? () > > #48 0xffffff80fa3bc290 in ?? () > > #49 0xffffff80fa3bc238 in ?? () > > #50 0xfffffe00049a88e0 in ?? () > > #51 0xffffffff8091352e in sched_switch (td=3D0xffffffff812228a0,=20 > > newtd=3D0xfffffe0006c072e0, flags=3DVariable "flags" is not availab= le. > > ) at /usr/src/sys/kern/sched_ule.c:1921 > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) >=20 > Please, at the kgdb prompt, do > p/x *(struct vm_object *)0xffffffff81281580 p/x *(struct vm_page=20 > *)0xfffffe00cd733ab0 list *vm_page_free_toq+0x45 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 21:20:30 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4E84AFE1 for ; Mon, 14 Jan 2013 21:20:30 +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 8C2D3B0A for ; Mon, 14 Jan 2013 21:20:29 +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 XAA10683; Mon, 14 Jan 2013 23:20:23 +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 1TurSB-000LME-Kj; Mon, 14 Jan 2013 23:20:23 +0200 Message-ID: <50F47695.8050205@FreeBSD.org> Date: Mon, 14 Jan 2013 23:20:21 +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: Po-Li Soong , Konstantin Belousov Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1 References: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66DDB6@reactor.sldomain.com> <20130109234924.GM2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66E4F3@reactor.sldomain.com> <20130113175527.GB2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66EF0E@reactor.sldomain.com> In-Reply-To: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66EF0E@reactor.sldomain.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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, 14 Jan 2013 21:20:30 -0000 on 14/01/2013 22:04 Po-Li Soong said the following: > First of all, I agree with you that it would be very strange to have crashed > at vm_page_free_toq+0x45, by which point m (in the register rbx. See below > for the assembly listing.) has been dereferenced a few times. However, there > is a discrepancy between the KDB backtrace and the annotated one just few > lines below. In the annotated backtrace, it appears that it is the > vm_page_remove that runs into the panic at 0xffffffff80b50597, which is at > line 975. That source line looks a lot more probable for causing a panic than > that in vm_page_free_toq. Yes, it looks like you do not have DDB in your kernel and thus the panic time backtrace was produced by stack(9), which is not aware of trap frames and such. So that stack trace is not correct (accidentally it misses just one frame just before the trap). On the other hand, the stack trace from kgdb seems to be on spot. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 21:56:09 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4C54F301; Mon, 14 Jan 2013 21:56:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id EECECDCB; Mon, 14 Jan 2013 21:56:08 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r0ELu7WJ048050; Mon, 14 Jan 2013 21:56:07 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r0ELu7pH048038; Mon, 14 Jan 2013 21:56:07 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 Jan 2013 21:56:07 GMT Message-Id: <201301142156.r0ELu7pH048038@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm 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: Mon, 14 Jan 2013 21:56:09 -0000 TB --- 2013-01-14 20:02:02 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-01-14 20:02:02 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-01-14 20:02:02 - starting RELENG_9 tinderbox run for arm/arm TB --- 2013-01-14 20:02:02 - cleaning the object tree TB --- 2013-01-14 20:02:02 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-01-14 20:02:02 - cd /tinderbox/RELENG_9/arm/arm TB --- 2013-01-14 20:02:02 - /usr/local/bin/svn cleanup /src TB --- 2013-01-14 20:03:08 - /usr/local/bin/svn update /src TB --- 2013-01-14 20:04:55 - building world TB --- 2013-01-14 20:04:55 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 20:04:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 20:04:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 20:04:55 - SRCCONF=/dev/null TB --- 2013-01-14 20:04:55 - TARGET=arm TB --- 2013-01-14 20:04:55 - TARGET_ARCH=arm TB --- 2013-01-14 20:04:55 - TZ=UTC TB --- 2013-01-14 20:04:55 - __MAKE_CONF=/dev/null TB --- 2013-01-14 20:04:55 - cd /src TB --- 2013-01-14 20:04:55 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 14 20:04:56 UTC 2013 >>> 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 Mon Jan 14 21:16:30 UTC 2013 TB --- 2013-01-14 21:16:30 - cd /src/sys/arm/conf TB --- 2013-01-14 21:16:30 - /usr/sbin/config -m AVILA TB --- 2013-01-14 21:16:30 - building AVILA kernel TB --- 2013-01-14 21:16:30 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:16:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:16:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:16:30 - SRCCONF=/dev/null TB --- 2013-01-14 21:16:30 - TARGET=arm TB --- 2013-01-14 21:16:30 - TARGET_ARCH=arm TB --- 2013-01-14 21:16:30 - TZ=UTC TB --- 2013-01-14 21:16:30 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:16:30 - cd /src TB --- 2013-01-14 21:16:30 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Mon Jan 14 21:16:30 UTC 2013 >>> 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 >>> Kernel build for AVILA completed on Mon Jan 14 21:20:45 UTC 2013 TB --- 2013-01-14 21:20:45 - cd /src/sys/arm/conf TB --- 2013-01-14 21:20:45 - /usr/sbin/config -m BWCT TB --- 2013-01-14 21:20:45 - building BWCT kernel TB --- 2013-01-14 21:20:45 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:20:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:20:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:20:45 - SRCCONF=/dev/null TB --- 2013-01-14 21:20:45 - TARGET=arm TB --- 2013-01-14 21:20:45 - TARGET_ARCH=arm TB --- 2013-01-14 21:20:45 - TZ=UTC TB --- 2013-01-14 21:20:45 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:20:45 - cd /src TB --- 2013-01-14 21:20:45 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Mon Jan 14 21:20:45 UTC 2013 >>> 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 >>> Kernel build for BWCT completed on Mon Jan 14 21:23:24 UTC 2013 TB --- 2013-01-14 21:23:24 - cd /src/sys/arm/conf TB --- 2013-01-14 21:23:24 - /usr/sbin/config -m CAMBRIA TB --- 2013-01-14 21:23:24 - building CAMBRIA kernel TB --- 2013-01-14 21:23:24 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:23:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:23:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:23:24 - SRCCONF=/dev/null TB --- 2013-01-14 21:23:24 - TARGET=arm TB --- 2013-01-14 21:23:24 - TARGET_ARCH=arm TB --- 2013-01-14 21:23:24 - TZ=UTC TB --- 2013-01-14 21:23:24 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:23:24 - cd /src TB --- 2013-01-14 21:23:24 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Mon Jan 14 21:23:24 UTC 2013 >>> 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 >>> Kernel build for CAMBRIA completed on Mon Jan 14 21:27:07 UTC 2013 TB --- 2013-01-14 21:27:07 - cd /src/sys/arm/conf TB --- 2013-01-14 21:27:07 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-01-14 21:27:07 - building CNS11XXNAS kernel TB --- 2013-01-14 21:27:07 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:27:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:27:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:27:07 - SRCCONF=/dev/null TB --- 2013-01-14 21:27:07 - TARGET=arm TB --- 2013-01-14 21:27:07 - TARGET_ARCH=arm TB --- 2013-01-14 21:27:07 - TZ=UTC TB --- 2013-01-14 21:27:07 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:27:07 - cd /src TB --- 2013-01-14 21:27:07 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Mon Jan 14 21:27:07 UTC 2013 >>> 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 >>> Kernel build for CNS11XXNAS completed on Mon Jan 14 21:30:08 UTC 2013 TB --- 2013-01-14 21:30:08 - cd /src/sys/arm/conf TB --- 2013-01-14 21:30:08 - /usr/sbin/config -m CRB TB --- 2013-01-14 21:30:08 - building CRB kernel TB --- 2013-01-14 21:30:08 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:30:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:30:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:30:08 - SRCCONF=/dev/null TB --- 2013-01-14 21:30:08 - TARGET=arm TB --- 2013-01-14 21:30:08 - TARGET_ARCH=arm TB --- 2013-01-14 21:30:08 - TZ=UTC TB --- 2013-01-14 21:30:08 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:30:08 - cd /src TB --- 2013-01-14 21:30:08 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Mon Jan 14 21:30:08 UTC 2013 >>> 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 >>> Kernel build for CRB completed on Mon Jan 14 21:34:20 UTC 2013 TB --- 2013-01-14 21:34:20 - cd /src/sys/arm/conf TB --- 2013-01-14 21:34:20 - /usr/sbin/config -m DB-78XXX TB --- 2013-01-14 21:34:20 - building DB-78XXX kernel TB --- 2013-01-14 21:34:20 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:34:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:34:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:34:20 - SRCCONF=/dev/null TB --- 2013-01-14 21:34:20 - TARGET=arm TB --- 2013-01-14 21:34:20 - TARGET_ARCH=arm TB --- 2013-01-14 21:34:20 - TZ=UTC TB --- 2013-01-14 21:34:20 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:34:20 - cd /src TB --- 2013-01-14 21:34:20 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Mon Jan 14 21:34:20 UTC 2013 >>> 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 >>> Kernel build for DB-78XXX completed on Mon Jan 14 21:37:33 UTC 2013 TB --- 2013-01-14 21:37:33 - cd /src/sys/arm/conf TB --- 2013-01-14 21:37:33 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-01-14 21:37:34 - building DB-88F5XXX kernel TB --- 2013-01-14 21:37:34 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:37:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:37:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:37:34 - SRCCONF=/dev/null TB --- 2013-01-14 21:37:34 - TARGET=arm TB --- 2013-01-14 21:37:34 - TARGET_ARCH=arm TB --- 2013-01-14 21:37:34 - TZ=UTC TB --- 2013-01-14 21:37:34 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:37:34 - cd /src TB --- 2013-01-14 21:37:34 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Mon Jan 14 21:37:34 UTC 2013 >>> 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 >>> Kernel build for DB-88F5XXX completed on Mon Jan 14 21:40:21 UTC 2013 TB --- 2013-01-14 21:40:21 - cd /src/sys/arm/conf TB --- 2013-01-14 21:40:21 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-01-14 21:40:21 - building DB-88F6XXX kernel TB --- 2013-01-14 21:40:21 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:40:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:40:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:40:21 - SRCCONF=/dev/null TB --- 2013-01-14 21:40:21 - TARGET=arm TB --- 2013-01-14 21:40:21 - TARGET_ARCH=arm TB --- 2013-01-14 21:40:21 - TZ=UTC TB --- 2013-01-14 21:40:21 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:40:21 - cd /src TB --- 2013-01-14 21:40:21 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Mon Jan 14 21:40:22 UTC 2013 >>> 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 >>> Kernel build for DB-88F6XXX completed on Mon Jan 14 21:43:41 UTC 2013 TB --- 2013-01-14 21:43:41 - cd /src/sys/arm/conf TB --- 2013-01-14 21:43:41 - /usr/sbin/config -m DOCKSTAR TB --- 2013-01-14 21:43:41 - building DOCKSTAR kernel TB --- 2013-01-14 21:43:41 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:43:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:43:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:43:41 - SRCCONF=/dev/null TB --- 2013-01-14 21:43:41 - TARGET=arm TB --- 2013-01-14 21:43:41 - TARGET_ARCH=arm TB --- 2013-01-14 21:43:41 - TZ=UTC TB --- 2013-01-14 21:43:41 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:43:41 - cd /src TB --- 2013-01-14 21:43:41 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Mon Jan 14 21:43:41 UTC 2013 >>> 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 >>> Kernel build for DOCKSTAR completed on Mon Jan 14 21:46:11 UTC 2013 TB --- 2013-01-14 21:46:11 - cd /src/sys/arm/conf TB --- 2013-01-14 21:46:11 - /usr/sbin/config -m EP80219 TB --- 2013-01-14 21:46:12 - building EP80219 kernel TB --- 2013-01-14 21:46:12 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:46:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:46:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:46:12 - SRCCONF=/dev/null TB --- 2013-01-14 21:46:12 - TARGET=arm TB --- 2013-01-14 21:46:12 - TARGET_ARCH=arm TB --- 2013-01-14 21:46:12 - TZ=UTC TB --- 2013-01-14 21:46:12 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:46:12 - cd /src TB --- 2013-01-14 21:46:12 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Mon Jan 14 21:46:12 UTC 2013 >>> 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 >>> Kernel build for EP80219 completed on Mon Jan 14 21:50:01 UTC 2013 TB --- 2013-01-14 21:50:01 - cd /src/sys/arm/conf TB --- 2013-01-14 21:50:01 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-01-14 21:50:02 - building ETHERNUT5 kernel TB --- 2013-01-14 21:50:02 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:50:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:50:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:50:02 - SRCCONF=/dev/null TB --- 2013-01-14 21:50:02 - TARGET=arm TB --- 2013-01-14 21:50:02 - TARGET_ARCH=arm TB --- 2013-01-14 21:50:02 - TZ=UTC TB --- 2013-01-14 21:50:02 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:50:02 - cd /src TB --- 2013-01-14 21:50:02 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Mon Jan 14 21:50:02 UTC 2013 >>> 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 -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/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/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9280_olc.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/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/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/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/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_reset.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/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/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-14 21:56:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-14 21:56:07 - ERROR: failed to build ETHERNUT5 kernel TB --- 2013-01-14 21:56:07 - 4544.38 user 794.79 system 6845.50 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 23:58:55 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 989EB933; Mon, 14 Jan 2013 23:58:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 49F10618; Mon, 14 Jan 2013 23:58:55 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r0ENws1Z051709; Mon, 14 Jan 2013 23:58:54 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r0ENwstx051692; Mon, 14 Jan 2013 23:58:54 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 Jan 2013 23:58:54 GMT Message-Id: <201301142358.r0ENwstx051692@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 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: Mon, 14 Jan 2013 23:58:55 -0000 TB --- 2013-01-14 21:56:08 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-01-14 21:56:08 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-01-14 21:56:08 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2013-01-14 21:56:08 - cleaning the object tree TB --- 2013-01-14 21:56:08 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-01-14 21:56:08 - cd /tinderbox/RELENG_9/ia64/ia64 TB --- 2013-01-14 21:56:08 - /usr/local/bin/svn cleanup /src TB --- 2013-01-14 21:57:11 - /usr/local/bin/svn update /src TB --- 2013-01-14 21:58:44 - building world TB --- 2013-01-14 21:58:44 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:58:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:58:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:58:44 - SRCCONF=/dev/null TB --- 2013-01-14 21:58:44 - TARGET=ia64 TB --- 2013-01-14 21:58:44 - TARGET_ARCH=ia64 TB --- 2013-01-14 21:58:44 - TZ=UTC TB --- 2013-01-14 21:58:44 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:58:44 - cd /src TB --- 2013-01-14 21:58:44 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 14 21:58:46 UTC 2013 >>> 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 Mon Jan 14 23:51:21 UTC 2013 TB --- 2013-01-14 23:51:21 - generating LINT kernel config TB --- 2013-01-14 23:51:21 - cd /src/sys/ia64/conf TB --- 2013-01-14 23:51:21 - /usr/bin/make -B LINT TB --- 2013-01-14 23:51:21 - cd /src/sys/ia64/conf TB --- 2013-01-14 23:51:21 - /usr/sbin/config -m LINT TB --- 2013-01-14 23:51:21 - building LINT kernel TB --- 2013-01-14 23:51:21 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 23:51:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 23:51:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 23:51:21 - SRCCONF=/dev/null TB --- 2013-01-14 23:51:21 - TARGET=ia64 TB --- 2013-01-14 23:51:21 - TARGET_ARCH=ia64 TB --- 2013-01-14 23:51:21 - TZ=UTC TB --- 2013-01-14 23:51:21 - __MAKE_CONF=/dev/null TB --- 2013-01-14 23:51:21 - cd /src TB --- 2013-01-14 23:51:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 14 23:51:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar9001/ar9160_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_olc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-14 23:58:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-14 23:58:54 - ERROR: failed to build LINT kernel TB --- 2013-01-14 23:58:54 - 5080.38 user 699.75 system 7366.52 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 00:46:09 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6D8EFD32; Tue, 15 Jan 2013 00:46:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE7787B; Tue, 15 Jan 2013 00:46:09 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r0F0k8BC039126; Tue, 15 Jan 2013 00:46:08 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r0F0k8uT039120; Tue, 15 Jan 2013 00:46:08 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 Jan 2013 00:46:08 GMT Message-Id: <201301150046.r0F0k8uT039120@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 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: Tue, 15 Jan 2013 00:46:09 -0000 TB --- 2013-01-14 21:37:09 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-01-14 21:37:09 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-01-14 21:37:09 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2013-01-14 21:37:09 - cleaning the object tree TB --- 2013-01-14 21:37:09 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-01-14 21:37:09 - cd /tinderbox/RELENG_9/i386/i386 TB --- 2013-01-14 21:37:09 - /usr/local/bin/svn cleanup /src TB --- 2013-01-14 21:38:20 - /usr/local/bin/svn update /src TB --- 2013-01-14 21:39:45 - building world TB --- 2013-01-14 21:39:45 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:39:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:39:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:39:45 - SRCCONF=/dev/null TB --- 2013-01-14 21:39:45 - TARGET=i386 TB --- 2013-01-14 21:39:45 - TARGET_ARCH=i386 TB --- 2013-01-14 21:39:45 - TZ=UTC TB --- 2013-01-14 21:39:45 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:39:45 - cd /src TB --- 2013-01-14 21:39:45 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 14 21:39:46 UTC 2013 >>> 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 Tue Jan 15 00:37:33 UTC 2013 TB --- 2013-01-15 00:37:33 - generating LINT kernel config TB --- 2013-01-15 00:37:33 - cd /src/sys/i386/conf TB --- 2013-01-15 00:37:33 - /usr/bin/make -B LINT TB --- 2013-01-15 00:37:33 - cd /src/sys/i386/conf TB --- 2013-01-15 00:37:33 - /usr/sbin/config -m LINT TB --- 2013-01-15 00:37:33 - building LINT kernel TB --- 2013-01-15 00:37:33 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 00:37:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 00:37:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 00:37:33 - SRCCONF=/dev/null TB --- 2013-01-15 00:37:33 - TARGET=i386 TB --- 2013-01-15 00:37:33 - TARGET_ARCH=i386 TB --- 2013-01-15 00:37:33 - TZ=UTC TB --- 2013-01-15 00:37:33 - __MAKE_CONF=/dev/null TB --- 2013-01-15 00:37:33 - cd /src TB --- 2013-01-15 00:37:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 15 00:37:33 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar9001/ar9160_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar9002/ar9280_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar9002/ar9280_olc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-15 00:46:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-15 00:46:08 - ERROR: failed to build LINT kernel TB --- 2013-01-15 00:46:08 - 8164.91 user 932.32 system 11339.42 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 00:50:57 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0D061EA9; Tue, 15 Jan 2013 00:50:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id AB84F8BB; Tue, 15 Jan 2013 00:50:56 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r0F0ouqf063609; Tue, 15 Jan 2013 00:50:56 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r0F0ourX063608; Tue, 15 Jan 2013 00:50:56 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 Jan 2013 00:50:56 GMT Message-Id: <201301150050.r0F0ourX063608@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 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: Tue, 15 Jan 2013 00:50:57 -0000 TB --- 2013-01-14 21:42:31 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-01-14 21:42:31 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-01-14 21:42:31 - starting RELENG_9 tinderbox run for i386/pc98 TB --- 2013-01-14 21:42:31 - cleaning the object tree TB --- 2013-01-14 21:42:31 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-01-14 21:42:31 - cd /tinderbox/RELENG_9/i386/pc98 TB --- 2013-01-14 21:42:31 - /usr/local/bin/svn cleanup /src TB --- 2013-01-14 21:43:49 - /usr/local/bin/svn update /src TB --- 2013-01-14 21:45:28 - building world TB --- 2013-01-14 21:45:28 - CROSS_BUILD_TESTING=YES TB --- 2013-01-14 21:45:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-14 21:45:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-14 21:45:28 - SRCCONF=/dev/null TB --- 2013-01-14 21:45:28 - TARGET=pc98 TB --- 2013-01-14 21:45:28 - TARGET_ARCH=i386 TB --- 2013-01-14 21:45:28 - TZ=UTC TB --- 2013-01-14 21:45:28 - __MAKE_CONF=/dev/null TB --- 2013-01-14 21:45:28 - cd /src TB --- 2013-01-14 21:45:28 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 14 21:45:30 UTC 2013 >>> 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 Tue Jan 15 00:43:32 UTC 2013 TB --- 2013-01-15 00:43:32 - generating LINT kernel config TB --- 2013-01-15 00:43:32 - cd /src/sys/pc98/conf TB --- 2013-01-15 00:43:32 - /usr/bin/make -B LINT TB --- 2013-01-15 00:43:33 - cd /src/sys/pc98/conf TB --- 2013-01-15 00:43:33 - /usr/sbin/config -m LINT TB --- 2013-01-15 00:43:33 - building LINT kernel TB --- 2013-01-15 00:43:33 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 00:43:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 00:43:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 00:43:33 - SRCCONF=/dev/null TB --- 2013-01-15 00:43:33 - TARGET=pc98 TB --- 2013-01-15 00:43:33 - TARGET_ARCH=i386 TB --- 2013-01-15 00:43:33 - TZ=UTC TB --- 2013-01-15 00:43:33 - __MAKE_CONF=/dev/null TB --- 2013-01-15 00:43:33 - cd /src TB --- 2013-01-15 00:43:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 15 00:43:33 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar9001/ar9160_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar9002/ar9280_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar9002/ar9280_olc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-15 00:50:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-15 00:50:56 - ERROR: failed to build LINT kernel TB --- 2013-01-15 00:50:56 - 8063.30 user 939.12 system 11304.47 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 01:42:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63985B2F for ; Tue, 15 Jan 2013 01:42:41 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vb0-f68.google.com (mail-vb0-f68.google.com [209.85.212.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2AE5CA88 for ; Tue, 15 Jan 2013 01:42:40 +0000 (UTC) Received: by mail-vb0-f68.google.com with SMTP id s24so1118536vbi.3 for ; Mon, 14 Jan 2013 17:42:40 -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=59k97XRStN/XlnCHXHnJQAkq8GPwmtn5nOwvkXKjLWM=; b=TLJb2X2bqw9/1VTp0TeAjW6FzPu7hX2hUfXCTp3EhUhENvdkjHDXJ58axn6P4najyN wXkeS3gKDKmr2hFcCYBkZFi3LgNVOjucpiH3FZ2a7kEKe6ULarEgPvWfgDBfb5OzRJM9 +m0Mrps/prp7kHNQfVzoQq3KK0yB/IA0mJSiI78dJ/CBvQOrdDdVUf8N1pCKXxxwCaYa 242M+UWihVs5XfLjApbCLkuQhiBqdEb1LbnOf7P66+rquf6pq9KWSLoOG8UO2QxPFGIy pS9wv8fdZeEZ0JwTVkITT0Q9wQP1WF/TGXDGqR7RoMjNOZLZHHYGVvYb1PtDu7WpTRQ+ PYag== MIME-Version: 1.0 Received: by 10.52.178.225 with SMTP id db1mr92399528vdc.10.1358214160233; Mon, 14 Jan 2013 17:42:40 -0800 (PST) Received: by 10.58.152.42 with HTTP; Mon, 14 Jan 2013 17:42:40 -0800 (PST) Date: Mon, 14 Jan 2013 20:42:40 -0500 Message-ID: Subject: IPv6 Tunnel Shared With Jails via epair Devices From: Shawn Webb To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 15 Jan 2013 01:42:41 -0000 Hey All, I've been working on sharing a 6in4 IPv6 tunnel (via a gif device) I have with Hurricane Electric (tunnelbroker.net) to my jails via epair devices. My setup is a bit unique in that the IPv6 tunnel is behind an OpenVPN connection. I've had varying degrees of success. I might have a bug to report, but I thought I'd post here to get input from people who know better than I do about these kinds of things. I have a bridge device (we'll call it bridge0) with a /64 IPv6 address (2001:470:8142:1::1). Each jail's epair[n]b device will get an IPv6 address in that same prefix. For example, one of my jails is 2001:470:8142:1::3. The default IPv6 gateway is the IPv6 address of bridge0. Giving one jail an IP address works fine. For each jail after that, the IPv6 address stays in tentative mode. FreeBSD gets stuck trying to use DAD to figure out if there's an address conflict. It never leaves tentative mode. This is the bug I'm working out. Here's bridge0's config: # ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 ether 02:fe:21:34:d3:00 inet6 2001:470:8142:1::1 prefixlen 64 nd6 options=21 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: epair0a flags=143 ifmaxaddr 0 port 19 priority 128 path cost 2000 member: epair1a flags=143 ifmaxaddr 0 port 21 priority 128 path cost 2000 member: bge0 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 200000 Here's the relevant epair device for the jail whose IPv6 stack is working: # jexec "ClamAV_Dev" ifconfig epair1b epair1b: flags=8843 metric 0 mtu 1500 options=8 ether 02:fb:c0:00:16:0b inet6 2001:470:8142:1::3 prefixlen 64 inet6 fe80::fb:c0ff:fe00:160b%epair1b prefixlen 64 scopeid 0x2 inet 10.7.1.172 netmask 0xfffffe00 broadcast 10.7.1.255 nd6 options=21 media: Ethernet 10Gbase-T (10Gbase-T ) status: active Here's the relevant epair device for the jail whose IPv6 stack isn't working: # jexec "Dev Template" ifconfig epair0b epair0b: flags=8843 metric 0 mtu 1500 options=8 ether 02:80:03:00:14:0b inet6 2001:470:8142:1::5 prefixlen 64 tentative inet6 fe80::80:3ff:fe00:140b%epair0b prefixlen 64 tentative scopeid 0x2 inet 10.7.1.92 netmask 0xfffffe00 broadcast 10.7.1.255 nd6 options=29 media: Ethernet 10Gbase-T (10Gbase-T ) status: active I brought up the "Dev Template" jail after bringing up the ClamAV_Dev jail. If there's any other output you'd like to see, let me know. If you're confused about my setup, visit my blog post about the subject here: http://0xfeedface.org/blog/lattera/2013-01-12/tunneled-ipv6-freebsd-jails I'm curious to know if I've got a legit bug or if it's something I'm doing wrong. The one thing I haven't tried is setting up rtadvd on the bridge. That'd be kindof interesting, since my physical NIC is a member on the bridge. I'd rather not dish out IPv6 addresses for all devices on the network (a network with lots of devices I don't own or control). Thanks, Shawn From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 02:55:46 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1CBBFBB8; Tue, 15 Jan 2013 02:55:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id BDF51E0D; Tue, 15 Jan 2013 02:55:45 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r0F2tjVd089923; Tue, 15 Jan 2013 02:55:45 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r0F2tj3T089918; Tue, 15 Jan 2013 02:55:45 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 Jan 2013 02:55:45 GMT Message-Id: <201301150255.r0F2tj3T089918@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 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: Tue, 15 Jan 2013 02:55:46 -0000 TB --- 2013-01-15 01:14:40 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-01-15 01:14:40 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-01-15 01:14:40 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2013-01-15 01:14:40 - cleaning the object tree TB --- 2013-01-15 01:14:40 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-01-15 01:14:40 - cd /tinderbox/RELENG_9/sparc64/sparc64 TB --- 2013-01-15 01:14:40 - /usr/local/bin/svn cleanup /src TB --- 2013-01-15 01:15:21 - /usr/local/bin/svn update /src TB --- 2013-01-15 01:17:00 - building world TB --- 2013-01-15 01:17:00 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 01:17:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 01:17:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 01:17:00 - SRCCONF=/dev/null TB --- 2013-01-15 01:17:00 - TARGET=sparc64 TB --- 2013-01-15 01:17:00 - TARGET_ARCH=sparc64 TB --- 2013-01-15 01:17:00 - TZ=UTC TB --- 2013-01-15 01:17:00 - __MAKE_CONF=/dev/null TB --- 2013-01-15 01:17:00 - cd /src TB --- 2013-01-15 01:17:00 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 15 01:17:01 UTC 2013 >>> 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 Tue Jan 15 02:48:21 UTC 2013 TB --- 2013-01-15 02:48:21 - generating LINT kernel config TB --- 2013-01-15 02:48:21 - cd /src/sys/sparc64/conf TB --- 2013-01-15 02:48:21 - /usr/bin/make -B LINT TB --- 2013-01-15 02:48:22 - cd /src/sys/sparc64/conf TB --- 2013-01-15 02:48:22 - /usr/sbin/config -m LINT TB --- 2013-01-15 02:48:22 - building LINT kernel TB --- 2013-01-15 02:48:22 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 02:48:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 02:48:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 02:48:22 - SRCCONF=/dev/null TB --- 2013-01-15 02:48:22 - TARGET=sparc64 TB --- 2013-01-15 02:48:22 - TARGET_ARCH=sparc64 TB --- 2013-01-15 02:48:22 - TZ=UTC TB --- 2013-01-15 02:48:22 - __MAKE_CONF=/dev/null TB --- 2013-01-15 02:48:22 - cd /src TB --- 2013-01-15 02:48:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 15 02:48:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9001/ar9160_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_olc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-15 02:55:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-15 02:55:44 - ERROR: failed to build LINT kernel TB --- 2013-01-15 02:55:44 - 3851.46 user 610.80 system 6064.34 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 03:39:48 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4FD98C78; Tue, 15 Jan 2013 03:39:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id E817F163; Tue, 15 Jan 2013 03:39:47 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r0F3dlrh057794; Tue, 15 Jan 2013 03:39:47 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r0F3dlLU057789; Tue, 15 Jan 2013 03:39:47 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 Jan 2013 03:39:47 GMT Message-Id: <201301150339.r0F3dlLU057789@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on powerpc/powerpc 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: Tue, 15 Jan 2013 03:39:48 -0000 TB --- 2013-01-15 00:46:08 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-01-15 00:46:08 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-01-15 00:46:08 - starting RELENG_9 tinderbox run for powerpc/powerpc TB --- 2013-01-15 00:46:08 - cleaning the object tree TB --- 2013-01-15 00:46:08 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-01-15 00:46:08 - cd /tinderbox/RELENG_9/powerpc/powerpc TB --- 2013-01-15 00:46:08 - /usr/local/bin/svn cleanup /src TB --- 2013-01-15 00:47:10 - /usr/local/bin/svn update /src TB --- 2013-01-15 00:48:53 - building world TB --- 2013-01-15 00:48:53 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 00:48:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 00:48:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 00:48:53 - SRCCONF=/dev/null TB --- 2013-01-15 00:48:53 - TARGET=powerpc TB --- 2013-01-15 00:48:53 - TARGET_ARCH=powerpc TB --- 2013-01-15 00:48:53 - TZ=UTC TB --- 2013-01-15 00:48:53 - __MAKE_CONF=/dev/null TB --- 2013-01-15 00:48:53 - cd /src TB --- 2013-01-15 00:48:53 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 15 00:48:54 UTC 2013 >>> 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 Tue Jan 15 03:36:23 UTC 2013 TB --- 2013-01-15 03:36:23 - generating LINT kernel config TB --- 2013-01-15 03:36:23 - cd /src/sys/powerpc/conf TB --- 2013-01-15 03:36:23 - /usr/bin/make -B LINT TB --- 2013-01-15 03:36:23 - cd /src/sys/powerpc/conf TB --- 2013-01-15 03:36:23 - /usr/sbin/config -m LINT TB --- 2013-01-15 03:36:23 - building LINT kernel TB --- 2013-01-15 03:36:23 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 03:36:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 03:36:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 03:36:23 - SRCCONF=/dev/null TB --- 2013-01-15 03:36:23 - TARGET=powerpc TB --- 2013-01-15 03:36:23 - TARGET_ARCH=powerpc TB --- 2013-01-15 03:36:23 - TZ=UTC TB --- 2013-01-15 03:36:23 - __MAKE_CONF=/dev/null TB --- 2013-01-15 03:36:23 - cd /src TB --- 2013-01-15 03:36:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 15 03:36:23 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9001/ar9160_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_olc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-15 03:39:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-15 03:39:47 - ERROR: failed to build LINT kernel TB --- 2013-01-15 03:39:47 - 7829.75 user 846.78 system 10418.46 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 04:03:50 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 63E69602; Tue, 15 Jan 2013 04:03:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 12D152B5; Tue, 15 Jan 2013 04:03:49 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r0F43nSE052834; Tue, 15 Jan 2013 04:03:49 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r0F43nDQ052833; Tue, 15 Jan 2013 04:03:49 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 Jan 2013 04:03:49 GMT Message-Id: <201301150403.r0F43nDQ052833@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on powerpc64/powerpc 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: Tue, 15 Jan 2013 04:03:50 -0000 TB --- 2013-01-15 00:50:56 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-01-15 00:50:56 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-01-15 00:50:56 - starting RELENG_9 tinderbox run for powerpc64/powerpc TB --- 2013-01-15 00:50:56 - cleaning the object tree TB --- 2013-01-15 00:50:56 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-01-15 00:50:56 - cd /tinderbox/RELENG_9/powerpc64/powerpc TB --- 2013-01-15 00:50:56 - /usr/local/bin/svn cleanup /src TB --- 2013-01-15 00:51:53 - /usr/local/bin/svn update /src TB --- 2013-01-15 00:53:33 - building world TB --- 2013-01-15 00:53:33 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 00:53:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 00:53:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 00:53:33 - SRCCONF=/dev/null TB --- 2013-01-15 00:53:33 - TARGET=powerpc TB --- 2013-01-15 00:53:33 - TARGET_ARCH=powerpc64 TB --- 2013-01-15 00:53:33 - TZ=UTC TB --- 2013-01-15 00:53:33 - __MAKE_CONF=/dev/null TB --- 2013-01-15 00:53:33 - cd /src TB --- 2013-01-15 00:53:33 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 15 00:53:34 UTC 2013 >>> 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 Tue Jan 15 04:00:56 UTC 2013 TB --- 2013-01-15 04:00:56 - generating LINT kernel config TB --- 2013-01-15 04:00:56 - cd /src/sys/powerpc/conf TB --- 2013-01-15 04:00:56 - /usr/bin/make -B LINT TB --- 2013-01-15 04:00:56 - cd /src/sys/powerpc/conf TB --- 2013-01-15 04:00:56 - /usr/sbin/config -m LINT TB --- 2013-01-15 04:00:56 - building LINT kernel TB --- 2013-01-15 04:00:56 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 04:00:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 04:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 04:00:56 - SRCCONF=/dev/null TB --- 2013-01-15 04:00:56 - TARGET=powerpc TB --- 2013-01-15 04:00:56 - TARGET_ARCH=powerpc64 TB --- 2013-01-15 04:00:56 - TZ=UTC TB --- 2013-01-15 04:00:56 - __MAKE_CONF=/dev/null TB --- 2013-01-15 04:00:56 - cd /src TB --- 2013-01-15 04:00:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 15 04:00:56 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9001/ar9160_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_olc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-15 04:03:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-15 04:03:49 - ERROR: failed to build LINT kernel TB --- 2013-01-15 04:03:49 - 8724.62 user 1022.18 system 11573.02 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 05:29:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF217EFD for ; Tue, 15 Jan 2013 05:29:46 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id B7331A02 for ; Tue, 15 Jan 2013 05:29:46 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 7B493450BB; Tue, 15 Jan 2013 05:29:39 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk 7B493450BB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1358227780; bh=KeC55uomjt/5IPP2T0eO8P6cfyQe6ftZ51i+m0Wnabs=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: In-Reply-To; b=AEp0xb3gkicfGcWDHY5gE46HMB6+5AqJ6auzxbq4G+ykKxxs8e2bmu6+w5gG8z5vg GDVNZvM8QR+aPX119A9jqsrX4IfcROvw+n7rfqLRZ7pkYnB16Q4wddCdgMrea50KTr OkrqILhRKnwefCfg6Nn90Twm/xPzuMQwhTgiG8j8= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 42A158692; Tue, 15 Jan 2013 05:29:37 +0000 (GMT) Date: Tue, 15 Jan 2013 05:29:37 +0000 From: Ben Morrow To: lattera@gmail.com, freebsd-stable@freebsd.org Subject: Re: IPv6 Tunnel Shared With Jails via epair Devices Message-ID: <20130115052937.GA44328@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk 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: Tue, 15 Jan 2013 05:29:46 -0000 Quoth Shawn Webb : > > I've been working on sharing a 6in4 IPv6 tunnel (via a gif device) I have > with Hurricane Electric (tunnelbroker.net) to my jails via epair devices. > My setup is a bit unique in that the IPv6 tunnel is behind an OpenVPN > connection. I've had varying degrees of success. I might have a bug to > report, but I thought I'd post here to get input from people who know > better than I do about these kinds of things. > > I have a bridge device (we'll call it bridge0) with a /64 IPv6 address > (2001:470:8142:1::1). Each jail's epair[n]b device will get an IPv6 address > in that same prefix. For example, one of my jails is 2001:470:8142:1::3. > The default IPv6 gateway is the IPv6 address of bridge0. > > Giving one jail an IP address works fine. For each jail after that, the > IPv6 address stays in tentative mode. FreeBSD gets stuck trying to use DAD > to figure out if there's an address conflict. It never leaves tentative > mode. This is the bug I'm working out. > > Here's bridge0's config: > > # ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu > 1500 > ether 02:fe:21:34:d3:00 > inet6 2001:470:8142:1::1 prefixlen 64 > nd6 options=21 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: epair0a flags=143 > ifmaxaddr 0 port 19 priority 128 path cost 2000 > member: epair1a flags=143 > ifmaxaddr 0 port 21 priority 128 path cost 2000 > member: bge0 flags=143 > ifmaxaddr 0 port 5 priority 128 path cost 200000 Why have you added the physical interface to the bridge? AFAICT you don't need to: a bridge will bridge epairs just fine, and as you explained in that blog post you have to route rather than bridge into the tunnel, since the tunnel isn't an Ethernet device. > Here's the relevant epair device for the jail whose IPv6 stack is working: > > # jexec "ClamAV_Dev" ifconfig epair1b > epair1b: flags=8843 metric 0 mtu > 1500 > options=8 > ether 02:fb:c0:00:16:0b > inet6 2001:470:8142:1::3 prefixlen 64 > inet6 fe80::fb:c0ff:fe00:160b%epair1b prefixlen 64 scopeid 0x2 > inet 10.7.1.172 netmask 0xfffffe00 broadcast 10.7.1.255 > nd6 options=21 > media: Ethernet 10Gbase-T (10Gbase-T ) > status: active > > Here's the relevant epair device for the jail whose IPv6 stack isn't > working: > > # jexec "Dev Template" ifconfig epair0b > epair0b: flags=8843 metric 0 mtu > 1500 > options=8 > ether 02:80:03:00:14:0b > inet6 2001:470:8142:1::5 prefixlen 64 tentative > inet6 fe80::80:3ff:fe00:140b%epair0b prefixlen 64 tentative scopeid 0x2 > inet 10.7.1.92 netmask 0xfffffe00 broadcast 10.7.1.255 > nd6 options=29 I suspect the addresses are only marked tentative because the interface has been marked IFDISABLED. This causes all current addresses to be marked tentative, because the kernel isn't allowed to send or receive IPv6 packets and so can't defend the addresses any more. Is it possible something in the jail's startup scripts is causing the interface to be marked IFDISABLED after the inet6 address has been assigned? Some of the functions in network.subr mark interfaces IFDISABLED automatically if they don't think they have IPv6 addresses. > media: Ethernet 10Gbase-T (10Gbase-T ) > status: active > > I brought up the "Dev Template" jail after bringing up the ClamAV_Dev jail. > If there's any other output you'd like to see, let me know. If you're > confused about my setup, visit my blog post about the subject here: > http://0xfeedface.org/blog/lattera/2013-01-12/tunneled-ipv6-freebsd-jails > > I'm curious to know if I've got a legit bug or if it's something I'm doing > wrong. The one thing I haven't tried is setting up rtadvd on the bridge. > That'd be kindof interesting, since my physical NIC is a member on the > bridge. I'd rather not dish out IPv6 addresses for all devices on the > network (a network with lots of devices I don't own or control). As I said, I don't believe you need the physical interface on the bridge, unless you have to for IPv4 (and you can't route or proxyarp instead). However, before you can run rtadvd you will need to give the bridge its proper link-local address, which probably also means locking down its hardware address in rc.conf. Bridges don't get auto link-local addresses, for reasons I've never entirely understood, and RAs have to use ll addresses. You will need to set up routing so that packets coming in through the tunnel destined for the jails get routed out of the bridge, and packets coming in on the bridge destined for the IPv6 Internet get routed out of the tunnel. Probably that will have happened already, just by assigning an inet6 address and prefixlen to the bridge and the default inet6 route to the tunnel. Ben From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 05:49:01 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2BFE6B5 for ; Tue, 15 Jan 2013 05:49:01 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by mx1.freebsd.org (Postfix) with ESMTP id 20A58AF2 for ; Tue, 15 Jan 2013 05:49:00 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id fq13so4703472lab.33 for ; Mon, 14 Jan 2013 21:48:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :user-agent:mime-version:to:subject:openpgp:content-type :content-transfer-encoding:x-gm-message-state; bh=fIrR+uCe7lOf1a3Z4Gr522bRiQGjOpbRejRzjroferE=; b=SnLOPqVVwuav/FwSbYLBiefSfo9WH8hbTuW0EIKEFBbc78dOtC76oEbPceISVu5DbR jWSwM4jAtEx0kN32CROAU7JDqwpz2JmKKvkZHcPauBc/0K0DVD9VSZwNnr8fobb0vCqx NBh7uz4HQ4C4UWf+9/ENnA3BaSt+cel269fjVhPw6mwNlNorsIxpXshTvQV1n8Q5NZeS wZltrSryK19cAg4/8a2aWAoW5pdcfnw5xfrYibZL5wu5HqORqzAxPiBFMFPIyMXCux6G GAxYoaSCtstjaWicR3S+dlHnh/jPq+2WwdekryexE+PV9nT2+ZFSRN+8aN+WvPwJmrhs cUaQ== X-Received: by 10.112.45.232 with SMTP id q8mr36535449lbm.23.1358228939710; Mon, 14 Jan 2013 21:48:59 -0800 (PST) Received: from [192.168.1.2] ([89.169.163.3]) by mx.google.com with ESMTPS id hm5sm6154800lab.6.2013.01.14.21.48.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 21:48:59 -0800 (PST) Message-ID: <50F4EDC9.8090205@freebsd.org> Date: Tue, 15 Jan 2013 09:48:57 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: stable@freebsd.org, dim@freebsd.org Subject: kernel's make fails in ath module, stable9 OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQndL9zNGtPrcauTaLVkQtWy4gXHgaWnChA6aFpHVoiMaYz8FWuzVXLAcDoZQU0IOWkeG/KP 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, 15 Jan 2013 05:49:01 -0000 Most recent -stable. Please fix: ... cc -O2 -pipe -march=prescott -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /usr/src/sys/i386/compile/POBRECITA/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/src/sys/i386/compile/POBRECITA -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** [ar9285_attach.o] Error code 1 Stop in /usr/src/sys/modules/ath. *** [all] Error code 1 Stop in /usr/src/sys/modules. *** [modules-all] Error code 1 -- http://ache.vniz.net/ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 07:44:28 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 951C9513 for ; Tue, 15 Jan 2013 07:44:28 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6001E1C5 for ; Tue, 15 Jan 2013 07:44:28 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:d8d8:1399:7768:60b9] (unknown [IPv6:2001:7b8:3a7:0:d8d8:1399:7768:60b9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 68A085C37 for ; Tue, 15 Jan 2013 08:44:25 +0100 (CET) Message-ID: <50F508D7.8070802@andric.com> Date: Tue, 15 Jan 2013 08:44:23 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: stable@freebsd.org Subject: Re: [releng_9 tinderbox] failure on arm/arm References: <201301142156.r0ELu7pH048038@freebsd-stable.sentex.ca> In-Reply-To: <201301142156.r0ELu7pH048038@freebsd-stable.sentex.ca> 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: Tue, 15 Jan 2013 07:44:28 -0000 On 2013-01-14 22:56, FreeBSD Tinderbox wrote: > TB --- 2013-01-14 20:02:02 - tinderbox 2.10 running on freebsd-stable.sentex.ca > TB --- 2013-01-14 20:02:02 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 > TB --- 2013-01-14 20:02:02 - starting RELENG_9 tinderbox run for arm/arm ... > cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/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/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c > /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': > /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) > /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once > /src/sys/modules/ath/../../dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) Sorry for breaking this, it should be fixed with r245449. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 11:30:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EA0F134 for ; Tue, 15 Jan 2013 11:30:16 +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 03069E90 for ; Tue, 15 Jan 2013 11:30:15 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Tv4ic-0002pJ-A4 for freebsd-stable@freebsd.org; Tue, 15 Jan 2013 03:30:14 -0800 Date: Tue, 15 Jan 2013 03:30:14 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1358249414281-5777859.post@n5.nabble.com> In-Reply-To: <50F4EDC9.8090205@freebsd.org> References: <50F4EDC9.8090205@freebsd.org> Subject: Re: kernel's make fails in ath module, stable9 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: Tue, 15 Jan 2013 11:30:16 -0000 See tinderbox log, my -wirelesss mail etc. I'm waiting for a fix too. -- View this message in context: http://freebsd.1045724.n5.nabble.com/kernel-s-make-fails-in-ath-module-stable9-tp5777779p5777859.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 11:31:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F24482D4 for ; Tue, 15 Jan 2013 11:31:45 +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 D358BEC2 for ; Tue, 15 Jan 2013 11:31:45 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Tv4k5-0006Rq-7a for freebsd-stable@freebsd.org; Tue, 15 Jan 2013 03:31:45 -0800 Date: Tue, 15 Jan 2013 03:31:45 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1358249505210-5777864.post@n5.nabble.com> In-Reply-To: <1358249414281-5777859.post@n5.nabble.com> References: <50F4EDC9.8090205@freebsd.org> <1358249414281-5777859.post@n5.nabble.com> Subject: Re: kernel's make fails in ath module, stable9 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: Tue, 15 Jan 2013 11:31:46 -0000 ...should be fixed, as it is already reverted. -- View this message in context: http://freebsd.1045724.n5.nabble.com/kernel-s-make-fails-in-ath-module-stable9-tp5777779p5777864.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 14:06:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 043AF98A for ; Tue, 15 Jan 2013 14:06:45 +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 B7F03A15 for ; Tue, 15 Jan 2013 14:06:44 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:d8d8:1399:7768:60b9] (unknown [IPv6:2001:7b8:3a7:0:d8d8:1399:7768:60b9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4E3515C37; Tue, 15 Jan 2013 15:06:37 +0100 (CET) Message-ID: <50F5626B.8000404@FreeBSD.org> Date: Tue, 15 Jan 2013 15:06:35 +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: Jakub Lach Subject: Re: kernel's make fails in ath module, stable9 References: <50F4EDC9.8090205@freebsd.org> <1358249414281-5777859.post@n5.nabble.com> <1358249505210-5777864.post@n5.nabble.com> In-Reply-To: <1358249505210-5777864.post@n5.nabble.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: Tue, 15 Jan 2013 14:06:45 -0000 On 2013-01-15 12:31, Jakub Lach wrote: > ...should be fixed, as it is already reverted. Yes, sorry about that breakage. It should be fixed as of r245449. The good news is that stable/9 now has clang 3.2 release. :-) From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 14:55:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7E16A914 for ; Tue, 15 Jan 2013 14:55:52 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by mx1.freebsd.org (Postfix) with ESMTP id 44413DFA for ; Tue, 15 Jan 2013 14:55:52 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id j34so114345qco.23 for ; Tue, 15 Jan 2013 06:55:51 -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=sWevvWWjZm0YXhYj06JjvuvmmQkGoMoSHQ5X21ObgTw=; b=ySJxcsp0Tln3sEcZ3dciG6W3W3dvqcY1BSJoG4Aa+Af/AtRbbWPR8dwu5rF4MtXmcq Yr54wm+em+r+uI5kNW33cOiEupAXKYwCJtyML9DLMjOGrpRrIY9OADa76PFiiIl1M+1c T03U8XOcf4RTOc6KFvQ7ujcFI9uaeTYiAUk43RF+osbx0YUCpQozPZKc3sRGbvSQFE4p ypJhuU+hXz6H9P5YD7ZSEJXOh5ScLla05/r/0V9dIzYUumOJv3D9Jn2bTplM3aDIVgn+ ErYVkyJmFiaTYe/NfYMO8w2uUxKRDQ5viKxrYqRN+4GM8zLzmUkzOqgCR5MKwRjCj+jM auYQ== MIME-Version: 1.0 Received: by 10.224.181.135 with SMTP id by7mr72787664qab.51.1358261751621; Tue, 15 Jan 2013 06:55:51 -0800 (PST) Received: by 10.49.25.234 with HTTP; Tue, 15 Jan 2013 06:55:51 -0800 (PST) In-Reply-To: <20130115052937.GA44328@anubis.morrow.me.uk> References: <20130115052937.GA44328@anubis.morrow.me.uk> Date: Tue, 15 Jan 2013 09:55:51 -0500 Message-ID: Subject: Re: IPv6 Tunnel Shared With Jails via epair Devices From: Shawn Webb To: Ben Morrow Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.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: Tue, 15 Jan 2013 14:55:52 -0000 On Tue, Jan 15, 2013 at 12:29 AM, Ben Morrow wrote: > Quoth Shawn Webb : > > > > I've been working on sharing a 6in4 IPv6 tunnel (via a gif device) I have > > with Hurricane Electric (tunnelbroker.net) to my jails via epair > devices. > > My setup is a bit unique in that the IPv6 tunnel is behind an OpenVPN > > connection. I've had varying degrees of success. I might have a bug to > > report, but I thought I'd post here to get input from people who know > > better than I do about these kinds of things. > > > > I have a bridge device (we'll call it bridge0) with a /64 IPv6 address > > (2001:470:8142:1::1). Each jail's epair[n]b device will get an IPv6 > address > > in that same prefix. For example, one of my jails is 2001:470:8142:1::3. > > The default IPv6 gateway is the IPv6 address of bridge0. > > > > Giving one jail an IP address works fine. For each jail after that, the > > IPv6 address stays in tentative mode. FreeBSD gets stuck trying to use > DAD > > to figure out if there's an address conflict. It never leaves tentative > > mode. This is the bug I'm working out. > > > > Here's bridge0's config: > > > > # ifconfig bridge0 > > bridge0: flags=8843 metric 0 mtu > > 1500 > > ether 02:fe:21:34:d3:00 > > inet6 2001:470:8142:1::1 prefixlen 64 > > nd6 options=21 > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > member: epair0a flags=143 > > ifmaxaddr 0 port 19 priority 128 path cost 2000 > > member: epair1a flags=143 > > ifmaxaddr 0 port 21 priority 128 path cost 2000 > > member: bge0 flags=143 > > ifmaxaddr 0 port 5 priority 128 path cost 200000 > > Why have you added the physical interface to the bridge? AFAICT you > don't need to: a bridge will bridge epairs just fine, and as you > explained in that blog post you have to route rather than bridge into > the tunnel, since the tunnel isn't an Ethernet device. > I did it so that I have an IPv4 address directly on the LAN for each of my jails. > > > Here's the relevant epair device for the jail whose IPv6 stack is > working: > > > > # jexec "ClamAV_Dev" ifconfig epair1b > > epair1b: flags=8843 metric 0 mtu > > 1500 > > options=8 > > ether 02:fb:c0:00:16:0b > > inet6 2001:470:8142:1::3 prefixlen 64 > > inet6 fe80::fb:c0ff:fe00:160b%epair1b prefixlen 64 scopeid 0x2 > > inet 10.7.1.172 netmask 0xfffffe00 broadcast 10.7.1.255 > > nd6 options=21 > > media: Ethernet 10Gbase-T (10Gbase-T ) > > status: active > > > > Here's the relevant epair device for the jail whose IPv6 stack isn't > > working: > > > > # jexec "Dev Template" ifconfig epair0b > > epair0b: flags=8843 metric 0 mtu > > 1500 > > options=8 > > ether 02:80:03:00:14:0b > > inet6 2001:470:8142:1::5 prefixlen 64 tentative > > inet6 fe80::80:3ff:fe00:140b%epair0b prefixlen 64 tentative scopeid 0x2 > > inet 10.7.1.92 netmask 0xfffffe00 broadcast 10.7.1.255 > > nd6 options=29 > > I suspect the addresses are only marked tentative because the interface > has been marked IFDISABLED. This causes all current addresses to be > marked tentative, because the kernel isn't allowed to send or receive > IPv6 packets and so can't defend the addresses any more. > > Is it possible something in the jail's startup scripts is causing the > interface to be marked IFDISABLED after the inet6 address has been > assigned? Some of the functions in network.subr mark interfaces > IFDISABLED automatically if they don't think they have IPv6 addresses. > I was thinking the same thing. One problem is that I can't remove the IFDISABLED flag. This is what happens when I try: # jexec "Dev Template" ifconfig epair0b -ifdisabled ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument > > > media: Ethernet 10Gbase-T (10Gbase-T ) > > status: active > > > > I brought up the "Dev Template" jail after bringing up the ClamAV_Dev > jail. > > If there's any other output you'd like to see, let me know. If you're > > confused about my setup, visit my blog post about the subject here: > > > http://0xfeedface.org/blog/lattera/2013-01-12/tunneled-ipv6-freebsd-jails > > > > I'm curious to know if I've got a legit bug or if it's something I'm > doing > > wrong. The one thing I haven't tried is setting up rtadvd on the bridge. > > That'd be kindof interesting, since my physical NIC is a member on the > > bridge. I'd rather not dish out IPv6 addresses for all devices on the > > network (a network with lots of devices I don't own or control). > > As I said, I don't believe you need the physical interface on the > bridge, unless you have to for IPv4 (and you can't route or proxyarp > instead). However, before you can run rtadvd you will need to give the > bridge its proper link-local address, which probably also means locking > down its hardware address in rc.conf. Bridges don't get auto link-local > addresses, for reasons I've never entirely understood, and RAs have to > use ll addresses. > > You will need to set up routing so that packets coming in through the > tunnel destined for the jails get routed out of the bridge, and packets > coming in on the bridge destined for the IPv6 Internet get routed out of > the tunnel. Probably that will have happened already, just by assigning > an inet6 address and prefixlen to the bridge and the default inet6 route > to the tunnel. > Routing is already set up properly. The first jail that boots up has a working IPv6 stack. The problem is with jails booted up after the first one has been booted up. > > Ben > > Thanks for the help, Ben. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 15:32:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2F5574FF for ; Tue, 15 Jan 2013 15:32:58 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id AC040FCB for ; Tue, 15 Jan 2013 15:32:57 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hn3so242463wib.5 for ; Tue, 15 Jan 2013 07:32:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ptCaosX2ca0VBg8BG7RGwGUKjFOiSpWUp9GKjXlMmk8=; b=C8YwAPQwqhVLU1/DFKftVDdV2PTiFNJRwCm9aahh2w5StrGSqf8eBq8e4TAPDEsDNN Y3X+RUpngYwGbKdwZkbL9wVqprbMb2KEAHnqZYhLve2rMO2cX7RdvhBE9mp5VboF/WVI eiqMvLXVih4Xtf6xuVMw/V0Zvha8m5k23EH700eFikDXkzUJY66bEtekRwrPJnn7SMZW FSq9td0KELwdbmzrD2Ule/eKXr1tTEWNsaXWOjUXxNbBqyF7muF7ptz/paxn5WWdabph nT1Og1jV/HHfzXHGe9qw/IuRF//3hPgySXNymUgQzmwjpQPgEVn5DRiOTUNoMSuYS2U5 BRxQ== X-Received: by 10.194.85.234 with SMTP id k10mr141879550wjz.53.1358263971083; Tue, 15 Jan 2013 07:32:51 -0800 (PST) Received: from [172.16.44.24] (abo-99-180-68.mtp.modulonet.fr. [85.68.180.99]) by mx.google.com with ESMTPS id bd6sm3894126wib.10.2013.01.15.07.32.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 07:32:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: make release doesn't correctly include EXTLOCALDIR ? From: Fleuriot Damien In-Reply-To: Date: Tue, 15 Jan 2013 16:32:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40B04B98-5651-40DB-BD73-2C6E16DA6795@my.gd> References: To: "freebsd-stable@freebsd.org" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkgZR7R7wg6g2KsRjdWBB63feLSDG9pKTxyme+aidXWcSnch+CsSfobeJIYMMAZ80CCYvk4 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, 15 Jan 2013 15:32:58 -0000 On Jan 11, 2013, at 2:06 PM, Fleuriot Damien wrote: > Hello list, >=20 >=20 > I'm running 8.3-stable r245223 from a mere 2 days ago and am in the = process of building a custom release for our internal use as = preconfigured firewalls. >=20 > "make release" works pretty fine except for a few quirks here and = there. >=20 >=20 >=20 > First of all, I have set EXTLOCALDIR so that the release contains my = existing /usr/local/ , and thus the collection of installed ports. >=20 > The problem here is that while /release/usr/local/ is correctly = populated, the ISO images and ftp install directory have an empty = usr/local/ > Extracting the ISO's base.?? files doesn't yield the /usr/local/ = contents either. >=20 >=20 >=20 >=20 > The second problem I encounter is with the kernel's build. > Apparently "make release" doesn't pull MODULES_OVERRIDE from = /etc/make.conf and decides to build every single module, as opposed to = my own restricted list. >=20 > I'm going to try with with KERNEL_FLAGS=3D-DMODULES_OVERRIDE module1 = module2 in /usr/src/release/Makefile >=20 >=20 >=20 > Has anyone else ever experienced the same problem regarding the = inclusion of /usr/local/ in their release ? >=20 Reposting to -stable in the hope of getting feedback, having received = none on -questions. Has anyone experienced this before ? Is this intended behaviour ? I fail to see the purpose of including /usr/local/ if it won't be = packaged into the release images. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 19:54:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BFD0B6F7 for ; Tue, 15 Jan 2013 19:54:51 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 8B26F242 for ; Tue, 15 Jan 2013 19:54:51 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 3ACC6450C2; Tue, 15 Jan 2013 19:54:49 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk 3ACC6450C2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1358279690; bh=VbHQjFe2xRDeeOaQ0sD7/krOpOymSdlVEzqp0vBEyXg=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=O1hwUdQURSJTv8nmL6zwr1H6BnLpuEwD3etMmpaVOL5wax1yC3RxdIAL0Ji86cNQX bxOTsfxaL39QjGHcnM0iY/cplB9jiCBXFShGlwYMYvWErE+Al+obnHYcU5QrlWS89s 5AipxGX/bL7OJk53i/weLHqnszQpZucRxKdEYL5I= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id CBF1687AD; Tue, 15 Jan 2013 19:54:44 +0000 (GMT) Date: Tue, 15 Jan 2013 19:54:44 +0000 From: Ben Morrow To: lattera@gmail.com, freebsd-stable@freebsd.org Subject: Re: IPv6 Tunnel Shared With Jails via epair Devices Message-ID: <20130115195444.GA92522@anubis.morrow.me.uk> References: <20130115052937.GA44328@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk 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: Tue, 15 Jan 2013 19:54:51 -0000 Quoth Shawn Webb : > On Tue, Jan 15, 2013 at 12:29 AM, Ben Morrow wrote: > > Quoth Shawn Webb : > > > > > > # ifconfig bridge0 > > > bridge0: flags=8843 metric 0 mtu > > > 1500 > > > ether 02:fe:21:34:d3:00 > > > inet6 2001:470:8142:1::1 prefixlen 64 > > > nd6 options=21 > > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > > member: epair0a flags=143 > > > ifmaxaddr 0 port 19 priority 128 path cost 2000 > > > member: epair1a flags=143 > > > ifmaxaddr 0 port 21 priority 128 path cost 2000 > > > member: bge0 flags=143 > > > ifmaxaddr 0 port 5 priority 128 path cost 200000 > > > > Why have you added the physical interface to the bridge? AFAICT you > > don't need to: a bridge will bridge epairs just fine, and as you > > explained in that blog post you have to route rather than bridge into > > the tunnel, since the tunnel isn't an Ethernet device. > > I did it so that I have an IPv4 address directly on the LAN for each of my > jails. Hmm, OK. > > > # jexec "Dev Template" ifconfig epair0b > > > epair0b: flags=8843 metric 0 mtu > > > 1500 > > > options=8 > > > ether 02:80:03:00:14:0b > > > inet6 2001:470:8142:1::5 prefixlen 64 tentative > > > inet6 fe80::80:3ff:fe00:140b%epair0b prefixlen 64 tentative scopeid 0x2 > > > inet 10.7.1.92 netmask 0xfffffe00 broadcast 10.7.1.255 > > > nd6 options=29 > > > > I suspect the addresses are only marked tentative because the interface > > has been marked IFDISABLED. This causes all current addresses to be > > marked tentative, because the kernel isn't allowed to send or receive > > IPv6 packets and so can't defend the addresses any more. > > > > Is it possible something in the jail's startup scripts is causing the > > interface to be marked IFDISABLED after the inet6 address has been > > assigned? Some of the functions in network.subr mark interfaces > > IFDISABLED automatically if they don't think they have IPv6 addresses. > > I was thinking the same thing. One problem is that I can't remove the > IFDISABLED flag. This is what happens when I try: > > # jexec "Dev Template" ifconfig epair0b -ifdisabled > ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument ifconfig epair0b inet6 -ifdisabled I don't know why you get that error when you miss out the 'inet6'; it's not exactly very clear. Ben From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 19:55:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4156A7F1; Tue, 15 Jan 2013 19:55:25 +0000 (UTC) (envelope-from olivier777a7@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 C1AB425A; Tue, 15 Jan 2013 19:55:23 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id fs13so564618lab.23 for ; Tue, 15 Jan 2013 11:55:22 -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=gmPWyccEvg/1qMgT5YgggOnZQo4WIg59D1YBCCOPe+o=; b=vpkwX7gqVtnLLzPliWhTCcB3w+ZU3nmvi3WYbf1zir0TV3qhi4OJQyBm+kPDZtOQXe Xv8nFqOhSdLSzndKyqwSE2uGTFYxa6A5D99UQ/qdAWavYCrqyUpBwU4jvNNpcdhhyAur CiZ7WWPIjf3E62wDbEzUlswE5M6M8UuA4DErKIDFP1ESr75u/FWodd6TSjg/9iE3OUS6 OWMvfiqraS4s8rTrzetrq6mt81DQjGiLlAxtJ8UMKlPqp963T5J5Qb9Pe74xgeOQSQcg Vson8t14ry3iZTzdrXRIBvhdPtv5yOu//aXGFevqNkv3lSwFuRRhuCreDRU0nA5vnNLt cpZg== MIME-Version: 1.0 Received: by 10.152.145.37 with SMTP id sr5mr30198611lab.33.1358279722551; Tue, 15 Jan 2013 11:55:22 -0800 (PST) Received: by 10.114.78.41 with HTTP; Tue, 15 Jan 2013 11:55:22 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Jan 2013 11:55:22 -0800 Message-ID: Subject: Re: CAM hangs in 9-STABLE? [Was: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE] From: olivier To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ken@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: Tue, 15 Jan 2013 19:55:25 -0000 Dear All, Still experiencing the same hangs I reported earlier with 9.1. I've been running a kernel with WITNESS enabled to provide more information. During an occurrence of the hang, running show alllocks gave Process 25777 (sysctl) thread 0xfffffe014c5b2920 (102567) exclusive sleep mutex Giant (Giant) r = 0 (0xffffffff811e34c0) locked @ /usr/src/sys/dev/usb/usb_transfer.c:3171 Process 25750 (sshd) thread 0xfffffe015a688000 (104313) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffffe0204e0bb98) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 24922 (cnid_dbd) thread 0xfffffe0187ac4920 (103597) shared lockmgr zfs (zfs) r = 0 (0xfffffe0973062488) locked @ /usr/src/sys/kern/vfs_syscalls.c:3591 Process 24117 (sshd) thread 0xfffffe07bd914490 (104195) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffffe0204e0a8f0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1243 (java) thread 0xfffffe01ca85d000 (102704) exclusive sleep mutex pmap (pmap) r = 0 (0xfffffe015aec1440) locked @ /usr/src/sys/amd64/amd64/pmap.c:4840 exclusive rw pmap pv global (pmap pv global) r = 0 (0xffffffff81409780) locked @ /usr/src/sys/amd64/amd64/pmap.c:4802 exclusive sleep mutex vm page (vm page) r = 0 (0xffffffff813f0a80) locked @ /usr/src/sys/vm/vm_object.c:1128 exclusive sleep mutex vm object (standard object) r = 0 (0xfffffe01458e43a0) locked @ /usr/src/sys/vm/vm_object.c:1076 shared sx vm map (user) (vm map (user)) r = 0 (0xfffffe015aec1388) locked @ /usr/src/sys/vm/vm_map.c:2045 Process 994 (nfsd) thread 0xfffffe015a0df000 (102426) shared lockmgr zfs (zfs) r = 0 (0xfffffe0c3b505878) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1760 Process 994 (nfsd) thread 0xfffffe015a0f8490 (102422) exclusive lockmgr zfs (zfs) r = 0 (0xfffffe02db3b3e60) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1760 Process 931 (syslogd) thread 0xfffffe015af18920 (102365) shared lockmgr zfs (zfs) r = 0 (0xfffffe0141dd6680) locked @ /usr/src/sys/kern/vfs_syscalls.c:3591 Process 22 (syncer) thread 0xfffffe0125077000 (100279) exclusive lockmgr syncer (syncer) r = 0 (0xfffffe015a2ff680) locked @ /usr/src/sys/kern/vfs_subr.c:1809 I don't have full "show lockedvnods" output because the output does not get captured by ddb after using "capture on", it doesn't fit on a single screen, and doesn't get piped into a "more" equivalent. What I did manage to get (copied by hand, typos possible) is: 0xfffffe0c3b5057e0: 0xfffffe0c3b5057e0: tag zfs, type VREG tag zfs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) v_object 0xfffffe089bc1b828 ref 0 pages 0 v_object 0xfffffe089bc1b828 ref 0 pages 0 lock type zfs: SHARED (count 1) lock type zfs: SHARED (count 1) 0xfffffe02db3b3dc8: 0xfffffe02db3b3dc8: tag zfs, type VREG tag zfs, type VREG usecount 6, writecount 0, refcount 6 mountedhere 0 usecount 6, writecount 0, refcount 6 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) v_object 0xfffffe0b79583ae0 ref 0 pages 0 v_object 0xfffffe0b79583ae0 ref 0 pages 0 lock type zfs: EXCL by thread 0xfffffe015a0f8490 (pid 994) lock type zfs: EXCL by thread 0xfffffe015a0f8490 (pid 994) with exclusive waiters pending with exclusive waiters pending The output of show witness is at http://pastebin.com/eSRb3FEu The output of alltrace is at http://pastebin.com/X1LruNrf (a number of threads are stuck in zio_wait, none I can find in zio_interrupt, and according to gstat and disks eventually going to sleep all disk IO seems to be stuck for good; I think Andriy explained earlier that these criteria might indicate this is a ZFS hang). The output of show geom is at http://pastebin.com/6nwQbKr4 The output of vmstat -i is at http://pastebin.com/9LcZ7Mi0 Interrupts are occurring at a normal rate during the hang, as far as I can tell. Any help would be greatly appreciated. Thanks Olivier PS: my kernel was compiled from 9-STABLE from December, with CAM and ahci from 9.0 (in the hope it would fix the hangs I was experiencing in plain 9-STABLE; obviously the hangs are still occurring). The rest of my configuration is the same as posted earlier. On Mon, Dec 24, 2012 at 9:42 PM, olivier wrote: > 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 Jan 15 20:05:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E75B7B49 for ; Tue, 15 Jan 2013 20:05:12 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by mx1.freebsd.org (Postfix) with ESMTP id 995602E9 for ; Tue, 15 Jan 2013 20:05:12 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id fl11so562613vcb.1 for ; Tue, 15 Jan 2013 12:05: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=H1ZKvwICyTEKE9VZW+2r8SSvuP+RM3q9qOQ8PCuPBag=; b=KWW+ZEmL0u14v/qctIYqZsviWo8kusrW+f+9duxw0XuFjeX0qLA0bp3Ev5CAu1a4nj OxaFvrIix3vrCFAMVvSlyx/prsjNc6NtNLLS3akOg2mJu1H6XGtRR0pL4ku7g8zVyKs/ OOESw8s1yCu87EdomtsE4d6HsMEM2sHeZf7ZDjaOxJ4aQV+tPTy4ouJwYFGS5h+9v031 eTD/fkVpbYzHD8VeEUd6vnYfnZNxbUJ864DOBKZjW7XlqCMLCLdrmW96Y/ioMnrXA/gG EYc9/CQtTz0+vjL1ZP4LuGo6XIXrYr6cOhYf2JWjRiqGNU+aCSd+F1FJ7G6CgSEafTJL 23gw== MIME-Version: 1.0 Received: by 10.52.36.19 with SMTP id m19mr91179554vdj.33.1358280311855; Tue, 15 Jan 2013 12:05:11 -0800 (PST) Received: by 10.58.152.42 with HTTP; Tue, 15 Jan 2013 12:05:11 -0800 (PST) In-Reply-To: <20130115195444.GA92522@anubis.morrow.me.uk> References: <20130115052937.GA44328@anubis.morrow.me.uk> <20130115195444.GA92522@anubis.morrow.me.uk> Date: Tue, 15 Jan 2013 15:05:11 -0500 Message-ID: Subject: Re: IPv6 Tunnel Shared With Jails via epair Devices From: Shawn Webb To: Ben Morrow Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.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: Tue, 15 Jan 2013 20:05:13 -0000 On Tue, Jan 15, 2013 at 2:54 PM, Ben Morrow wrote: > Quoth Shawn Webb : > > On Tue, Jan 15, 2013 at 12:29 AM, Ben Morrow wrote: > > > Quoth Shawn Webb : > > > > > > > > # ifconfig bridge0 > > > > bridge0: flags=8843 metric 0 > mtu > > > > 1500 > > > > ether 02:fe:21:34:d3:00 > > > > inet6 2001:470:8142:1::1 prefixlen 64 > > > > nd6 options=21 > > > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > > > member: epair0a flags=143 > > > > ifmaxaddr 0 port 19 priority 128 path cost 2000 > > > > member: epair1a flags=143 > > > > ifmaxaddr 0 port 21 priority 128 path cost 2000 > > > > member: bge0 flags=143 > > > > ifmaxaddr 0 port 5 priority 128 path cost 200000 > > > > > > Why have you added the physical interface to the bridge? AFAICT you > > > don't need to: a bridge will bridge epairs just fine, and as you > > > explained in that blog post you have to route rather than bridge into > > > the tunnel, since the tunnel isn't an Ethernet device. > > > > I did it so that I have an IPv4 address directly on the LAN for each of > my > > jails. > > Hmm, OK. > > > > > # jexec "Dev Template" ifconfig epair0b > > > > epair0b: flags=8843 metric 0 > mtu > > > > 1500 > > > > options=8 > > > > ether 02:80:03:00:14:0b > > > > inet6 2001:470:8142:1::5 prefixlen 64 tentative > > > > inet6 fe80::80:3ff:fe00:140b%epair0b prefixlen 64 tentative scopeid > 0x2 > > > > inet 10.7.1.92 netmask 0xfffffe00 broadcast 10.7.1.255 > > > > nd6 options=29 > > > > > > I suspect the addresses are only marked tentative because the interface > > > has been marked IFDISABLED. This causes all current addresses to be > > > marked tentative, because the kernel isn't allowed to send or receive > > > IPv6 packets and so can't defend the addresses any more. > > > > > > Is it possible something in the jail's startup scripts is causing the > > > interface to be marked IFDISABLED after the inet6 address has been > > > assigned? Some of the functions in network.subr mark interfaces > > > IFDISABLED automatically if they don't think they have IPv6 addresses. > > > > I was thinking the same thing. One problem is that I can't remove the > > IFDISABLED flag. This is what happens when I try: > > > > # jexec "Dev Template" ifconfig epair0b -ifdisabled > > ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument > > ifconfig epair0b inet6 -ifdisabled > > I don't know why you get that error when you miss out the 'inet6'; it's > not exactly very clear. > Ah. That works. I'll just have to add that to my scripts. Since the device won't come out of tentative mode without manually removing the ifdisabled flag, should I go ahead and file a PR? It'd be nice if I could at the very least set a timeout for DAD. > > Ben > > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 22:56:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 520DE620 for ; Tue, 15 Jan 2013 22:56:17 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 02DDCF9F for ; Tue, 15 Jan 2013 22:56:16 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so716691vcb.13 for ; Tue, 15 Jan 2013 14:56:14 -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=jS039QAZY7GqzmtEKQLnzE/qGl9KRuHuxy8RSz4fLl8=; b=rpge2KHqn8sB/eamcCT/QumVtxjxV/e8ghYX7W2AMWs1bWZXUmllOMdyn92hsWrA0B eYwnzyaNtLDJtr76Cpo2UUR4izwT1woxy0BfzXjBKbsioCU0sZrjOss+03wc3x/+7occ azQJGcpxH0aqZaStB9BvQfqflT4MAO9PjOsqGGyNUGhCmrnJqVerfnprm1FyOCTXr9pn pAIyNZHg3NKiUZrP8bA2s52I/qQiuU43zQ82PHnawj9AOQbSvUee3vol6tecIOpb/JfO eH3R3gf/iOE9vkLsFsb0vt9FqHhruBkPjP9TZepqhF9b3uyjISj9Znh/Car/UIRmuhL5 6Bxw== MIME-Version: 1.0 Received: by 10.52.22.240 with SMTP id h16mr94297577vdf.82.1358290574295; Tue, 15 Jan 2013 14:56:14 -0800 (PST) Received: by 10.58.152.42 with HTTP; Tue, 15 Jan 2013 14:56:14 -0800 (PST) In-Reply-To: References: <20130115052937.GA44328@anubis.morrow.me.uk> <20130115195444.GA92522@anubis.morrow.me.uk> <20130115215159.GA93174@anubis.morrow.me.uk> Date: Tue, 15 Jan 2013 17:56:14 -0500 Message-ID: Subject: Re: IPv6 Tunnel Shared With Jails via epair Devices From: Shawn Webb To: Ben Morrow Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.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: Tue, 15 Jan 2013 22:56:17 -0000 Somehow there ended up a typo in the CC to freebsd-stable@freebsd.org. Last email below: On Tue, Jan 15, 2013 at 5:53 PM, Shawn Webb wrote: > On Tue, Jan 15, 2013 at 4:52 PM, Ben Morrow wrote: > >> Quoth Shawn Webb : >> > On Tue, Jan 15, 2013 at 2:54 PM, Ben Morrow wrote: >> > > >> > > ifconfig epair0b inet6 -ifdisabled >> > > >> > > I don't know why you get that error when you miss out the 'inet6'; >> it's >> > > not exactly very clear. >> > > >> > >> > Ah. That works. I'll just have to add that to my scripts. Since the >> device >> > won't come out of tentative mode without manually removing the >> ifdisabled >> > flag, should I go ahead and file a PR? It'd be nice if I could at the >> very >> > least set a timeout for DAD. >> >> DAD already has a timeout: it succeeds iff no packets indicating someone >> else is using the address are received in a given time. The only reason >> for an address remaining tentative indefinitely (without transitioning >> to either valid or duplicated) is if IPv6 on that interface has been >> disable entirely by setting IFDISABLED. If DAD fails for the LL address >> the interface is marked IFDISABLED but the LL address is marked >> duplicated rather than tentative. >> > > I figured it out. In my jail initialization scripts, I'm running '/bin/sh > /bin/rc' after doing initial network setup. The rc script puts the > interface in IFDISABLED mode. So if I run the ifconfig command to remove > the flag, I'm golden. I've committed and pushed the code that fixes the > problem in my scripts. If you're curious, you can look at > https://github.com/lattera/drupal-jailadmin/commit/cbf8509712c3dd237bbc020f49f63b51507b7be4 > > Thanks for the help. I really appreciate it. > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 15 23:27:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B89722E for ; Tue, 15 Jan 2013 23:27:56 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 27AD4235 for ; Tue, 15 Jan 2013 23:27:55 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 94DE0450C2; Tue, 15 Jan 2013 23:27:54 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk 94DE0450C2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1358292474; bh=WCxU7XX5MJSX63NwyXpudGS8jUT9uUdx4XF56A74XIY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=X4W0K5JvPjgzXdn7UhbDHJzp9d4dZFKxjF6vGwyXzgepGamXfDRNbapyvhxhlscDl g5xl6iUdrJcGny1jNWl+OjgRbfqjIdIII3LDeLKpgQuvfLMxl++dRskvjYaVTdYUMg GGLBNGiMQT3F2sA3YUqmz+aZvaCZqkugJ3dmg1QA= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 615A28804; Tue, 15 Jan 2013 23:27:52 +0000 (GMT) Date: Tue, 15 Jan 2013 23:27:52 +0000 From: Ben Morrow To: Shawn Webb Subject: Re: IPv6 Tunnel Shared With Jails via epair Devices Message-ID: <20130115232751.GA2420@anubis.morrow.me.uk> References: <20130115052937.GA44328@anubis.morrow.me.uk> <20130115195444.GA92522@anubis.morrow.me.uk> <20130115215159.GA93174@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org 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, 15 Jan 2013 23:27:56 -0000 At 5PM -0500 on 15/01/13 you (Shawn Webb) wrote: > > I figured it out. In my jail initialization scripts, I'm running '/bin/sh > /bin/rc' after doing initial network setup. The rc script puts the > interface in IFDISABLED mode. So if I run the ifconfig command to remove > the flag, I'm golden. Yes, that's what I thought. You should be able to avoid this by specifying either ifconfig_epair0b_ipv6="inet6 auto_linklocal" or ipv6_activate_all_interfaces="YES" in the jail's rc.conf. This is cleaner than running ifconfig explicitly outside the jail. Ben From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 00:07:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C02EA25B for ; Wed, 16 Jan 2013 00:07:40 +0000 (UTC) (envelope-from rcartwri@asu.edu) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7D870F for ; Wed, 16 Jan 2013 00:07:40 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id x4so781244obh.24 for ; Tue, 15 Jan 2013 16:07:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=IVTKzE3xkDriny8v4brXDu2cpIUqrxpTT97TyGQjVEc=; b=ewtYWttBqcPHTlKd5XPLdJ22F3D1FZq+qRDegVFP8vlM8xPsc9tvDfB6hS0VdALoUE YWHVL3G6XFO+SLcNM8HSFlWxOkgVW9pLwWgJjLS27wbtl9jsFfD6dmyzq86IP59zG08v EN+tguGe0jtGrH8sUZ49ZtOivn38tKiXGwCl8U+UCWhh/MGPYrE2/5VwHlZuzncjQ1lu GTe/lnLE9jh+urbO+NvumK39C1iw0v2h18d05G3YY5nb9NTV9EZ+zVcFZrmXEKDqO97L zqaF8fHhOLGBj7p/q+yYBIJVYdW4EWQx4LUSxwC9nH26SQtL/LAlwDXAznAo3CA8BWaR KkFw== MIME-Version: 1.0 Received: by 10.182.235.70 with SMTP id uk6mr23274848obc.54.1358294858555; Tue, 15 Jan 2013 16:07:38 -0800 (PST) Received: by 10.76.173.101 with HTTP; Tue, 15 Jan 2013 16:07:38 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Jan 2013 17:07:38 -0700 Message-ID: Subject: Re: CAM hangs in 9-STABLE? [Was: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE] From: "Reed A. Cartwright" To: olivier Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkufxcsiLUQlmP3XbBeDI5SZwyKnMT39BUynWO/DPdjX5gjoY0X7Jbx7ReymEQKkVMlMvEA Cc: freebsd-fs@freebsd.org, ken@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: Wed, 16 Jan 2013 00:07:40 -0000 I don't know if this is relevant or not, but I deadlock was recently fixed in the VFS code: http://svnweb.freebsd.org/base?view=revision&revision=244795 On Tue, Jan 15, 2013 at 12:55 PM, olivier wrote: > Dear All, > Still experiencing the same hangs I reported earlier with 9.1. I've been > running a kernel with WITNESS enabled to provide more information. > > During an occurrence of the hang, running show alllocks gave > > Process 25777 (sysctl) thread 0xfffffe014c5b2920 (102567) > exclusive sleep mutex Giant (Giant) r = 0 (0xffffffff811e34c0) locked @ > /usr/src/sys/dev/usb/usb_transfer.c:3171 > Process 25750 (sshd) thread 0xfffffe015a688000 (104313) > exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffffe0204e0bb98) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > Process 24922 (cnid_dbd) thread 0xfffffe0187ac4920 (103597) > shared lockmgr zfs (zfs) r = 0 (0xfffffe0973062488) locked @ > /usr/src/sys/kern/vfs_syscalls.c:3591 > Process 24117 (sshd) thread 0xfffffe07bd914490 (104195) > exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffffe0204e0a8f0) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > Process 1243 (java) thread 0xfffffe01ca85d000 (102704) > exclusive sleep mutex pmap (pmap) r = 0 (0xfffffe015aec1440) locked @ > /usr/src/sys/amd64/amd64/pmap.c:4840 > exclusive rw pmap pv global (pmap pv global) r = 0 (0xffffffff81409780) > locked @ /usr/src/sys/amd64/amd64/pmap.c:4802 > exclusive sleep mutex vm page (vm page) r = 0 (0xffffffff813f0a80) locked @ > /usr/src/sys/vm/vm_object.c:1128 > exclusive sleep mutex vm object (standard object) r = 0 > (0xfffffe01458e43a0) locked @ /usr/src/sys/vm/vm_object.c:1076 > shared sx vm map (user) (vm map (user)) r = 0 (0xfffffe015aec1388) locked @ > /usr/src/sys/vm/vm_map.c:2045 > Process 994 (nfsd) thread 0xfffffe015a0df000 (102426) > shared lockmgr zfs (zfs) r = 0 (0xfffffe0c3b505878) locked @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1760 > Process 994 (nfsd) thread 0xfffffe015a0f8490 (102422) > exclusive lockmgr zfs (zfs) r = 0 (0xfffffe02db3b3e60) locked @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1760 > Process 931 (syslogd) thread 0xfffffe015af18920 (102365) > shared lockmgr zfs (zfs) r = 0 (0xfffffe0141dd6680) locked @ > /usr/src/sys/kern/vfs_syscalls.c:3591 > Process 22 (syncer) thread 0xfffffe0125077000 (100279) > exclusive lockmgr syncer (syncer) r = 0 (0xfffffe015a2ff680) locked @ > /usr/src/sys/kern/vfs_subr.c:1809 > > I don't have full "show lockedvnods" output because the output does not get > captured by ddb after using "capture on", it doesn't fit on a single > screen, and doesn't get piped into a "more" equivalent. What I did manage > to get (copied by hand, typos possible) is: > > 0xfffffe0c3b5057e0: 0xfffffe0c3b5057e0: tag zfs, type VREG > tag zfs, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VI_ACTIVE) > flags (VI_ACTIVE) > v_object 0xfffffe089bc1b828 ref 0 pages 0 > v_object 0xfffffe089bc1b828 ref 0 pages 0 > lock type zfs: SHARED (count 1) > lock type zfs: SHARED (count 1) > > 0xfffffe02db3b3dc8: 0xfffffe02db3b3dc8: tag zfs, type VREG > tag zfs, type VREG > usecount 6, writecount 0, refcount 6 mountedhere 0 > usecount 6, writecount 0, refcount 6 mountedhere 0 > flags (VI_ACTIVE) > flags (VI_ACTIVE) > v_object 0xfffffe0b79583ae0 ref 0 pages 0 > v_object 0xfffffe0b79583ae0 ref 0 pages 0 > lock type zfs: EXCL by thread 0xfffffe015a0f8490 (pid 994) > lock type zfs: EXCL by thread 0xfffffe015a0f8490 (pid 994) > with exclusive waiters pending > with exclusive waiters pending > > The output of show witness is at http://pastebin.com/eSRb3FEu > > The output of alltrace is at http://pastebin.com/X1LruNrf (a number of > threads are stuck in zio_wait, none I can find in zio_interrupt, and > according to gstat and disks eventually going to sleep all disk IO seems to > be stuck for good; I think Andriy explained earlier that these criteria > might indicate this is a ZFS hang). > > The output of show geom is at http://pastebin.com/6nwQbKr4 > > The output of vmstat -i is at http://pastebin.com/9LcZ7Mi0 Interrupts are > occurring at a normal rate during the hang, as far as I can tell. > > Any help would be greatly appreciated. > Thanks > Olivier > PS: my kernel was compiled from 9-STABLE from December, with CAM and ahci > from 9.0 (in the hope it would fix the hangs I was experiencing in plain > 9-STABLE; obviously the hangs are still occurring). The rest of my > configuration is the same as posted earlier. > > On Mon, Dec 24, 2012 at 9:42 PM, olivier wrote: > >> 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 >>>>> >>>> >>>> >>> >> > _______________________________________________ > 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" -- Reed A. Cartwright, PhD Assistant Professor of Genomics, Evolution, and Bioinformatics School of Life Sciences Center for Evolutionary Medicine and Informatics The Biodesign Institute Arizona State University From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 02:23:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 41B80DED; Wed, 16 Jan 2013 02:23:32 +0000 (UTC) (envelope-from olivier777a7@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 C17A0E9A; Wed, 16 Jan 2013 02:23:30 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id ej20so871696lab.35 for ; Tue, 15 Jan 2013 18:23:24 -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=WxoEaKQMpUbcYwd6CadgFniPrFeyKzP9yeqLzzSeJao=; b=otcxFn/U7LRdxP1bOUJRrt4l9CYWDemIBHjEqORBzAwp4ky1pnwGI57opXWN5xbIXO U9F87ArtiVxRFH/wIrFQYLjiKjjjR6u16WxmaiBxSmKiiMJyE86HL6EO8UdOfIhBjrk8 dnf57JBg8kyIsXNww3wq3H3s7OW+9SA+VaOcYxKiYGyD4mmUCL5cfPZOK3bj+oTtDt5L hkIEGUyOLGh/9v3/H3szSetsP5mMp2O5AEgY4BP9SIzVOLcFY1U7PyggJiZjXMDQeCe8 NgTlqTxWHb7PqyxqDuQtICH65yPTqjrND1fTGeI6WiZOplbSmPFjecA51f70dNgJJ94s 2tkg== MIME-Version: 1.0 Received: by 10.152.144.164 with SMTP id sn4mr87688027lab.57.1358303004305; Tue, 15 Jan 2013 18:23:24 -0800 (PST) Received: by 10.114.78.41 with HTTP; Tue, 15 Jan 2013 18:23:24 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Jan 2013 18:23:24 -0800 Message-ID: Subject: Re: CAM hangs in 9-STABLE? [Was: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE] From: olivier To: "Reed A. Cartwright" 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" , 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: Wed, 16 Jan 2013 02:23:32 -0000 My understanding is that the locks (and pieces of kernel code) involved are different. Maybe someone more knowledgeable than I am can comment. Thanks for the suggestion... Olivier On Tue, Jan 15, 2013 at 4:07 PM, Reed A. Cartwright wrote: > I don't know if this is relevant or not, but I deadlock was recently > fixed in the VFS code: > > http://svnweb.freebsd.org/base?view=revision&revision=244795 > > On Tue, Jan 15, 2013 at 12:55 PM, olivier wrote: > > Dear All, > > Still experiencing the same hangs I reported earlier with 9.1. I've been > > running a kernel with WITNESS enabled to provide more information. > > > > During an occurrence of the hang, running show alllocks gave > > > > Process 25777 (sysctl) thread 0xfffffe014c5b2920 (102567) > > exclusive sleep mutex Giant (Giant) r = 0 (0xffffffff811e34c0) locked @ > > /usr/src/sys/dev/usb/usb_transfer.c:3171 > > Process 25750 (sshd) thread 0xfffffe015a688000 (104313) > > exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffffe0204e0bb98) locked @ > > /usr/src/sys/kern/uipc_sockbuf.c:148 > > Process 24922 (cnid_dbd) thread 0xfffffe0187ac4920 (103597) > > shared lockmgr zfs (zfs) r = 0 (0xfffffe0973062488) locked @ > > /usr/src/sys/kern/vfs_syscalls.c:3591 > > Process 24117 (sshd) thread 0xfffffe07bd914490 (104195) > > exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffffe0204e0a8f0) locked @ > > /usr/src/sys/kern/uipc_sockbuf.c:148 > > Process 1243 (java) thread 0xfffffe01ca85d000 (102704) > > exclusive sleep mutex pmap (pmap) r = 0 (0xfffffe015aec1440) locked @ > > /usr/src/sys/amd64/amd64/pmap.c:4840 > > exclusive rw pmap pv global (pmap pv global) r = 0 (0xffffffff81409780) > > locked @ /usr/src/sys/amd64/amd64/pmap.c:4802 > > exclusive sleep mutex vm page (vm page) r = 0 (0xffffffff813f0a80) > locked @ > > /usr/src/sys/vm/vm_object.c:1128 > > exclusive sleep mutex vm object (standard object) r = 0 > > (0xfffffe01458e43a0) locked @ /usr/src/sys/vm/vm_object.c:1076 > > shared sx vm map (user) (vm map (user)) r = 0 (0xfffffe015aec1388) > locked @ > > /usr/src/sys/vm/vm_map.c:2045 > > Process 994 (nfsd) thread 0xfffffe015a0df000 (102426) > > shared lockmgr zfs (zfs) r = 0 (0xfffffe0c3b505878) locked @ > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1760 > > Process 994 (nfsd) thread 0xfffffe015a0f8490 (102422) > > exclusive lockmgr zfs (zfs) r = 0 (0xfffffe02db3b3e60) locked @ > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1760 > > Process 931 (syslogd) thread 0xfffffe015af18920 (102365) > > shared lockmgr zfs (zfs) r = 0 (0xfffffe0141dd6680) locked @ > > /usr/src/sys/kern/vfs_syscalls.c:3591 > > Process 22 (syncer) thread 0xfffffe0125077000 (100279) > > exclusive lockmgr syncer (syncer) r = 0 (0xfffffe015a2ff680) locked @ > > /usr/src/sys/kern/vfs_subr.c:1809 > > > > I don't have full "show lockedvnods" output because the output does not > get > > captured by ddb after using "capture on", it doesn't fit on a single > > screen, and doesn't get piped into a "more" equivalent. What I did manage > > to get (copied by hand, typos possible) is: > > > > 0xfffffe0c3b5057e0: 0xfffffe0c3b5057e0: tag zfs, type VREG > > tag zfs, type VREG > > usecount 1, writecount 0, refcount 1 mountedhere 0 > > usecount 1, writecount 0, refcount 1 mountedhere 0 > > flags (VI_ACTIVE) > > flags (VI_ACTIVE) > > v_object 0xfffffe089bc1b828 ref 0 pages 0 > > v_object 0xfffffe089bc1b828 ref 0 pages 0 > > lock type zfs: SHARED (count 1) > > lock type zfs: SHARED (count 1) > > > > 0xfffffe02db3b3dc8: 0xfffffe02db3b3dc8: tag zfs, type VREG > > tag zfs, type VREG > > usecount 6, writecount 0, refcount 6 mountedhere 0 > > usecount 6, writecount 0, refcount 6 mountedhere 0 > > flags (VI_ACTIVE) > > flags (VI_ACTIVE) > > v_object 0xfffffe0b79583ae0 ref 0 pages 0 > > v_object 0xfffffe0b79583ae0 ref 0 pages 0 > > lock type zfs: EXCL by thread 0xfffffe015a0f8490 (pid 994) > > lock type zfs: EXCL by thread 0xfffffe015a0f8490 (pid 994) > > with exclusive waiters pending > > with exclusive waiters pending > > > > The output of show witness is at http://pastebin.com/eSRb3FEu > > > > The output of alltrace is at http://pastebin.com/X1LruNrf (a number of > > threads are stuck in zio_wait, none I can find in zio_interrupt, and > > according to gstat and disks eventually going to sleep all disk IO seems > to > > be stuck for good; I think Andriy explained earlier that these criteria > > might indicate this is a ZFS hang). > > > > The output of show geom is at http://pastebin.com/6nwQbKr4 > > > > The output of vmstat -i is at http://pastebin.com/9LcZ7Mi0 Interrupts > are > > occurring at a normal rate during the hang, as far as I can tell. > > > > Any help would be greatly appreciated. > > Thanks > > Olivier > > PS: my kernel was compiled from 9-STABLE from December, with CAM and ahci > > from 9.0 (in the hope it would fix the hangs I was experiencing in plain > > 9-STABLE; obviously the hangs are still occurring). The rest of my > > configuration is the same as posted earlier. > > > > On Mon, Dec 24, 2012 at 9:42 PM, olivier wrote: > > > >> 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 > >>>>> > >>>> > >>>> > >>> > >> > > _______________________________________________ > > 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 > " > > > > -- > Reed A. Cartwright, PhD > Assistant Professor of Genomics, Evolution, and Bioinformatics > School of Life Sciences > Center for Evolutionary Medicine and Informatics > The Biodesign Institute > Arizona State University > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 09:54:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2BD1565 for ; Wed, 16 Jan 2013 09:54:28 +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 AF20995A for ; Wed, 16 Jan 2013 09:54:28 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TvPZ7-000NC7-5C for freebsd-stable@freebsd.org; Wed, 16 Jan 2013 11:45:49 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable@freebsd.org Subject: time issues and some more Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jan 2013 11:45:49 +0200 From: Daniel Braniss Message-ID: 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, 16 Jan 2013 09:54:29 -0000 I resently upgraded a Dell PowerEdge R710, to 9.1-stable, we mainly use it as a backup to several zfs servers (doing send|receive) without major issues till the upgrade, it was running 8.2-stable. now, we see that sometime the time drifts, and today I noticed that it was hung, and once I got unto the ipmi console this is what i got: [SOL Session operational. Use ~? for help] swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: 12288 and things started moving again, in /var/log/messages: Jan 16 03:27:35 store-02 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: 12288 but the REAL time is 7hs ahead!, so time stood still ? and now, of course we get: Jan 16 03:54:19 store-02 ntpd[38163]: time correction of 25216 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. I will now reboot, and try a newer kernel and check, but any insight will be very helpful, thanks, danny From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 12:05:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B285475 for ; Wed, 16 Jan 2013 12:05:14 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 2EEC5131 for ; Wed, 16 Jan 2013 12:05:14 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id o1so1151358wic.0 for ; Wed, 16 Jan 2013 04:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=8veztiqf143F39d9oSVwMCm1jF0RbiROSRZTq2AK0iE=; b=DiDqR18zx4zGm8bL4lya/0THfpyHnHr86BNOR/1K9hdOo6u5kmET4L2fdtLdpbeksO rOL2tgeUPGafplzYd7yHGAVoPqACH5PVCv1ZAsvrOZhkW07SRvqtqYkDawmpX+2qpEpy mtQJMttKPAn5yhKNt6Okg1QmmWOpiq9Fi/bUfTQSLL7RD8+I2lZFDc43cyUCZrEOoskJ juZywuP+SPVpN0BuGVj1yTcroH1OYbItITZxBkha3jT/7xcBpp0QjCpVc4TgN24GIJOz kyT6Xju5KHhSuAHNMwbgt8oVWQA7vMElFHWqgFWhdO240zi3VbofwZZ9rrMg2fdFV4zL p4/Q== MIME-Version: 1.0 X-Received: by 10.180.93.40 with SMTP id cr8mr9690244wib.15.1358337913247; Wed, 16 Jan 2013 04:05:13 -0800 (PST) Received: by 10.216.172.197 with HTTP; Wed, 16 Jan 2013 04:05:13 -0800 (PST) Date: Wed, 16 Jan 2013 14:05:13 +0200 Message-ID: Subject: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 From: Kimmo Paasiala 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: Wed, 16 Jan 2013 12:05:14 -0000 Hello list. I just updated my stable/9 system after clang3.2 was added. My system is amd64, both world and kernel are compiled with clang3.2 and the default compiler is clang. I'm tracking the sources with GIT and the version I have corresponds to SVN revision r245451. Everything else seems to work but the pam authentication module security/pam_ssh_agent_auth segfaults immediately. The version I had was compiled in a releng/9.1 jail using poudriere with clang as the default compiler. I recompiled the port with the new clang3.2 compiler but no difference. Here is the backtrace from gdb when I run su(1) as root with the suitable settings to force the use of the plugin: (gdb) run Starting program: /usr/bin/su (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 (gdb) bt #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7 #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7 #3 0x0000000801c0e2e7 in do_log () from /usr/local/lib/pam_ssh_agent_auth.so #4 0x0000000801c0e4ff in logit () from /usr/local/lib/pam_ssh_agent_auth.so #5 0x0000000801c116f4 in pam_user_key_allowed2 () from /usr/local/lib/pam_ssh_agent_auth.so #6 0x0000000801c11f1e in pam_user_key_allowed () from /usr/local/lib/pam_ssh_agent_auth.so #7 0x0000000801c11a18 in userauth_pubkey_from_id () from /usr/local/lib/pam_ssh_agent_auth.so #8 0x0000000801c118fa in find_authorized_keys () from /usr/local/lib/pam_ssh_agent_auth.so #9 0x0000000801c122e5 in pam_sm_authenticate () from /usr/local/lib/pam_ssh_agent_auth.so #10 0x0000000800a343e0 in openpam_dispatch () from /usr/lib/libpam.so.5 #11 0x0000000800a33946 in pam_authenticate () from /usr/lib/libpam.so.5 #12 0x00000000004020b8 in ?? () #13 0x0000000000401c61 in ?? () #14 0x000000080061f000 in ?? () #15 0x0000000000000000 in ?? () The str*vis() calls suggest that it's something in the libc maybe? Regards, Kimmo Paasiala From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 16:10:52 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB1C612F; Wed, 16 Jan 2013 16:10:52 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) by mx1.freebsd.org (Postfix) with ESMTP id A380D3F2; Wed, 16 Jan 2013 16:10:52 +0000 (UTC) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 9D32DBDC5E; Wed, 16 Jan 2013 17:10:49 +0100 (CET) Received: from ogg.in.absolight.net (ogg.in.absolight.net [79.143.241.239]) by prod2.absolight.net (Postfix) with ESMTPA id 85D89BDC1F; Wed, 16 Jan 2013 17:10:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ogg.in.absolight.net (Postfix) with ESMTP id F37F54E336AB; Wed, 16 Jan 2013 17:10:48 +0100 (CET) Date: Wed, 16 Jan 2013 17:10:48 +0100 From: Mathieu Arnold To: Mathieu Arnold , stable@freebsd.org Subject: Re: Upgrade to 9.1 failing Message-ID: In-Reply-To: <603EB188CA36FE2EE2198CFE@ogg.in.absolight.net> References: <13BA1B76EC845A57F6527036@ogg.in.absolight.net> <20130114180531.GH8239@home.opsec.eu> <603EB188CA36FE2EE2198CFE@ogg.in.absolight.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Wed, 16 Jan 2013 16:10:52 -0000 +--On 14 janvier 2013 19:26:58 +0100 Mathieu Arnold wrote: | +--On 14 janvier 2013 19:05:31 +0100 Kurt Jaeger wrote: || Hi! || ||> Today, I was trying to upgrade a 7.0-rel box to 9.1 with freebsd-update, ||> and I get : || [...] ||> The update metadata is correctly signed, but ||> failed an integrity check. ||> Cowardly refusing to proceed any further. || || You can not upgrade from 7.0 to 9.1 directly. || || Use two intermediate steps, 7.4 and 8.3 and try if this works. Add || more intermediate steps, if one fails. | | Hum, sorry, but no, that's not the problem, I just tried and I can upgrade | from 6.2, 6.3, 6.4, 7.1 and 7.2 to 9.1 with freebsd-update directly | without problems. It gives an error on 7.0, which leads me to think that | something's broken on that particular path. | The file[1] that fails integrity check must have had something bad | happening to it when it was created. | | 1: debug tells me it's | 9.1-RELEASE/i386/m/d80b83818c81a090997460d48fb1f53eb14d43072a1d1a4a5ba16d | e4c5ae93b2.gz So, cperciva tells me that it's because of FreeBSD-EN-12:01.freebsd-update.asc[1], patching my freebsd-update solves it. 1: -- Mathieu Arnold From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 16:15:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8444E3DC; Wed, 16 Jan 2013 16:15:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 477FF692; Wed, 16 Jan 2013 16:15:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:84a:f2c4:59a0:2557] (unknown [IPv6:2001:7b8:3a7:0:84a:f2c4:59a0:2557]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E09685C37; Wed, 16 Jan 2013 17:15:07 +0100 (CET) Message-ID: <50F6D20A.6070306@FreeBSD.org> Date: Wed, 16 Jan 2013 17:15:06 +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: Kimmo Paasiala Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , 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, 16 Jan 2013 16:15:09 -0000 On 2013-01-16 13:05, Kimmo Paasiala wrote: > I just updated my stable/9 system after clang3.2 was added. My system > is amd64, both world and kernel are compiled with clang3.2 and the > default compiler is clang. I'm tracking the sources with GIT and the > version I have corresponds to SVN revision r245451. > > Everything else seems to work but the pam authentication module > security/pam_ssh_agent_auth segfaults immediately. ... > #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 > #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7 > #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7 > #3 0x0000000801c0e2e7 in do_log () from /usr/local/lib/pam_ssh_agent_auth.so > #4 0x0000000801c0e4ff in logit () from /usr/local/lib/pam_ssh_agent_auth.so ... > The str*vis() calls suggest that it's something in the libc maybe? Brooks merged the new strvis implementations in r245439, so you may have run into a bug with them. I don't think this is caused specifically by clang, at least not without more proof. :-) Can you try reverting to the revision just before r245439, rebuilding and reinstalling at least libc, and see if the pam_ssh_agent_auth crash goes away? From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 16:27:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BD0CACA for ; Wed, 16 Jan 2013 16:27:18 +0000 (UTC) (envelope-from dddaley@yahoo.com) Received: from nm30-vm1.access.bullet.mail.mud.yahoo.com (nm30-vm1.access.bullet.mail.mud.yahoo.com [66.94.237.87]) by mx1.freebsd.org (Postfix) with ESMTP id D4C4B886 for ; Wed, 16 Jan 2013 16:27:17 +0000 (UTC) Received: from [66.94.237.201] by nm30.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Jan 2013 16:27:17 -0000 Received: from [98.139.44.92] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Jan 2013 16:27:17 -0000 Received: from [127.0.0.1] by omp1029.access.mail.sp2.yahoo.com with NNFMP; 16 Jan 2013 16:27:17 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 22436.27012.bm@omp1029.access.mail.sp2.yahoo.com Received: (qmail 61506 invoked by uid 60001); 16 Jan 2013 16:27:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358353636; bh=dNujTXAJ/trLVgiP2UGlPt5bfkTS3zmStXjCIqvDCKE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=3Fl1JdqUBesz7daogXtl+pTS/3hyZUmjQU7rfniQHDGa9EnPZmT8LycYZVxv/dRQHhoy0KDeIFDyXO3p7Xpon20MAej0dBn4N61tgv7rV2z+WTnO8hcTYj61XSzgRPIDRdGZGp71j+H1FhLTzfNxbPL7+rD0bjZ/d+4ugJUe9a8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=B62I2c2UQtRsHael+Ns6r+1NY3JtOf8U5H4JpmpW0wm1J017vD4vf10r/UaA5CuZrVy0BRM2kJmPHH8PntTX3m2U2XOw4Hz9IftWGrt+xBYuO3p7eNeqOZL4lR2RgER2WRsu+/w3nCginvrCt7jM2odE2H5C1ngZ57RkYGYjZWI=; X-YMail-OSG: gCwAA2AVM1mTOZHPFLrfyH9Mow07wYkriY2d3Dco03E7PbW fIoHaHYfrRd3rr2zdu084XuHEftaRLzXAlYq.TAxFtel2HSfuwnIC3lRigCD zNRQrIzTUpW8jHmzF.9xDpAtMaiixoKyR4WQq_ap900ewIsynST1aOJodUKF .Hjhhd6LZZsfYebnb6IBfXGpXSFMeSqDS_x0gyKZ4zl8UTbkGjzutPoiz2Iv aBQMGy4IZXipWD_HI9bhsxSIswzgoWVXnfcOGCOGsfAE6Gjo_tsJ1A3g1Dgy vKQEJfjssk541IdsUvStpUuijN7wBOVBfJlG5.i04B4O.xPdJEmuyvpSnTpl WlgFcBIu9mwGEU2SGweTEHAnoBFy_zH.ondDrPclAf7J2HRFPjb4PUYPQppC xkcy9X5idY07ixj3lMFaA4k4Yrc8WTaGfMAIUvTTYhyBKqU54wi63QUOImO. F41GCzRIeRVvKI0fM3zvxMXgTw504sCBmd0CVZ2lgM135jkDtwNQmTins Received: from [50.56.228.100] by web181703.mail.ne1.yahoo.com via HTTP; Wed, 16 Jan 2013 08:27:16 PST X-Rocket-MIMEInfo: 001.001, CkkgaGF2ZSBub3RpY2VkIHNpbWlsYXIgdGltZSBpc3N1ZXMgYWZ0ZXIgdXBncmFkaW5nIGZyb20gOC4yIHRvIDguMy4gIEkgaGF2ZW4ndCAKaGFkIHRpbWUgdG8gaW52ZXN0aWdhdGUsIGJ1dCBvZnRlbiB0aGUgdGltZSBkcmlmdCAiZXhjZWVkcyBzYW5pdHkgbGltaXQuIgoKU28sIHRoZSBwcm9ibGVtIGlzIHByZXNlbnQgcHJlIDkueC4gIEkgbmV2ZXIgaGFkIHRoaXMgcHJvYmxlbSB3aGVuIHJ1bm5pbmcgOC4yLgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogRGFuaWVsIEJyYW4BMAEBAQE- X-Mailer: YahooMailRC/718 YahooMailWebService/0.8.130.494 References: Message-ID: <1358353636.28832.YahooMailRC@web181703.mail.ne1.yahoo.com> Date: Wed, 16 Jan 2013 08:27:16 -0800 (PST) From: Dan Daley Subject: Re: time issues and some more To: Daniel Braniss , freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Wed, 16 Jan 2013 16:27:18 -0000 I have noticed similar time issues after upgrading from 8.2 to 8.3. I haven't had time to investigate, but often the time drift "exceeds sanity limit." So, the problem is present pre 9.x. I never had this problem when running 8.2. ________________________________ From: Daniel Braniss To: freebsd-stable@freebsd.org Sent: Wed, January 16, 2013 3:54:44 AM Subject: time issues and some more I resently upgraded a Dell PowerEdge R710, to 9.1-stable, we mainly use it as a backup to several zfs servers (doing send|receive) without major issues till the upgrade, it was running 8.2-stable. now, we see that sometime the time drifts, and today I noticed that it was hung, and once I got unto the ipmi console this is what i got: [SOL Session operational. Use ~? for help] swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: 12288 and things started moving again, in /var/log/messages: Jan 16 03:27:35 store-02 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: 12288 but the REAL time is 7hs ahead!, so time stood still ? and now, of course we get: Jan 16 03:54:19 store-02 ntpd[38163]: time correction of 25216 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. I will now reboot, and try a newer kernel and check, but any insight will be very helpful, thanks, danny _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 17:56:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F8822AE for ; Wed, 16 Jan 2013 17:56:16 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews06.kpnxchange.com (cpsmtpb-ews06.kpnxchange.com [213.75.39.9]) by mx1.freebsd.org (Postfix) with ESMTP id 17240E6D for ; Wed, 16 Jan 2013 17:56:15 +0000 (UTC) Received: from cpsps-ews19.kpnxchange.com ([10.94.84.185]) by cpsmtpb-ews06.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 16 Jan 2013 18:54:59 +0100 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews19.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 16 Jan 2013 18:54:59 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 16 Jan 2013 18:56:07 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 3E17F97D5 for ; Wed, 16 Jan 2013 18:56:07 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: time issues and some more References: Date: Wed, 16 Jan 2013 18:56:06 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.12 (FreeBSD) X-OriginalArrivalTime: 16 Jan 2013 17:56:07.0635 (UTC) FILETIME=[C2AD7A30:01CDF412] X-RcptDomain: 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, 16 Jan 2013 17:56:16 -0000 On Wed, 16 Jan 2013 10:45:49 +0100, Daniel Braniss wrote: > I resently upgraded a Dell PowerEdge R710, to 9.1-stable, we mainly use > it as > a backup to several zfs servers (doing send|receive) without major > issues till > the upgrade, it was running 8.2-stable. > > now, we see that sometime the time drifts, and today I noticed that it > was > hung, and once I got unto the ipmi console this is what i got: > [SOL Session operational. Use ~? for help] > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: 12288 > > and things started moving again, > > in /var/log/messages: > Jan 16 03:27:35 store-02 kernel: swap_pager: indefinite wait buffer: > bufobj: > 0, blkno: 3864, size: 12288 > > but the REAL time is 7hs ahead!, so time stood still ? > and now, of course we get: > Jan 16 03:54:19 store-02 ntpd[38163]: time correction of 25216 seconds > exceeds > sanity limit (1000); set clock manually to the correct UTC time. > > I will now reboot, and try a newer kernel and check, but any insight will > be very helpful, > > thanks, > danny Does BSD 9 choose another timer source than BSD 8? Use sysctl to check these values at your system. kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) kern.eventtimer.timer: LAPIC Or this ones. I always confuse these. kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) i8254(0) dummy(-1000000) kern.timecounter.hardware: TSC-low Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 18:01:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4B9BF427; Wed, 16 Jan 2013 18:01:02 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id 90FFBEC2; Wed, 16 Jan 2013 18:01:01 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so1518190wib.2 for ; Wed, 16 Jan 2013 10:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qZMkTwxHj3cSgS6b36hHfHNKgNFcgKn7+N9JLrEaJmI=; b=JQGWGmdzHEDKmtwySWPUAHdk2ksyWwMd5vIO+WZe1tzq3T1toizRp0eOkzVs441ODS PntBZSPlhZtyJprnXRaRdEPe/w5jHdKQKUF+QuK4RpSbhrEBILAyc+ICV5aW6H6tWHAS 8+YPVgfqXdpEvv3QaCbykBNber3uuGuDAdOKGOs5pgdDtrSgzb2TZEciH+8ve7b06YC0 YW/fcEZgD632oSM9DIJDZH98ehUWr3WnTocgD94KChKQRY9GM5WiEkzjZOKw8KqV0yhQ FxR/JZpyXoZoWel2bwxz5+idy8NKOuD/5oXSCW6Zsqlo5udMFYdZ8LUwAPPy55cWvlHN nMXg== MIME-Version: 1.0 X-Received: by 10.180.81.39 with SMTP id w7mr3805283wix.15.1358359260339; Wed, 16 Jan 2013 10:01:00 -0800 (PST) Received: by 10.216.172.197 with HTTP; Wed, 16 Jan 2013 10:01:00 -0800 (PST) In-Reply-To: <50F6D20A.6070306@FreeBSD.org> References: <50F6D20A.6070306@FreeBSD.org> Date: Wed, 16 Jan 2013 20:01:00 +0200 Message-ID: Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 From: Kimmo Paasiala To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: Brooks Davis , 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, 16 Jan 2013 18:01:02 -0000 On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric wrote: > On 2013-01-16 13:05, Kimmo Paasiala wrote: >> >> I just updated my stable/9 system after clang3.2 was added. My system >> is amd64, both world and kernel are compiled with clang3.2 and the >> default compiler is clang. I'm tracking the sources with GIT and the >> version I have corresponds to SVN revision r245451. >> >> Everything else seems to work but the pam authentication module >> security/pam_ssh_agent_auth segfaults immediately. > > ... > >> #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 >> #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7 >> #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7 >> #3 0x0000000801c0e2e7 in do_log () from >> /usr/local/lib/pam_ssh_agent_auth.so >> #4 0x0000000801c0e4ff in logit () from >> /usr/local/lib/pam_ssh_agent_auth.so > > ... > >> The str*vis() calls suggest that it's something in the libc maybe? > > > Brooks merged the new strvis implementations in r245439, so you may have > run into a bug with them. I don't think this is caused specifically by > clang, at least not without more proof. :-) > > Can you try reverting to the revision just before r245439, rebuilding > and reinstalling at least libc, and see if the pam_ssh_agent_auth crash > goes away? I'm rebuilding world now. Took me some time to figure out how to revert the commits in git. I'll report back once finished. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 19:25:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 26C7B530; Wed, 16 Jan 2013 19:25:35 +0000 (UTC) (envelope-from sodynet1@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 D2D39777; Wed, 16 Jan 2013 19:25:34 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so3267126iec.13 for ; Wed, 16 Jan 2013 11:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=uyRRoZLItTDyoTZ7rqSnZGmlVCXE6PM1R8fYofsz5Q4=; b=MvePhaCNGXDjwXcQBEaFGidRWf1Yr6q9oO1nQlYkpQS9/dMOgcqNagbZu0Yl0GS/Ze lzfcagIFc5eFZB3IXQT1hjq8edQDOPu2H9gI5j49WrDi+1WDqkepUY3y52xzjEEtA5vR RihitiJt+mUv7L9XAMJlr93eLTao4Nl3UiJ7YjRIdK9K192LfA/GDDeOdmF5C6FqIv7t 4LEzm/WGUTb+VXllu4wheVJqeowKj6v3tPC4X3g3sOqEjopuuhkm0CszMn073Gi07GJO iMQz2eQnHT0XobSBhAxNVxHKnX9wDOWnkGDEDwOJivwGzCLv+Yphm60EnjUS3ldN32QP 7uAA== MIME-Version: 1.0 X-Received: by 10.50.183.227 with SMTP id ep3mr5395288igc.107.1358364334092; Wed, 16 Jan 2013 11:25:34 -0800 (PST) Received: by 10.64.51.98 with HTTP; Wed, 16 Jan 2013 11:25:33 -0800 (PST) Received: by 10.64.51.98 with HTTP; Wed, 16 Jan 2013 11:25:33 -0800 (PST) Date: Wed, 16 Jan 2013 21:25:33 +0200 Message-ID: Subject: Failsafe on kernel panic From: Sami Halabi To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 16 Jan 2013 19:25:35 -0000 Hi everyone, I have a production box, in which I want to install new kernel without any remotd kvn. my problem is its 2 hours away, and if a kernel panic occurs I got a problem. I woner if I can seg failsafe script to load the old kernel in case of psnic. Sami From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 20:13:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C23CC5B4; Wed, 16 Jan 2013 20:13:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2ACA1B; Wed, 16 Jan 2013 20:13:28 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DCF23B939; Wed, 16 Jan 2013 15:13:27 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Failsafe on kernel panic Date: Wed, 16 Jan 2013 15:13:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301161513.27016.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 Jan 2013 15:13:28 -0500 (EST) Cc: freebsd-stable@freebsd.org, Sami Halabi 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, 16 Jan 2013 20:13:28 -0000 On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > Hi everyone, > I have a production box, in which I want to install new kernel without any > remotd kvn. > my problem is its 2 hours away, and if a kernel panic occurs I got a > problem. > I woner if I can seg failsafe script to load the old kernel in case of > psnic. man nextboot (if you are using UFS) -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 20:57:20 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AF5764D for ; Wed, 16 Jan 2013 20:57:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD96D72 for ; Wed, 16 Jan 2013 20:57:18 +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 WAA04610; Wed, 16 Jan 2013 22:57: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 1Tva2u-000Ocr-1Y; Wed, 16 Jan 2013 22:57:16 +0200 Message-ID: <50F7142B.7080504@FreeBSD.org> Date: Wed, 16 Jan 2013 22:57: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: Willem Jan Withagen , Julian Stecklina Subject: Re: Some new hardware with 9.1 does not reboot easily References: <50ACA518.4050309@digiware.nl> <50AD0AC2.5070804@FreeBSD.org> <50AD0B29.6060602@FreeBSD.org> <50AD0F00.5020600@digiware.nl> <50AD13EE.8050901@digiware.nl> <50AD17E4.50104@FreeBSD.org> <50AD189D.4040902@digiware.nl> <50AD1941.2020108@FreeBSD.org> <50ADF362.2040803@FreeBSD.org> <20121123140932.3a6deff6@mr129166> <50AF88AA.1060003@FreeBSD.org> <50AFF419.3070604@digiware.nl> <50AFF7C1.2090405@FreeBSD.org> <50AFFB9C.8050101@digiware.nl> <20121126111052.68136d00@mr129166> <50B3421B.2010606@FreeBSD.org> <20121129094137.6829eae8@mr129166> <50B7229D.4090901@digiware.nl> <50B77A6A.9050604@FreeBSD.org> <50B77C3B.6070305@digiware.nl> <50B77D70.1000803@FreeBSD.org> <871udwgbya.fsf@os.inf.tu-dresden.de> <50F06A43.801@digiware.nl> In-Reply-To: <50F06A43.801@digiware.nl> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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, 16 Jan 2013 20:57:20 -0000 on 11/01/2013 21:38 Willem Jan Withagen said the following: > On 2013-01-07 18:06, Julian Stecklina wrote: >> Has this been resolved? I still see a hang on reboot/shutdown on my box >> (zfs root on USB thumb drive), but I am not sure if the problem is >> related. > > Could very well be be. > > I have again the same problem as I reported before with the full and new > 9.1 code. > But did not have time yet to build a system te test with. > > My other 9.1 box is my ZFS only fileserver. And I do not want to fidle > to much with it. Have you guys tried to obtain a stack trace of the stuck reboot thread (in ddb)? Not all hangs in reboot have the same cause... -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jan 16 21:27:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0BC4E29; Wed, 16 Jan 2013 21:27:54 +0000 (UTC) (envelope-from sodynet1@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 8F998EF7; Wed, 16 Jan 2013 21:27:54 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so3516672iec.13 for ; Wed, 16 Jan 2013 13:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oREYJitDKadiVyVzx9Hb+7pXoBahgQjGGBZlFCQxB+U=; b=s2tYux9KOgPPK3n8/RnctVbdV6jAnnT71t20tbJGKFLUc74/nIOBzt2dmSc1yDxfn/ vGk6pD/g5PVu8M8WP+PPrz4pSTU6W5YgI9nhnhUyh2wjycKZaXODC1XHx6Tjj9BpS1jM O0c5g9hZJe3OKSaq1mxfSdEv0aH9BHelEgV7VTahq6e45mGThEzmMwI6UEr9PPgOcUSD 0Ts/OpHeD6Ti709gm75W1EGXYfHSBfJFQMkhNTRknqr4dm72omec3Ylyioq7hedQVlEd Es4sT7kSfmznxmqfL/s2A+R742pXB4AJIE+t2qt+PSYiGwavhB2hG7rq+nsiZ/3FLGTX 40Xw== MIME-Version: 1.0 X-Received: by 10.50.183.227 with SMTP id ep3mr5663218igc.107.1358371673631; Wed, 16 Jan 2013 13:27:53 -0800 (PST) Received: by 10.64.51.98 with HTTP; Wed, 16 Jan 2013 13:27:53 -0800 (PST) In-Reply-To: <201301161513.27016.jhb@freebsd.org> References: <201301161513.27016.jhb@freebsd.org> Date: Wed, 16 Jan 2013 23:27:53 +0200 Message-ID: Subject: Re: Failsafe on kernel panic From: Sami Halabi To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@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, 16 Jan 2013 21:27:55 -0000 Thank you for your response, very helpful. one question - how do i configure auto-reboot once kernel panic occurs? Sami On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > Hi everyone, > > I have a production box, in which I want to install new kernel without > any > > remotd kvn. > > my problem is its 2 hours away, and if a kernel panic occurs I got a > > problem. > > I woner if I can seg failsafe script to load the old kernel in case of > > psnic. > > man nextboot (if you are using UFS) > > -- > John Baldwin > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 00:11:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 946E94DE; Thu, 17 Jan 2013 00:11:17 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 5AB4C97C; Thu, 17 Jan 2013 00:11:16 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r0H0BHhJ043757; Wed, 16 Jan 2013 18:11:17 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r0H0BGa8043756; Wed, 16 Jan 2013 18:11:16 -0600 (CST) (envelope-from brooks) Date: Wed, 16 Jan 2013 18:11:16 -0600 From: Brooks Davis To: Kimmo Paasiala Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 Message-ID: <20130117001116.GD29437@lor.one-eyed-alien.net> References: <50F6D20A.6070306@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qrgsu6vtpU/OV/zm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Dimitry Andric 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, 17 Jan 2013 00:11:17 -0000 --Qrgsu6vtpU/OV/zm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 16, 2013 at 08:01:00PM +0200, Kimmo Paasiala wrote: > On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric wrote: > > On 2013-01-16 13:05, Kimmo Paasiala wrote: > >> > >> I just updated my stable/9 system after clang3.2 was added. My system > >> is amd64, both world and kernel are compiled with clang3.2 and the > >> default compiler is clang. I'm tracking the sources with GIT and the > >> version I have corresponds to SVN revision r245451. > >> > >> Everything else seems to work but the pam authentication module > >> security/pam_ssh_agent_auth segfaults immediately. > > > > ... > > > >> #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 > >> #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7 > >> #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7 > >> #3 0x0000000801c0e2e7 in do_log () from > >> /usr/local/lib/pam_ssh_agent_auth.so > >> #4 0x0000000801c0e4ff in logit () from > >> /usr/local/lib/pam_ssh_agent_auth.so > > > > ... > > > >> The str*vis() calls suggest that it's something in the libc maybe? > > > > > > Brooks merged the new strvis implementations in r245439, so you may have > > run into a bug with them. I don't think this is caused specifically by > > clang, at least not without more proof. :-) > > > > Can you try reverting to the revision just before r245439, rebuilding > > and reinstalling at least libc, and see if the pam_ssh_agent_auth crash > > goes away? >=20 > I'm rebuilding world now. Took me some time to figure out how to > revert the commits in git. I'll report back once finished. NetBSD and OpenBSD use different signatures for strnvis(). :( pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD one but ours is the NetBSD one. The port will need to be patched to use the openbsd version like it was doing or to swap the second and third arguments when build on newer versions of FreeBSD. -- Brooks --Qrgsu6vtpU/OV/zm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD4DBQFQ90GkXY6L6fI4GtQRAn2cAJd3pImKCFw5WQwGfrbq0h5O6u+bAKDNT1h0 qkkIS4ub6iaR3Si14aqVZw== =sjN8 -----END PGP SIGNATURE----- --Qrgsu6vtpU/OV/zm-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 00:16:49 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0F9817EA; Thu, 17 Jan 2013 00:16:49 +0000 (UTC) (envelope-from prvs=172911332d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 727599F9; Thu, 17 Jan 2013 00:16:48 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001731834.msg; Thu, 17 Jan 2013 00:16:45 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Jan 2013 00:16:45 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=172911332d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <86386CBB12394FDAB981F1C19CBC520B@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , "Willem Jan Withagen" , "Julian Stecklina" References: <50ACA518.4050309@digiware.nl> <50AD0AC2.5070804@FreeBSD.org> <50AD0B29.6060602@FreeBSD.org> <50AD0F00.5020600@digiware.nl> <50AD13EE.8050901@digiware.nl> <50AD17E4.50104@FreeBSD.org> <50AD189D.4040902@digiware.nl> <50AD1941.2020108@FreeBSD.org> <50ADF362.2040803@FreeBSD.org> <20121123140932.3a6deff6@mr129166> <50AF88AA.1060003@FreeBSD.org> <50AFF419.3070604@digiware.nl> <50AFF7C1.2090405@FreeBSD.org> <50AFFB9C.8050101@digiware.nl> <20121126111052.68136d00@mr129166> <50B3421B.2010606@FreeBSD.org> <20121129094137.6829eae8@mr129166> <50B7229D.4090901@digiware.nl> <50B77A6A.9050604@FreeBSD.org> <50B77C3B.6070305@digiware.nl> <50B77D70.1000803@FreeBSD.org> <871udwgbya.fsf@os.inf.tu-dresden.de> <50F06A43.801@digiware.nl> <50F7142B.7080504@FreeBSD.org> Subject: Re: Some new hardware with 9.1 does not reboot easily Date: Thu, 17 Jan 2013 00:17:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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, 17 Jan 2013 00:16:49 -0000 ----- Original Message ----- From: "Andriy Gapon" > on 11/01/2013 21:38 Willem Jan Withagen said the following: >> On 2013-01-07 18:06, Julian Stecklina wrote: >>> Has this been resolved? I still see a hang on reboot/shutdown on my box >>> (zfs root on USB thumb drive), but I am not sure if the problem is >>> related. >> >> Could very well be be. >> >> I have again the same problem as I reported before with the full and new >> 9.1 code. >> But did not have time yet to build a system te test with. >> >> My other 9.1 box is my ZFS only fileserver. And I do not want to fidle >> to much with it. Not sure if this has been suggested or ruled out as yet but if you have usb enabled, you don't need to be using it, try the following see if it helps? sysctl hw.usb.no_shutdown_wait=1 If it does 1. Temporary fix is to pop that in /etc/sysctl.conf 2. Worth investigating which USB component isn't dropping references correctly. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 02:08:40 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DACE269; Thu, 17 Jan 2013 02:08:40 +0000 (UTC) (envelope-from jsteckli@os.inf.tu-dresden.de) Received: from os.inf.tu-dresden.de (os.inf.tu-dresden.de [IPv6:2002:8d4c:3001:48::99]) by mx1.freebsd.org (Postfix) with ESMTP id B3C7681; Thu, 17 Jan 2013 02:08:39 +0000 (UTC) Received: from [178.5.123.175] (helo=android-44bda2b04415f5bf.fritz.box) by os.inf.tu-dresden.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.80.1) id 1TveuD-0003b1-Nx; Thu, 17 Jan 2013 03:08:38 +0100 User-Agent: Kaiten Mail In-Reply-To: <86386CBB12394FDAB981F1C19CBC520B@multiplay.co.uk> References: <50ACA518.4050309@digiware.nl> <50AD0AC2.5070804@FreeBSD.org> <50AD0B29.6060602@FreeBSD.org> <50AD0F00.5020600@digiware.nl> <50AD13EE.8050901@digiware.nl> <50AD17E4.50104@FreeBSD.org> <50AD189D.4040902@digiware.nl> <50AD1941.2020108@FreeBSD.org> <50ADF362.2040803@FreeBSD.org> <20121123140932.3a6deff6@mr129166> <50AF88AA.1060003@FreeBSD.org> <50AFF419.3070604@digiware.nl> <50AFF7C1.2090405@FreeBSD.org> <50AFFB9C.8050101@digiware.nl> <20121126111052.68136d00@mr129166> <50B3421B.2010606@FreeBSD.org> <20121129094137.6829eae8@mr129166> <50B7229D.4090901@digiware.nl> <50B77A6A.9050604@FreeBSD.org> <50B77C3B.6070305@digiware.nl> <50B77D70.1000803@FreeBSD.org> <871udwgbya.fsf@os.inf.tu-dresden.de> <50F06A43.801@digiware.nl> <50F7142B.7080504@FreeBSD.org> <86386CBB12394FDAB981F1C19CBC520B@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----0GPH8U879RVWG3D272YCM2LZJ06L1C" Subject: Re: Some new hardware with 9.1 does not reboot easily From: Julian Stecklina Date: Thu, 17 Jan 2013 03:08:33 +0100 To: Steven Hartland , Andriy Gapon , Willem Jan Withagen Message-ID: <0bba4bca-218c-434a-a25d-a988df155207@email.android.com> 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, 17 Jan 2013 02:08:40 -0000 ------0GPH8U879RVWG3D272YCM2LZJ06L1C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Steven Hartland wrote: >----- Original Message ----- >From: "Andriy Gapon" > > >> on 11/01/2013 21:38 Willem Jan Withagen said the following: >>> On 2013-01-07 18:06, Julian Stecklina wrote: >>>> Has this been resolved? I still see a hang on reboot/shutdown on my >box >>>> (zfs root on USB thumb drive), but I am not sure if the problem is >>>> related. >>> >>> Could very well be be. >>> >>> I have again the same problem as I reported before with the full and >new >>> 9.1 code. >>> But did not have time yet to build a system te test with. >>> >>> My other 9.1 box is my ZFS only fileserver. And I do not want to >fidle >>> to much with it. > >Not sure if this has been suggested or ruled out as yet but if you have >usb >enabled, you don't need to be using it, try the following see if it >helps? > >sysctl hw.usb.no_shutdown_wait=1 With that sysctl set the box shuts down just fine. Thanks! > >If it does >1. Temporary fix is to pop that in /etc/sysctl.conf >2. Worth investigating which USB component isn't dropping references >correctly. I only have an USB thumb drive and a USB soundcard attached. I tried it without the soundcard attached and would still not reset/shutdown, so that does not seem to be the problem. I attached usbconfig list output. Julian -- Sent from Kaiten Mail. Please excuse my brevity. ------0GPH8U879RVWG3D272YCM2LZJ06L1C Content-Transfer-Encoding: base64 Content-Type: text/plain; name="usbdevs.txt" Content-Disposition: attachment; filename="usbdevs.txt"; size=669 dWdlbjAuMTogPE9IQ0kgcm9vdCBIVUIgQVRJPiBhdCB1c2J1czAsIGNmZz0wIG1kPUhPU1Qgc3Bk PUZVTEwgKDEyTWJwcykgcHdyPVNBVkUKdWdlbjEuMTogPEVIQ0kgcm9vdCBIVUIgQVRJPiBhdCB1 c2J1czEsIGNmZz0wIG1kPUhPU1Qgc3BkPUhJR0ggKDQ4ME1icHMpIHB3cj1TQVZFCnVnZW4yLjE6 IDxPSENJIHJvb3QgSFVCIEFUST4gYXQgdXNidXMyLCBjZmc9MCBtZD1IT1NUIHNwZD1GVUxMICgx Mk1icHMpIHB3cj1TQVZFCnVnZW4zLjE6IDxFSENJIHJvb3QgSFVCIEFUST4gYXQgdXNidXMzLCBj Zmc9MCBtZD1IT1NUIHNwZD1ISUdIICg0ODBNYnBzKSBwd3I9U0FWRQp1Z2VuNC4xOiA8T0hDSSBy b290IEhVQiBBVEk+IGF0IHVzYnVzNCwgY2ZnPTAgbWQ9SE9TVCBzcGQ9RlVMTCAoMTJNYnBzKSBw d3I9U0FWRQp1Z2VuNS4xOiA8RUhDSSByb290IEhVQiBBVEk+IGF0IHVzYnVzNSwgY2ZnPTAgbWQ9 SE9TVCBzcGQ9SElHSCAoNDgwTWJwcykgcHdyPVNBVkUKdWdlbjIuMjogPFVTQiBBdWRpbyBDT0RF QyBCdXJyLUJyb3duIGZyb20gVEk+IGF0IHVzYnVzMiwgY2ZnPTAgbWQ9SE9TVCBzcGQ9RlVMTCAo MTJNYnBzKSBwd3I9T04KdWdlbjMuMjogPENydXplciBTd2l0Y2ggU2FuRGlzaz4gYXQgdXNidXMz LCBjZmc9MCBtZD1IT1NUIHNwZD1ISUdIICg0ODBNYnBzKSBwd3I9T04K ------0GPH8U879RVWG3D272YCM2LZJ06L1C-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 03:18:56 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0116036E; Thu, 17 Jan 2013 03:18:55 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id BD2A2674; Thu, 17 Jan 2013 03:18:55 +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 r0H3Imon083026; Wed, 16 Jan 2013 20:18:49 -0700 (MST) (envelope-from ian@FreeBSD.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 r0H3Ikks005602; Wed, 16 Jan 2013 20:18:46 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Failsafe on kernel panic From: Ian Lepore To: Sami Halabi In-Reply-To: References: <201301161513.27016.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Jan 2013 20:18:45 -0700 Message-ID: <1358392725.32417.179.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, "freebsd-stable@freebsd.org" , John Baldwin 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, 17 Jan 2013 03:18:56 -0000 On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > Thank you for your response, very helpful. > one question - how do i configure auto-reboot once kernel panic occurs? > > Sami > >From src/sys/conf/NOTES, this may be what you're looking for... # # Don't enter the debugger for a panic. Intended for unattended operation # where you may want to enter the debugger from the console, but still want # the machine to recover from a panic. # options KDB_UNATTENDED But I think it only has meaning if you have option KDB in effect, otherwise it should just reboot itself after a 15 second pause. -- Ian > > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > > Hi everyone, > > > I have a production box, in which I want to install new kernel without > > any > > > remotd kvn. > > > my problem is its 2 hours away, and if a kernel panic occurs I got a > > > problem. > > > I woner if I can seg failsafe script to load the old kernel in case of > > > psnic. > > > > man nextboot (if you are using UFS) > > > > -- > > John Baldwin > > > > > From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 03:49:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1CDA5A7; Thu, 17 Jan 2013 03:49:55 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by mx1.freebsd.org (Postfix) with ESMTP id F36067E9; Thu, 17 Jan 2013 03:49:54 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id dr13so1318842wgb.1 for ; Wed, 16 Jan 2013 19:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TBE02La1pyJPbELoCqCtAXLJu0mZRVeUfdHJP/KrmQA=; b=khyp63ZYF2KnBLcEJngFlfeFRdLM5jHNRHQO07RZXk22+OI2K/j8E+dGC0pfTU4V0v 9vRO3A7GaBKefbI/s/yB5f74Du4JQA1X3kUynfcbpjIm4GXC88rhQx+wtC5C8xdgH6/H g6ah1dmy1qPRDoVdHgzyG8czNT0Ego9Pe1NUwEAhEyae1zCt12reuzYnXGI3lIIA3o85 aesh8bVOzDQlVWUoNNGK3JQqt9MJwybr1Gv8Xxlh7rjctCAc74QTtLOcMUszW68jfA39 +4A0mpF6iDI0nrJ8iQjSiyHHVx/WBEh6qalTjNpbr0gBCESR2R+w/bR/fSEuejbZZPmv iPFg== MIME-Version: 1.0 X-Received: by 10.180.93.133 with SMTP id cu5mr13300454wib.32.1358394588417; Wed, 16 Jan 2013 19:49:48 -0800 (PST) Received: by 10.216.172.197 with HTTP; Wed, 16 Jan 2013 19:49:48 -0800 (PST) In-Reply-To: <20130117001116.GD29437@lor.one-eyed-alien.net> References: <50F6D20A.6070306@FreeBSD.org> <20130117001116.GD29437@lor.one-eyed-alien.net> Date: Thu, 17 Jan 2013 05:49:48 +0200 Message-ID: Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 From: Kimmo Paasiala To: Brooks Davis Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Dimitry Andric 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, 17 Jan 2013 03:49:55 -0000 On Thu, Jan 17, 2013 at 2:11 AM, Brooks Davis wrote: > On Wed, Jan 16, 2013 at 08:01:00PM +0200, Kimmo Paasiala wrote: >> On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric wrote: >> > On 2013-01-16 13:05, Kimmo Paasiala wrote: >> >> >> >> I just updated my stable/9 system after clang3.2 was added. My system >> >> is amd64, both world and kernel are compiled with clang3.2 and the >> >> default compiler is clang. I'm tracking the sources with GIT and the >> >> version I have corresponds to SVN revision r245451. >> >> >> >> Everything else seems to work but the pam authentication module >> >> security/pam_ssh_agent_auth segfaults immediately. >> > >> > ... >> > >> >> #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 >> >> #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7 >> >> #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7 >> >> #3 0x0000000801c0e2e7 in do_log () from >> >> /usr/local/lib/pam_ssh_agent_auth.so >> >> #4 0x0000000801c0e4ff in logit () from >> >> /usr/local/lib/pam_ssh_agent_auth.so >> > >> > ... >> > >> >> The str*vis() calls suggest that it's something in the libc maybe? >> > >> > >> > Brooks merged the new strvis implementations in r245439, so you may have >> > run into a bug with them. I don't think this is caused specifically by >> > clang, at least not without more proof. :-) >> > >> > Can you try reverting to the revision just before r245439, rebuilding >> > and reinstalling at least libc, and see if the pam_ssh_agent_auth crash >> > goes away? >> >> I'm rebuilding world now. Took me some time to figure out how to >> revert the commits in git. I'll report back once finished. > > NetBSD and OpenBSD use different signatures for strnvis(). :( > pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD > one but ours is the NetBSD one. The port will need to be patched to use > the openbsd version like it was doing or to swap the second and third > arguments when build on newer versions of FreeBSD. > > -- Brooks Doesn't the change to strnvis() break the ABI on FreeBSD 9.X? I thought you could always compile a binary on an earlier version of FreeBSD 9.X and trust it to work without recompiling on any later minor version of the same major version line. (dynamic link libraries that are from ports excluded of course) -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 04:45:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E590ACB3; Thu, 17 Jan 2013 04:45:55 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by mx1.freebsd.org (Postfix) with ESMTP id E3AE82BB; Thu, 17 Jan 2013 04:45:54 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b47so978525eek.1 for ; Wed, 16 Jan 2013 20:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XyKU1Aect6zJaoi4QRKjATG61QSb7X5Or0Ikdb/E0u8=; b=jYqjrSrdb5gYfUWwD+SPbslFAq2un/2Cc0hG6mi2ZaasCumXjAahyDNQIZpaY3rVQa XjaByfLpvW1ISJrFL26STmSMu06VuJj3A01b8c8y7rKjoIYwk8n9SnsITPQhADtr6Qkn nuYxyR4G6XETP/02RIbOlyBXjIGD7z9ZZGUXo+yYkW8PYi91dRd4c9SNcwLUUbaW2pNL QzcgQQVJBxOy6UAY3YtZhm3aDD260Ako5VTO63nNzHmfsTScdO6Gal64XtgOeGXZLAL8 JyOB9Rpxr5A3yemX40pKndooA/6qYfBezHANKuDbkOFyn0lYd2kUOi8JBiXFh3kwoRdG dHYw== MIME-Version: 1.0 X-Received: by 10.14.216.70 with SMTP id f46mr9752694eep.12.1358397948295; Wed, 16 Jan 2013 20:45:48 -0800 (PST) Received: by 10.14.127.67 with HTTP; Wed, 16 Jan 2013 20:45:48 -0800 (PST) Received: by 10.14.127.67 with HTTP; Wed, 16 Jan 2013 20:45:48 -0800 (PST) In-Reply-To: <1358392725.32417.179.camel@revolution.hippie.lan> References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> Date: Thu, 17 Jan 2013 06:45:48 +0200 Message-ID: Subject: Re: Failsafe on kernel panic From: Sami Halabi To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, John Baldwin 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, 17 Jan 2013 04:45:56 -0000 Its only a kernel option? There is no flag to pass to the loader? SAMI =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 17 =D7=91=D7=99=D7=A0=D7=95 2013 05:18= , =D7=9E=D7=90=D7=AA "Ian Lepore" : > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > > Thank you for your response, very helpful. > > one question - how do i configure auto-reboot once kernel panic occurs? > > > > Sami > > > > From src/sys/conf/NOTES, this may be what you're looking for... > > # > # Don't enter the debugger for a panic. Intended for unattended operation > # where you may want to enter the debugger from the console, but still wa= nt > # the machine to recover from a panic. > # > options KDB_UNATTENDED > > But I think it only has meaning if you have option KDB in effect, > otherwise it should just reboot itself after a 15 second pause. > > -- Ian > > > > > > > > > > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > > > > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > > > Hi everyone, > > > > I have a production box, in which I want to install new kernel > without > > > any > > > > remotd kvn. > > > > my problem is its 2 hours away, and if a kernel panic occurs I got = a > > > > problem. > > > > I woner if I can seg failsafe script to load the old kernel in case > of > > > > psnic. > > > > > > man nextboot (if you are using UFS) > > > > > > -- > > > John Baldwin > > > > > > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 05:24:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3FB583A5; Thu, 17 Jan 2013 05:24:39 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A1D6E3DB; Thu, 17 Jan 2013 05:24:38 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so1355014wgb.17 for ; Wed, 16 Jan 2013 21:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sOL5zdmsXoEMzeF3vXfwy+lge44rcvlI1Ez0NUQrhsE=; b=xyeLeaOZ4sSOHmBFXmLvaAf3A2B+HTj62bRj+kgnDgdL/gy5qHOUBMXrsY+VNIVjye AXP9byrWxUPFdPJk/EuRsW468qUYmV1HV2V9MyAGGOiGizrRVgo0NbkE3arm0O6mXxY6 ztJzcVPX2Ku2keY7rYcoLSWL1KR7yeAr9C2QpXsEGtOUrOyhIkHxS2c4CkkETT/ecRpD G5JNNS+xjvjNlmihG878bF7kcH++RwKPM0/YJCjUPrGDoQB8mjaT8DFaFivgkzvpfROP Vr1uNXTEDv9FCs491RDQMBwvKoM3b+3yu+2jLAZdkANSLiJMxfmXcM67kcorGtmk/xUg vbnw== MIME-Version: 1.0 X-Received: by 10.194.21.70 with SMTP id t6mr6064283wje.42.1358400277499; Wed, 16 Jan 2013 21:24:37 -0800 (PST) Received: by 10.216.172.197 with HTTP; Wed, 16 Jan 2013 21:24:35 -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: Thu, 17 Jan 2013 07:24:35 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: Phil Kulin 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, 17 Jan 2013 05:24:39 -0000 On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin wrote: > 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 I don't have an 8.X system to test but I guess it's fine. Any more interest in this? I'd love to see this added, not because I wrote it but because I want to contribute in any way I can. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 06:45:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 72599297; Thu, 17 Jan 2013 06:45:52 +0000 (UTC) (envelope-from sodynet1@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 913B1820; Thu, 17 Jan 2013 06:45:51 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id b15so1015562eek.39 for ; Wed, 16 Jan 2013 22:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=69I0/3QjPXdUaHeCFXq0MLonfVxOBlFbs3v/31VUX1Q=; b=0K3Fu1dphxP9Pzv6+GkqMoRC/HB+ihBkcTzlhrQz4KgFWiAa9ERTjc/eA3Sram6Kkx AT2P9F0RqbYAasc672XCx6WkmtuWvNR2A9yoVf7qdi4O7TjpFjkVekQ2g3Cv3zqg4hJ1 LmR9BzzkvwnVh5dZ3F3bKAw+DOT7sMRpFd+DOmpHt3yKVxxTgMxkraAzZmIQlUIL2Q27 3LmSr+yBhr2AYIeO/PV7ZJGNfTBWzX6QvMcE4DvXIxDZ7sZe2PHjIxNBoUGQzONPx0Py E/YY0E95CI4CzuVRIuhbN7esflkITFlgfk81afActnUByp3veXAuQ36Jl8dBTpPCp7Lb y9ng== MIME-Version: 1.0 X-Received: by 10.14.221.5 with SMTP id q5mr10489754eep.33.1358404739884; Wed, 16 Jan 2013 22:38:59 -0800 (PST) Received: by 10.14.127.67 with HTTP; Wed, 16 Jan 2013 22:38:59 -0800 (PST) In-Reply-To: References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> Date: Thu, 17 Jan 2013 08:38:59 +0200 Message-ID: Subject: Re: Failsafe on kernel panic From: Sami Halabi To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, "freebsd-stable@freebsd.org" , John Baldwin 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, 17 Jan 2013 06:45:52 -0000 btw: i don't see any options in my kernel config for KBD / Unatteneded , th eonly thing that mention its is: device ukbd Sami On Thu, Jan 17, 2013 at 6:45 AM, Sami Halabi wrote: > Its only a kernel option? There is no flag to pass to the loader? > > SAMI > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 17 =D7=91=D7=99=D7=A0=D7=95 2013 05:= 18, =D7=9E=D7=90=D7=AA "Ian Lepore" : > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: >> > Thank you for your response, very helpful. >> > one question - how do i configure auto-reboot once kernel panic occurs= ? >> > >> > Sami >> > >> >> From src/sys/conf/NOTES, this may be what you're looking for... >> >> # >> # Don't enter the debugger for a panic. Intended for unattended operatio= n >> # where you may want to enter the debugger from the console, but still >> want >> # the machine to recover from a panic. >> # >> options KDB_UNATTENDED >> >> But I think it only has meaning if you have option KDB in effect, >> otherwise it should just reboot itself after a 15 second pause. >> >> -- Ian >> >> >> >> >> >> >> > >> > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote= : >> > >> > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: >> > > > Hi everyone, >> > > > I have a production box, in which I want to install new kernel >> without >> > > any >> > > > remotd kvn. >> > > > my problem is its 2 hours away, and if a kernel panic occurs I got= a >> > > > problem. >> > > > I woner if I can seg failsafe script to load the old kernel in cas= e >> of >> > > > psnic. >> > > >> > > man nextboot (if you are using UFS) >> > > >> > > -- >> > > John Baldwin >> > > >> > >> > >> > >> >> >> --=20 Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 07:06:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D5927A4; Thu, 17 Jan 2013 07:06:28 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by mx1.freebsd.org (Postfix) with ESMTP id D5FC18D7; Thu, 17 Jan 2013 07:06:27 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id e13so4225330iej.4 for ; Wed, 16 Jan 2013 23:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zbEE7NyGn80IrmAEimyWHj0EjgZnGvbbVxCdSgultK8=; b=FmuhtSnxDr0aXkqjkxJaFwwy+jW2DfAr7E8usu0dfu838XJHigXbZAIfj983JBFfBj NO3r+T6CzWkZ3dZ6Pe51OfERJSJoHyt+gmjdsiTaW5FXMZVzAvmADUUdnU5dV0zQ+2Am 3Wp5mLrPtHu7OyHeDF5cJe14sXgMkf5AHb70VMQEho3MI2NwGDSImdMGIMRWb0kHPiI9 utWCDEQ//ieNmjE+vZYemgemWJmGo8zmIw05rRjsJcqs8l+6G8ikQTncqHpiWWiEGLlo XMZQOjgDerIRMxQHNuduY0RYZzSGBWxKC9A8528L1w9hCth8jNgbrl0pO6b7zqoAY/uy Tccg== MIME-Version: 1.0 X-Received: by 10.50.11.193 with SMTP id s1mr2952103igb.109.1358406387172; Wed, 16 Jan 2013 23:06:27 -0800 (PST) Received: by 10.64.143.138 with HTTP; Wed, 16 Jan 2013 23:06:27 -0800 (PST) In-Reply-To: References: <50F6D20A.6070306@FreeBSD.org> Date: Thu, 17 Jan 2013 09:06:27 +0200 Message-ID: Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 From: Kimmo Paasiala To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: Brooks Davis , 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, 17 Jan 2013 07:06:28 -0000 On Wed, Jan 16, 2013 at 8:01 PM, Kimmo Paasiala wrote: > On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric wrote: >> On 2013-01-16 13:05, Kimmo Paasiala wrote: >>> >>> I just updated my stable/9 system after clang3.2 was added. My system >>> is amd64, both world and kernel are compiled with clang3.2 and the >>> default compiler is clang. I'm tracking the sources with GIT and the >>> version I have corresponds to SVN revision r245451. >>> >>> Everything else seems to work but the pam authentication module >>> security/pam_ssh_agent_auth segfaults immediately. >> >> ... >> >>> #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 >>> #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7 >>> #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7 >>> #3 0x0000000801c0e2e7 in do_log () from >>> /usr/local/lib/pam_ssh_agent_auth.so >>> #4 0x0000000801c0e4ff in logit () from >>> /usr/local/lib/pam_ssh_agent_auth.so >> >> ... >> >>> The str*vis() calls suggest that it's something in the libc maybe? >> >> >> Brooks merged the new strvis implementations in r245439, so you may have >> run into a bug with them. I don't think this is caused specifically by >> clang, at least not without more proof. :-) >> >> Can you try reverting to the revision just before r245439, rebuilding >> and reinstalling at least libc, and see if the pam_ssh_agent_auth crash >> goes away? > Confirmed. Reverting world to one commit before r245439 and using the version of the port I used before fixes the problem. Trying to use the version I compiled with post r245439 world results in "su: pam_start: system error" when used on pre r245439 world. I have to repeat my question, isn't this the definition of ABI breakage? -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 07:22:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B848FA94 for ; Thu, 17 Jan 2013 07:22:45 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 80709968 for ; Thu, 17 Jan 2013 07:22:45 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id F31A3450CD; Thu, 17 Jan 2013 07:22:37 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk F31A3450CD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1358407358; bh=esALRKCVY2k0YRADNrEbA2TXAfBR1eRywz+XJMPzGvg=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=o5L2kN//sKnP+rsyqaaTV94ERcy1B9Yz0va8Y8VRy6hgcvbroHD7n/rLSJ9Folz5Q NW+fhLSvcI2x2b0Kru9yAiFufVf6pm4VxSJsjU7cfxjGuYvjHhiDRMLuXrY+gKa3vO SDKYW0+QdvHt6X0E2UlSyXXUK/oyJ3gY1lv4PQgU= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 175EA8A71; Thu, 17 Jan 2013 07:22:34 +0000 (GMT) Date: Thu, 17 Jan 2013 07:22:34 +0000 From: Ben Morrow To: sodynet1@gmail.com, freebsd-stable@freebsd.org Subject: Re: Failsafe on kernel panic Message-ID: <20130117072226.GA38991@anubis.morrow.me.uk> References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Newsgroups: gmane.os.freebsd.devel.hackers,gmane.os.freebsd.stable Organization: morrow.me.uk 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: Thu, 17 Jan 2013 07:22:45 -0000 Quoth Sami Halabi : > בת×ריך 17 בינו 2013 05:18, מ×ת "Ian Lepore" : > > > > From src/sys/conf/NOTES, this may be what you're looking for... > > > > # > > # Don't enter the debugger for a panic. Intended for unattended operation > > # where you may want to enter the debugger from the console, but still want > > # the machine to recover from a panic. > > # > > options KDB_UNATTENDED > > > > But I think it only has meaning if you have option KDB in effect, > > otherwise it should just reboot itself after a 15 second pause. > > Its only a kernel option? There is no flag to pass to the loader? ~% sysctl -ad | grep panic kern.stop_scheduler_on_panic: stop scheduler upon entering panic kern.sync_on_panic: Do a sync before rebooting from a panic debug.trace_on_panic: Print stack trace on kernel panic debug.debugger_on_panic: Run debugger on kernel panic debug.kdb.panic: set to panic the kernel machdep.enable_panic_key: Enable panic via keypress specified in kbdmap(5) machdep.panic_on_nmi: Panic on NMI These are also tunables which can be set in /boot/loader.conf or at the loader prompt. Ben From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 07:33:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5BEBAC0C for ; Thu, 17 Jan 2013 07:33:09 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1E79BD for ; Thu, 17 Jan 2013 07:33:08 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 2C25C450CD; Thu, 17 Jan 2013 07:33:06 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk 2C25C450CD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1358407988; bh=uV16Y5BwsA2TdKDXn8OtrzuVjnEIbrR7FaRZDsY6aOM=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=vjrZC++LUexNS9wzmwhzi2hM+TwXehce1n04QvQg3I1SJHJkxZG7hoa0xGw0V5a8X TYri0NehI+Wx3uOttoChaX7LyliCghXhGuaElYet60ii72BifBWJVQCuo1pUDom0L+ E5MAaXsGSMcoSitFv1/hSYwDQj3snHFBZbq7x1fU= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id BADA58A76; Thu, 17 Jan 2013 07:33:01 +0000 (GMT) Date: Thu, 17 Jan 2013 07:33:01 +0000 From: Ben Morrow To: kpaasial@gmail.com, freebsd-stable@freebsd.org Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 Message-ID: <20130117073301.GA39402@anubis.morrow.me.uk> References: <50F6D20A.6070306@FreeBSD.org> <20130117001116.GD29437@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk 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: Thu, 17 Jan 2013 07:33:09 -0000 Quoth Kimmo Paasiala : > > Doesn't the change to strnvis() break the ABI on FreeBSD 9.X? I > thought you could always compile a binary on an earlier version of > FreeBSD 9.X and trust it to work without recompiling on any later > minor version of the same major version line. No, it doesn't. No existing prototypes are changed, there are just a number of *nvis* functions added to complement the existing ones that didn't have length arguments. The only problem is that the port assumes that if a system has strnvis, it has a prototype matching OpenBSD's, which the new one doesn't. Ben From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 07:56:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9FF16EF for ; Thu, 17 Jan 2013 07:56:59 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC4DA87 for ; Thu, 17 Jan 2013 07:56:59 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id k13so4143166iea.8 for ; Wed, 16 Jan 2013 23:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l2g1LYgNTyLn7uMpXZKikye4ag5k9QmHDEG98l69Q/Y=; b=eDRVEUNnaNTJMYiGyjlw6874YjeJqWjiy0QhSWpYtecUj1lnhQKYSOPAJ0ka0myDm5 WclkEYCO4Et1G9jdZQUGZxun2tSIukYPrR0QmCZAPZ8Llr0UEa0FbehkoWzhmAKRW/LS bXxAZz4HgvA3L0fj1f6D77q1qitMzYdfnJdeQS4AHRj4vvZ0hq9L+Ks0PO7/oWszLIuA LVJOKg0wwAc5CTqawROincyTr+QZ9J+mRrBPJDv5md86cD/9lt8d9z9wm37/UmfA2Gpy TgC+OnsUsiOveV6UDXTHAyyVFwZyqt+lG8g6xnbBUGFLPjxO5xSlLcHH1UBTDV2MN219 Wm9g== MIME-Version: 1.0 X-Received: by 10.50.179.99 with SMTP id df3mr2955384igc.94.1358409418791; Wed, 16 Jan 2013 23:56:58 -0800 (PST) Received: by 10.64.143.138 with HTTP; Wed, 16 Jan 2013 23:56:58 -0800 (PST) In-Reply-To: <20130117073301.GA39402@anubis.morrow.me.uk> References: <50F6D20A.6070306@FreeBSD.org> <20130117001116.GD29437@lor.one-eyed-alien.net> <20130117073301.GA39402@anubis.morrow.me.uk> Date: Thu, 17 Jan 2013 09:56:58 +0200 Message-ID: Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 From: Kimmo Paasiala To: Ben Morrow 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, 17 Jan 2013 07:56:59 -0000 On Thu, Jan 17, 2013 at 9:33 AM, Ben Morrow wrote: > Quoth Kimmo Paasiala : >> >> Doesn't the change to strnvis() break the ABI on FreeBSD 9.X? I >> thought you could always compile a binary on an earlier version of >> FreeBSD 9.X and trust it to work without recompiling on any later >> minor version of the same major version line. > > No, it doesn't. No existing prototypes are changed, there are just a > number of *nvis* functions added to complement the existing ones that > didn't have length arguments. The only problem is that the port assumes > that if a system has strnvis, it has a prototype matching OpenBSD's, > which the new one doesn't. > > Ben > Aah yes, thanks for clarification. I'll submit a PR about the port then. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 08:00:19 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77B32230; Thu, 17 Jan 2013 08:00:19 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id 1F374AB1; Thu, 17 Jan 2013 08:00:19 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id E7EB1153434; Thu, 17 Jan 2013 09:00:17 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-y3zY0zZLpp; Thu, 17 Jan 2013 09:00:17 +0100 (CET) Received: from [192.168.10.120] (10G [192.168.10.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPS id 3E427153433; Thu, 17 Jan 2013 09:00:17 +0100 (CET) References: <50ACA518.4050309@digiware.nl> <50AD0AC2.5070804@FreeBSD.org> <50AD0B29.6060602@FreeBSD.org> <50AD0F00.5020600@digiware.nl> <50AD13EE.8050901@digiware.nl> <50AD17E4.50104@FreeBSD.org> <50AD189D.4040902@digiware.nl> <50AD1941.2020108@FreeBSD.org> <50ADF362.2040803@FreeBSD.org> <20121123140932.3a6deff6@mr129166> <50AF88AA.1060003@FreeBSD.org> <50AFF419.3070604@digiware.nl> <50AFF7C1.2090405@FreeBSD.org> <50AFFB9C.8050101@digiware.nl> <20121126111052.68136d00@mr129166> <50B3421B.2010606@FreeBSD.org> <20121129094137.6829eae8@mr129166> <50B7229D.4090901@digiware.nl> <50B77A6A.9050604@FreeBSD.org> <50B77C3B.6070305@digiware.nl> <50B77D70.1000803@FreeBSD.org> <871udwgbya.fsf@os.inf.tu-dresden.de> <50F06A43.801@digiware.nl> <50F7142B.7080504@FreeBSD.org> <86386CBB12394FDAB981F1C19CBC520B@multiplay.co.uk> In-Reply-To: <86386CBB12394FDAB981F1C19CBC520B@multiplay.co.uk> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <55CF24B1-025A-4E38-820D-1DD218A653D4@digiware.nl> X-Mailer: iPad Mail (9B206) From: Willem Jan Withagen Subject: Re: Some new hardware with 9.1 does not reboot easily Date: Thu, 17 Jan 2013 09:00:20 +0100 To: Steven Hartland Cc: "" , Andriy Gapon , Julian Stecklina 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, 17 Jan 2013 08:00:19 -0000 Op 17 jan. 2013 om 01:17 heeft "Steven Hartland" h= et volgende geschreven: > ----- Original Message ----- From: "Andriy Gapon" >=20 >=20 >> on 11/01/2013 21:38 Willem Jan Withagen said the following: >>> On 2013-01-07 18:06, Julian Stecklina wrote: >>>> Has this been resolved? I still see a hang on reboot/shutdown on my box= >>>> (zfs root on USB thumb drive), but I am not sure if the problem is >>>> related. >>> Could very well be be. >>> I have again the same problem as I reported before with the full and new= >>> 9.1 code. >>> But did not have time yet to build a system te test with. >>> My other 9.1 box is my ZFS only fileserver. And I do not want to fidle >>> to much with it. >=20 > Not sure if this has been suggested or ruled out as yet but if you have us= b enabled, you don't need to be using it, try the following see if it helps?= >=20 > sysctl hw.usb.no_shutdown_wait=3D1 >=20 > If it does > 1. Temporary fix is to pop that in /etc/sysctl.conf > 2. Worth investigating which USB component isn't dropping the connection=20= I do have a 500gb external western digital USB 2.0 connected. And will include your suggestion in the test. --WjW= From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 08:58:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BACDF2F for ; Thu, 17 Jan 2013 08:58:11 +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 0FE97D90 for ; Thu, 17 Jan 2013 08:58:10 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TvlIV-00013s-Rz; Thu, 17 Jan 2013 10:58:08 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: "Ronald Klop" Subject: Re: time issues and some more In-reply-to: References: Comments: In-reply-to "Ronald Klop" message dated "Wed, 16 Jan 2013 18:56:06 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jan 2013 10:58:07 +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: Thu, 17 Jan 2013 08:58:11 -0000 > On Wed, 16 Jan 2013 10:45:49 +0100, Daniel Braniss > wrote: > > > I resently upgraded a Dell PowerEdge R710, to 9.1-stable, we mainly use > > it as > > a backup to several zfs servers (doing send|receive) without major > > issues till > > the upgrade, it was running 8.2-stable. > > > > now, we see that sometime the time drifts, and today I noticed that it > > was > > hung, and once I got unto the ipmi console this is what i got: > > [SOL Session operational. Use ~? for help] > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: 12288 > > > > and things started moving again, > > > > in /var/log/messages: > > Jan 16 03:27:35 store-02 kernel: swap_pager: indefinite wait buffer: > > bufobj: > > 0, blkno: 3864, size: 12288 > > > > but the REAL time is 7hs ahead!, so time stood still ? > > and now, of course we get: > > Jan 16 03:54:19 store-02 ntpd[38163]: time correction of 25216 seconds > > exceeds > > sanity limit (1000); set clock manually to the correct UTC time. > > > > I will now reboot, and try a newer kernel and check, but any insight will > > be very helpful, > > > > thanks, > > danny > > Does BSD 9 choose another timer source than BSD 8? > Use sysctl to check these values at your system. > kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) > kern.eventtimer.timer: LAPIC > > Or this ones. I always confuse these. > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: TSC-low > under 8.3 it's kern.timecounte, so this is what I get: > sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 52515 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 925448 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1472869277 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 4125922088 kern.timecounter.tc.TSC.frequency: 2329838875 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 so I assume the choise is HPET, under 9.1: kern.eventtimer.timer: HPET so it seems to be the same. btw, this morning I see that it's behind more than 1 hour, and no signs of ntpd! the logs show: ... Jan 17 00:40:52 store-02 kernel: usb_dev_suspend_peer: Setting device remote wakeup failed Jan 17 01:05:46 store-02 ntpd[1845]: time correction of 7854 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. ... it seems to me that the 7854 seconds is exactly the time diff: date on this hosts says: Thu Jan 17 08:46:18 IST 2013 addig the 7854 sec is the current(almost) real date: Thu Jan 17 10:57:13 IST 2013 something is very fishy here. cheers, danny From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 10:03:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D95E8572 for ; Thu, 17 Jan 2013 10:03:18 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 74ED6DB for ; Thu, 17 Jan 2013 10:03:18 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TvmJR-0005Mg-S1 for freebsd-stable@freebsd.org; Thu, 17 Jan 2013 11:03:10 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TvmJS-0000A7-1W for freebsd-stable@freebsd.org; Thu, 17 Jan 2013 11:03:10 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: time issues and some more References: Date: Thu, 17 Jan 2013 11:03:10 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.12 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 92147cc26b2e14e0b1010f762ef587ae 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, 17 Jan 2013 10:03:18 -0000 On Thu, 17 Jan 2013 09:58:07 +0100, Daniel Braniss wrote: >> On Wed, 16 Jan 2013 10:45:49 +0100, Daniel Braniss >> wrote: >> >> > I resently upgraded a Dell PowerEdge R710, to 9.1-stable, we mainly >> use >> > it as >> > a backup to several zfs servers (doing send|receive) without major >> > issues till >> > the upgrade, it was running 8.2-stable. >> > >> > now, we see that sometime the time drifts, and today I noticed that it >> > was >> > hung, and once I got unto the ipmi console this is what i got: >> > [SOL Session operational. Use ~? for help] >> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: >> 12288 >> > >> > and things started moving again, >> > >> > in /var/log/messages: >> > Jan 16 03:27:35 store-02 kernel: swap_pager: indefinite wait buffer: >> > bufobj: >> > 0, blkno: 3864, size: 12288 >> > >> > but the REAL time is 7hs ahead!, so time stood still ? >> > and now, of course we get: >> > Jan 16 03:54:19 store-02 ntpd[38163]: time correction of 25216 seconds >> > exceeds >> > sanity limit (1000); set clock manually to the correct UTC time. >> > >> > I will now reboot, and try a newer kernel and check, but any insight >> will >> > be very helpful, >> > >> > thanks, >> > danny >> >> Does BSD 9 choose another timer source than BSD 8? >> Use sysctl to check these values at your system. >> kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) >> kern.eventtimer.timer: LAPIC >> >> Or this ones. I always confuse these. >> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) i8254(0) >> dummy(-1000000) >> kern.timecounter.hardware: TSC-low >> > > under 8.3 it's kern.timecounte, so this is what I get: > >> sysctl kern.timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 52515 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.ACPI-fast.counter: 925448 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.quality: 1000 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 1472869277 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 4125922088 > kern.timecounter.tc.TSC.frequency: 2329838875 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > > so I assume the choise is HPET, under 9.1: > kern.eventtimer.timer: HPET Your servers uses: > kern.timecounter.hardware: ACPI-fast Please check that value on 9.1 and 8.3. > > so it seems to be the same. > > btw, this morning I see that it's behind more than 1 hour, and no signs > of > ntpd! > > the logs show: > ... > Jan 17 00:40:52 store-02 kernel: usb_dev_suspend_peer: Setting device > remote > wakeup failed > Jan 17 01:05:46 store-02 ntpd[1845]: time correction of 7854 seconds > exceeds > sanity limit (1000); set clock manually to the correct UTC time. > ... > > it seems to me that the 7854 seconds is exactly the time diff: > date on this hosts says: > Thu Jan 17 08:46:18 IST 2013 > > > addig the 7854 sec is the current(almost) real date: > Thu Jan 17 10:57:13 IST 2013 > > something is very fishy here. Are you doing suspend/resume stuff on your machine? Or does usb_dev_suspend_peer mean suspend in another way? Ronald. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 11:32:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16F7BC26 for ; Thu, 17 Jan 2013 11:32:23 +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 953FD69E for ; Thu, 17 Jan 2013 11:32:22 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Tvnhf-00064g-8K; Thu, 17 Jan 2013 13:32:15 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: "Ronald Klop" Subject: Re: time issues and some more In-reply-to: References: Comments: In-reply-to "Ronald Klop" message dated "Thu, 17 Jan 2013 11:03:10 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jan 2013 13:32:15 +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: Thu, 17 Jan 2013 11:32:23 -0000 > On Thu, 17 Jan 2013 09:58:07 +0100, Daniel Braniss > wrote: > > >> On Wed, 16 Jan 2013 10:45:49 +0100, Daniel Braniss > >> wrote: > >> > >> > I resently upgraded a Dell PowerEdge R710, to 9.1-stable, we mainly > >> use > >> > it as > >> > a backup to several zfs servers (doing send|receive) without major > >> > issues till > >> > the upgrade, it was running 8.2-stable. > >> > > >> > now, we see that sometime the time drifts, and today I noticed that it > >> > was > >> > hung, and once I got unto the ipmi console this is what i got: > >> > [SOL Session operational. Use ~? for help] > >> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: > >> 12288 > >> > > >> > and things started moving again, > >> > > >> > in /var/log/messages: > >> > Jan 16 03:27:35 store-02 kernel: swap_pager: indefinite wait buffer: > >> > bufobj: > >> > 0, blkno: 3864, size: 12288 > >> > > >> > but the REAL time is 7hs ahead!, so time stood still ? > >> > and now, of course we get: > >> > Jan 16 03:54:19 store-02 ntpd[38163]: time correction of 25216 seconds > >> > exceeds > >> > sanity limit (1000); set clock manually to the correct UTC time. > >> > > >> > I will now reboot, and try a newer kernel and check, but any insight > >> will > >> > be very helpful, > >> > > >> > thanks, > >> > danny > >> > >> Does BSD 9 choose another timer source than BSD 8? > >> Use sysctl to check these values at your system. > >> kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) > >> kern.eventtimer.timer: LAPIC > >> > >> Or this ones. I always confuse these. > >> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) i8254(0) > >> dummy(-1000000) > >> kern.timecounter.hardware: TSC-low > >> > > > > under 8.3 it's kern.timecounte, so this is what I get: > > > >> sysctl kern.timecounter > > kern.timecounter.tick: 1 > > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) > > dummy(-1000000) > > kern.timecounter.hardware: ACPI-fast > > kern.timecounter.stepwarnings: 0 > > kern.timecounter.tc.i8254.mask: 65535 > > kern.timecounter.tc.i8254.counter: 52515 > > kern.timecounter.tc.i8254.frequency: 1193182 > > kern.timecounter.tc.i8254.quality: 0 > > kern.timecounter.tc.ACPI-fast.mask: 16777215 > > kern.timecounter.tc.ACPI-fast.counter: 925448 > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > kern.timecounter.tc.ACPI-fast.quality: 1000 > > kern.timecounter.tc.HPET.mask: 4294967295 > > kern.timecounter.tc.HPET.counter: 1472869277 > > kern.timecounter.tc.HPET.frequency: 14318180 > > kern.timecounter.tc.HPET.quality: 900 > > kern.timecounter.tc.TSC.mask: 4294967295 > > kern.timecounter.tc.TSC.counter: 4125922088 > > kern.timecounter.tc.TSC.frequency: 2329838875 > > kern.timecounter.tc.TSC.quality: -100 > > kern.timecounter.smp_tsc: 0 > > kern.timecounter.invariant_tsc: 1 > > > > so I assume the choise is HPET, under 9.1: > > kern.eventtimer.timer: HPET > > Your servers uses: > > kern.timecounter.hardware: ACPI-fast > > Please check that value on 9.1 and 8.3. > they both choose the same, ACPI-fast > > > > > so it seems to be the same. > > > > btw, this morning I see that it's behind more than 1 hour, and no signs > > of > > ntpd! > > > > the logs show: > > ... > > Jan 17 00:40:52 store-02 kernel: usb_dev_suspend_peer: Setting device > > remote > > wakeup failed > > Jan 17 01:05:46 store-02 ntpd[1845]: time correction of 7854 seconds > > exceeds > > sanity limit (1000); set clock manually to the correct UTC time. > > ... > > > > it seems to me that the 7854 seconds is exactly the time diff: > > date on this hosts says: > > Thu Jan 17 08:46:18 IST 2013 > > > > > > addig the 7854 sec is the current(almost) real date: > > Thu Jan 17 10:57:13 IST 2013 > > > > something is very fishy here. > > > Are you doing suspend/resume stuff on your machine? Or does > usb_dev_suspend_peer mean suspend in another way? not that I know, but the prev. time it complained about something else: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3864, size: 12288 Since I have other such boxes -without the problem-, my bet is on mfdi/zfs danny From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 13:07:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1EFF4B2; Thu, 17 Jan 2013 13:07:40 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id D7D10C39; Thu, 17 Jan 2013 13:07:39 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hq12so4569358wib.2 for ; Thu, 17 Jan 2013 05:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=66bvptgCDYa7PgOs9ezN2njp4PGbIi/J3SGApBZajBs=; b=esY7qoyo4OE8fAqxedaFKy833IgKzmfdgsAmnXBaEXsXbK605lhHnL7H7UZ/k7SOIy wzX7w1CNbBOTgmSEgq0b+xj5mW4k73sb5sphtyWcL8aqIacWGufwYva9MSkCwxrKr2ld LvvRIpDIL6c67ABK2drVvHjlX3RH93deuuqN6kmFyytURe4P0226fXtSaabW6ZwRGTWk lmjmBHDudZpxjxjOPXrZxi7Qj7B5N9nA7JHnodCfUzqvsVhIhVqeLb4644y8i+6gcHgl X1H3mKLdpKoSFVO2Wd6Chby1UVxKi69aJwimynKGZbQ8F6p++JIz9h5lDu7Ini68fOE6 0pLA== MIME-Version: 1.0 X-Received: by 10.180.80.170 with SMTP id s10mr15692760wix.27.1358428059041; Thu, 17 Jan 2013 05:07:39 -0800 (PST) Received: by 10.216.172.197 with HTTP; Thu, 17 Jan 2013 05:07:38 -0800 (PST) In-Reply-To: <20130117001116.GD29437@lor.one-eyed-alien.net> References: <50F6D20A.6070306@FreeBSD.org> <20130117001116.GD29437@lor.one-eyed-alien.net> Date: Thu, 17 Jan 2013 15:07:38 +0200 Message-ID: Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 From: Kimmo Paasiala To: Brooks Davis Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Dimitry Andric 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, 17 Jan 2013 13:07:40 -0000 On Thu, Jan 17, 2013 at 2:11 AM, Brooks Davis wrote: > On Wed, Jan 16, 2013 at 08:01:00PM +0200, Kimmo Paasiala wrote: >> On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric wrote: >> > On 2013-01-16 13:05, Kimmo Paasiala wrote: >> >> >> >> I just updated my stable/9 system after clang3.2 was added. My system >> >> is amd64, both world and kernel are compiled with clang3.2 and the >> >> default compiler is clang. I'm tracking the sources with GIT and the >> >> version I have corresponds to SVN revision r245451. >> >> >> >> Everything else seems to work but the pam authentication module >> >> security/pam_ssh_agent_auth segfaults immediately. >> > >> > ... >> > >> >> #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 >> >> #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7 >> >> #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7 >> >> #3 0x0000000801c0e2e7 in do_log () from >> >> /usr/local/lib/pam_ssh_agent_auth.so >> >> #4 0x0000000801c0e4ff in logit () from >> >> /usr/local/lib/pam_ssh_agent_auth.so >> > >> > ... >> > >> >> The str*vis() calls suggest that it's something in the libc maybe? >> > >> > >> > Brooks merged the new strvis implementations in r245439, so you may have >> > run into a bug with them. I don't think this is caused specifically by >> > clang, at least not without more proof. :-) >> > >> > Can you try reverting to the revision just before r245439, rebuilding >> > and reinstalling at least libc, and see if the pam_ssh_agent_auth crash >> > goes away? >> >> I'm rebuilding world now. Took me some time to figure out how to >> revert the commits in git. I'll report back once finished. > > NetBSD and OpenBSD use different signatures for strnvis(). :( > pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD > one but ours is the NetBSD one. The port will need to be patched to use > the openbsd version like it was doing or to swap the second and third > arguments when build on newer versions of FreeBSD. > > -- Brooks It turns out that security/pam_ssh_agent_auth compiles its own version of strnvis() when HAVE_STRNVIS is not defined. This in turn results in an exported dynamic strnvis symbol in the plugin binary. I guess that's what is breaking things when the plugin binary is loaded on post r245439 world. First thing that comes to my mind for a fix is renaming the local strnvis() to something else conditionally based on HAVE_STRNVIS. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 13:29:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C0312A09 for ; Thu, 17 Jan 2013 13:29:08 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 03D2EDFF for ; Thu, 17 Jan 2013 13:29:07 +0000 (UTC) Received: (qmail 23855 invoked from network); 17 Jan 2013 17:22:24 +0400 Received: from 95-27-78-36.broadband.corbina.ru (95-27-78-36.broadband.corbina.ru [95.27.78.36]) by mail.sub.ru ([88.212.205.2]) with ESMTP via TCP; 31 Dec 1969 23:59:59 -0000 Message-ID: <50F7FB12.5040602@webmail.sub.ru> Date: Thu, 17 Jan 2013 17:22:26 +0400 From: Alex Povolotsky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120817 Thunderbird/14.0 MIME-Version: 1.0 To: Mark Felder Subject: Re: Strange problem with... ZFS? Disk? Controller? References: <50D56D4B.4060709@webmail.sub.ru> <20121222032541.0ceb9f56@tech304> In-Reply-To: <20121222032541.0ceb9f56@tech304> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-hardware@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, 17 Jan 2013 13:29:08 -0000 On 12/22/12 13:25, Mark Felder wrote: > Try running diskinfo -t /dev/... > > If it says your device is really slow it's probably dying. I'd suspect it's having trouble seeking. > It was a break-in. Some dumb php script running with user privileges managed FreeBSD to hang on disk io up to stopping responding to anything besides reset. Alex From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 13:35:33 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 708FBD69; Thu, 17 Jan 2013 13:35:33 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF1DE56; Thu, 17 Jan 2013 13:35:32 +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 r0HDZWVB090566; Thu, 17 Jan 2013 06:35:32 -0700 (MST) (envelope-from ian@FreeBSD.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 r0HDZSLB006318; Thu, 17 Jan 2013 06:35:29 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Failsafe on kernel panic From: Ian Lepore To: Sami Halabi In-Reply-To: References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> Content-Type: text/plain; charset="iso-2022-jp" Date: Thu, 17 Jan 2013 06:35:28 -0700 Message-ID: <1358429728.32417.193.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@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: Thu, 17 Jan 2013 13:35:33 -0000 On Thu, 2013-01-17 at 08:38 +0200, Sami Halabi wrote: > btw: i don't see any options in my kernel config for KBD / Unatteneded , th > eonly thing that mention its > is: device ukbd > > Sami I think if you don't have any kdb options turned on, then a panic should automatically store a crashdump to swap, then reboot the machine. If that's not working, perhaps it locks up trying to store the dump? If the hardware has a watchdog timer, enabling that might be the best way to ensure a reboot on any kind of crash or hang. -- Ian > On Thu, Jan 17, 2013 at 6:45 AM, Sami Halabi wrote: > > > Its only a kernel option? There is no flag to pass to the loader? > > > > SAMI <> 17 2013 05:18, "Ian Lepore" : > > > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > >> > Thank you for your response, very helpful. > >> > one question - how do i configure auto-reboot once kernel panic occurs? > >> > > >> > Sami > >> > > >> > >> From src/sys/conf/NOTES, this may be what you're looking for... > >> > >> # > >> # Don't enter the debugger for a panic. Intended for unattended operation > >> # where you may want to enter the debugger from the console, but still > >> want > >> # the machine to recover from a panic. > >> # > >> options KDB_UNATTENDED > >> > >> But I think it only has meaning if you have option KDB in effect, > >> otherwise it should just reboot itself after a 15 second pause. > >> > >> -- Ian > >> > >> > >> > >> > >> > >> > >> > > >> > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > >> > > >> > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > >> > > > Hi everyone, > >> > > > I have a production box, in which I want to install new kernel > >> without > >> > > any > >> > > > remotd kvn. > >> > > > my problem is its 2 hours away, and if a kernel panic occurs I got a > >> > > > problem. > >> > > > I woner if I can seg failsafe script to load the old kernel in case > >> of > >> > > > psnic. > >> > > > >> > > man nextboot (if you are using UFS) > >> > > > >> > > -- > >> > > John Baldwin > >> > > > >> > > >> > > >> > > >> > >> > >> > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 13:57:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 641FE6EE; Thu, 17 Jan 2013 13:57:00 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 33240F6D; Thu, 17 Jan 2013 13:56:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=MjTYHRTY4K2TeNvGFKh/G0aL3sffha4cpGPt3Mmu8zo=; b=CiR1+XsOw1cln1xBOgzpmmJ1mU8L06A2ZZNKShGhr1aZTDctncaAEd5j51eGpTRJT7fuRciCihpVnCiZhSCZjd5WmeqJT3Qg736F+0JIkNsKyGIsblFo4yaEQoJ8MtT7; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tvpxh-0000Ls-Ch; Thu, 17 Jan 2013 07:56:57 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1358431011-86880-86877/5/2; Thu, 17 Jan 2013 13:56:51 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: Alex Povolotsky Subject: Re: Strange problem with... ZFS? Disk? Controller? References: <50D56D4B.4060709@webmail.sub.ru> <20121222032541.0ceb9f56@tech304> <50F7FB12.5040602@webmail.sub.ru> Date: Thu, 17 Jan 2013 07:56:51 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <50F7FB12.5040602@webmail.sub.ru> User-Agent: Opera Mail/12.12 (FreeBSD) Cc: freebsd-stable@freebsd.org, freebsd-hardware@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, 17 Jan 2013 13:57:00 -0000 On Thu, 17 Jan 2013 07:22:26 -0600, Alex Povolotsky wrote: > On 12/22/12 13:25, Mark Felder wrote: >> Try running diskinfo -t /dev/... >> >> If it says your device is really slow it's probably dying. I'd suspect >> it's having trouble seeking. >> > It was a break-in. Some dumb php script running with user privileges > managed FreeBSD to hang on disk io up to stopping responding to anything > besides reset. > > Alex Yikes! Make sure to run freebsd-update IDS to check the base OS's checksums and if you're using pkgng you can use "pkg check-s" to look for any tampered with files owned by packages. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 14:11:27 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 330E0CDC; Thu, 17 Jan 2013 14:11:27 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id BCED0D6; Thu, 17 Jan 2013 14:11:26 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 3821B153434; Thu, 17 Jan 2013 15:11:25 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZggGoF1jaHL; Thu, 17 Jan 2013 15:11:22 +0100 (CET) Received: from [127.0.0.1] (opteron [192.168.10.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPS id 7CBCB153433; Thu, 17 Jan 2013 15:11:22 +0100 (CET) Message-ID: <50F80688.7080800@digiware.nl> Date: Thu, 17 Jan 2013 15:11:20 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Julian Stecklina Subject: Re: Some new hardware with 9.1 does not reboot easily References: <50ACA518.4050309@digiware.nl> <50AD0AC2.5070804@FreeBSD.org> <50AD0B29.6060602@FreeBSD.org> <50AD0F00.5020600@digiware.nl> <50AD13EE.8050901@digiware.nl> <50AD17E4.50104@FreeBSD.org> <50AD189D.4040902@digiware.nl> <50AD1941.2020108@FreeBSD.org> <50ADF362.2040803@FreeBSD.org> <20121123140932.3a6deff6@mr129166> <50AF88AA.1060003@FreeBSD.org> <50AFF419.3070604@digiware.nl> <50AFF7C1.2090405@FreeBSD.org> <50AFFB9C.8050101@digiware.nl> <20121126111052.68136d00@mr129166> <50B3421B.2010606@FreeBSD.org> <20121129094137.6829eae8@mr129166> <50B7229D.4090901@digiware.nl> <50B77A6A.9050604@FreeBSD.org> <50B77C3B.6070305@digiware.nl> <50B77D70.1000803@FreeBSD.org> <871udwgbya.fsf@os.inf.tu-dresden.de> <50F06A43.801@digiware.nl> <50F7142B.7080504@FreeBSD.org> <86386CBB12394FDAB981F1C19CBC520B@multiplay.co.uk> <0bba4bca-218c-434a-a25d-a988df155207@email.android.com> In-Reply-To: <0bba4bca-218c-434a-a25d-a988df155207@email.android.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130117-0, 01/17/2013), Outbound message X-Antivirus-Status: Clean Cc: freebsd-stable@FreeBSD.org, Steven Hartland , 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: Thu, 17 Jan 2013 14:11:27 -0000 On 2013-01-17 3:08, Julian Stecklina wrote: > > > Steven Hartland wrote: > >> ----- Original Message ----- From: "Andriy Gapon" >> >> >> >>> on 11/01/2013 21:38 Willem Jan Withagen said the following: >>>> On 2013-01-07 18:06, Julian Stecklina wrote: >>>>> Has this been resolved? I still see a hang on reboot/shutdown >>>>> on my >> box >>>>> (zfs root on USB thumb drive), but I am not sure if the >>>>> problem is related. >>>> >>>> Could very well be be. >>>> >>>> I have again the same problem as I reported before with the >>>> full and >> new >>>> 9.1 code. But did not have time yet to build a system te test >>>> with. >>>> >>>> My other 9.1 box is my ZFS only fileserver. And I do not want >>>> to >> fidle >>>> to much with it. >> >> Not sure if this has been suggested or ruled out as yet but if you >> have usb enabled, you don't need to be using it, try the following >> see if it helps? >> >> sysctl hw.usb.no_shutdown_wait=1 > > With that sysctl set the box shuts down just fine. Thanks! > >> >> If it does 1. Temporary fix is to pop that in /etc/sysctl.conf 2. >> Worth investigating which USB component isn't dropping references >> correctly. > > I only have an USB thumb drive and a USB soundcard attached. I tried > it without the soundcard attached and would still not reset/shutdown, > so that does not seem to be the problem. > > I attached usbconfig list output. Hi all, This is with: FreeBSD zfs.digiware.nl 9.1-STABLE FreeBSD 9.1-STABLE #59 r245340: Sun Jan 13 06:49:37 CET 2013 I removed my WD USB disk, and it started to reboot just fine.... And as such I think it is a combination of USB storage and ZFS. So it could very well be a derivative of the previous problems where a more complex situation in storage ended up in deadlock. Thanx to Steven for putting the finger in the correct hole in the dike.... For the time being I'll just pop the sysctl into the config. --WjW From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 14:26:41 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 06F43411; Thu, 17 Jan 2013 14:26:41 +0000 (UTC) (envelope-from prvs=172911332d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 611F11FC; Thu, 17 Jan 2013 14:26:40 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001737500.msg; Thu, 17 Jan 2013 14:26:31 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Jan 2013 14:26:31 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=172911332d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <4B9E14C6DBAC4784BF070100E3601314@multiplay.co.uk> From: "Steven Hartland" To: "Willem Jan Withagen" , "Julian Stecklina" References: <50ACA518.4050309@digiware.nl> <50AD0AC2.5070804@FreeBSD.org> <50AD0B29.6060602@FreeBSD.org> <50AD0F00.5020600@digiware.nl> <50AD13EE.8050901@digiware.nl> <50AD17E4.50104@FreeBSD.org> <50AD189D.4040902@digiware.nl> <50AD1941.2020108@FreeBSD.org> <50ADF362.2040803@FreeBSD.org> <20121123140932.3a6deff6@mr129166> <50AF88AA.1060003@FreeBSD.org> <50AFF419.3070604@digiware.nl> <50AFF7C1.2090405@FreeBSD.org> <50AFFB9C.8050101@digiware.nl> <20121126111052.68136d00@mr129166> <50B3421B.2010606@FreeBSD.org> <20121129094137.6829eae8@mr129166> <50B7229D.4090901@digiware.nl> <50B77A6A.9050604@FreeBSD.org> <50B77C3B.6070305@digiware.nl> <50B77D70.1000803@FreeBSD.org> <871udwgbya.fsf@os.inf.tu-dresden.de> <50F06A43.801@digiware.nl> <50F7142B.7080504@FreeBSD.org> <86386CBB12394FDAB981F1C19CBC520B@multiplay.co.uk> <0bba4bca-218c-434a-a25d-a988df155207@email.android.com> <50F80688.7080800@digiware.nl> Subject: Re: Some new hardware with 9.1 does not reboot easily Date: Thu, 17 Jan 2013 14:26:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: 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: Thu, 17 Jan 2013 14:26:41 -0000 ----- Original Message ----- From: "Willem Jan Withagen" To: "Julian Stecklina" Cc: "Steven Hartland" ; "Andriy Gapon" ; Sent: Thursday, January 17, 2013 2:11 PM Subject: Re: Some new hardware with 9.1 does not reboot easily > On 2013-01-17 3:08, Julian Stecklina wrote: >> >> >> Steven Hartland wrote: >> >>> ----- Original Message ----- From: "Andriy Gapon" >>> >>> >>> >>>> on 11/01/2013 21:38 Willem Jan Withagen said the following: >>>>> On 2013-01-07 18:06, Julian Stecklina wrote: >>>>>> Has this been resolved? I still see a hang on reboot/shutdown >>>>>> on my >>> box >>>>>> (zfs root on USB thumb drive), but I am not sure if the >>>>>> problem is related. >>>>> >>>>> Could very well be be. >>>>> >>>>> I have again the same problem as I reported before with the >>>>> full and >>> new >>>>> 9.1 code. But did not have time yet to build a system te test >>>>> with. >>>>> >>>>> My other 9.1 box is my ZFS only fileserver. And I do not want >>>>> to >>> fidle >>>>> to much with it. >>> >>> Not sure if this has been suggested or ruled out as yet but if you >>> have usb enabled, you don't need to be using it, try the following >>> see if it helps? >>> >>> sysctl hw.usb.no_shutdown_wait=1 >> >> With that sysctl set the box shuts down just fine. Thanks! >> >>> >>> If it does 1. Temporary fix is to pop that in /etc/sysctl.conf 2. >>> Worth investigating which USB component isn't dropping references >>> correctly. >> >> I only have an USB thumb drive and a USB soundcard attached. I tried >> it without the soundcard attached and would still not reset/shutdown, >> so that does not seem to be the problem. >> >> I attached usbconfig list output. > > Hi all, > > This is with: > FreeBSD zfs.digiware.nl 9.1-STABLE FreeBSD 9.1-STABLE #59 r245340: > Sun Jan 13 06:49:37 CET 2013 > > I removed my WD USB disk, and it started to reboot just fine.... > And as such I think it is a combination of USB storage and ZFS. > > So it could very well be a derivative of the previous problems where a > more complex situation in storage ended up in deadlock. > > Thanx to Steven for putting the finger in the correct hole in the dike.... > For the time being I'll just pop the sysctl into the config. I don't "think" it will FS related, when I looked it was purely a device reference count thing. If you have a blank or unmounted device plugged in does it still fail to reboot without that sysctl? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 14:35:15 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ADF92620; Thu, 17 Jan 2013 14:35:15 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4489F285; Thu, 17 Jan 2013 14:35:15 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id A84A7153433; Thu, 17 Jan 2013 15:35:14 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-txKLOYO6bw; Thu, 17 Jan 2013 15:35:11 +0100 (CET) Received: from [127.0.0.1] (opteron [192.168.10.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPS id 62FC0153435; Thu, 17 Jan 2013 15:35:11 +0100 (CET) Message-ID: <50F80C1D.6040904@digiware.nl> Date: Thu, 17 Jan 2013 15:35:09 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Steven Hartland Subject: Re: Some new hardware with 9.1 does not reboot easily References: <50ACA518.4050309@digiware.nl> <50AD0AC2.5070804@FreeBSD.org> <50AD0B29.6060602@FreeBSD.org> <50AD0F00.5020600@digiware.nl> <50AD13EE.8050901@digiware.nl> <50AD17E4.50104@FreeBSD.org> <50AD189D.4040902@digiware.nl> <50AD1941.2020108@FreeBSD.org> <50ADF362.2040803@FreeBSD.org> <20121123140932.3a6deff6@mr129166> <50AF88AA.1060003@FreeBSD.org> <50AFF419.3070604@digiware.nl> <50AFF7C1.2090405@FreeBSD.org> <50AFFB9C.8050101@digiware.nl> <20121126111052.68136d00@mr129166> <50B3421B.2010606@FreeBSD.org> <20121129094137.6829eae8@mr129166> <50B7229D.4090901@digiware.nl> <50B77A6A.9050604@FreeBSD.org> <50B77C3B.6070305@digiware.nl> <50B77D70.1000803@FreeBSD.org> <871udwgbya.fsf@os.inf.tu-dresden.de> <50F06A43.801@digiware.nl> <50F7142B.7080504@FreeBSD.org> <86386CBB12394FDAB981F1C19CBC520B@multiplay.co.uk> <0bba4bca-218c-434a-a25d-a988df155207@email.android.com> <50F80688.7080800@digiware.nl> <4B9E14C6DBAC4784BF070100E3601314@multiplay.co.uk> In-Reply-To: <4B9E14C6DBAC4784BF070100E3601314@multiplay.co.uk> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130117-0, 01/17/2013), Outbound message X-Antivirus-Status: Clean Cc: freebsd-stable@FreeBSD.org, Andriy Gapon , Julian Stecklina 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, 17 Jan 2013 14:35:15 -0000 On 2013-01-17 15:26, Steven Hartland wrote: > > ----- Original Message ----- From: "Willem Jan Withagen" > To: "Julian Stecklina" > Cc: "Steven Hartland" ; "Andriy Gapon" > ; > Sent: Thursday, January 17, 2013 2:11 PM > Subject: Re: Some new hardware with 9.1 does not reboot easily > > >> On 2013-01-17 3:08, Julian Stecklina wrote: >>> >>> >>> Steven Hartland wrote: >>> >>>> ----- Original Message ----- From: "Andriy Gapon" >>>> >>>> >>>> >>>>> on 11/01/2013 21:38 Willem Jan Withagen said the following: >>>>>> On 2013-01-07 18:06, Julian Stecklina wrote: >>>>>>> Has this been resolved? I still see a hang on reboot/shutdown >>>>>>> on my >>>> box >>>>>>> (zfs root on USB thumb drive), but I am not sure if the >>>>>>> problem is related. >>>>>> >>>>>> Could very well be be. >>>>>> >>>>>> I have again the same problem as I reported before with the >>>>>> full and >>>> new >>>>>> 9.1 code. But did not have time yet to build a system te test >>>>>> with. >>>>>> >>>>>> My other 9.1 box is my ZFS only fileserver. And I do not want >>>>>> to >>>> fidle >>>>>> to much with it. >>>> >>>> Not sure if this has been suggested or ruled out as yet but if you >>>> have usb enabled, you don't need to be using it, try the following >>>> see if it helps? >>>> >>>> sysctl hw.usb.no_shutdown_wait=1 >>> >>> With that sysctl set the box shuts down just fine. Thanks! >>> >>>> >>>> If it does 1. Temporary fix is to pop that in /etc/sysctl.conf 2. >>>> Worth investigating which USB component isn't dropping references >>>> correctly. >>> >>> I only have an USB thumb drive and a USB soundcard attached. I tried >>> it without the soundcard attached and would still not reset/shutdown, >>> so that does not seem to be the problem. >>> >>> I attached usbconfig list output. >> >> Hi all, >> >> This is with: >> FreeBSD zfs.digiware.nl 9.1-STABLE FreeBSD 9.1-STABLE #59 r245340: >> Sun Jan 13 06:49:37 CET 2013 >> >> I removed my WD USB disk, and it started to reboot just fine.... >> And as such I think it is a combination of USB storage and ZFS. >> >> So it could very well be a derivative of the previous problems where a >> more complex situation in storage ended up in deadlock. >> >> Thanx to Steven for putting the finger in the correct hole in the >> dike.... >> For the time being I'll just pop the sysctl into the config. > > I don't "think" it will FS related, when I looked it was purely a device > reference > count thing. > > If you have a blank or unmounted device plugged in does it still fail to > reboot > without that sysctl? Interesting question.... Still havent finish building a ZFS test box. I tested USB on the fileserver, because it would give me an actual reboot in case of failure/shutdown.... --WjW From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 15:15:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2696E2EC; Thu, 17 Jan 2013 15:15:03 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id CD96F710; Thu, 17 Jan 2013 15:15:01 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r0HFF2in053699; Thu, 17 Jan 2013 09:15:02 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r0HFF2Lt053698; Thu, 17 Jan 2013 09:15:02 -0600 (CST) (envelope-from brooks) Date: Thu, 17 Jan 2013 09:15:02 -0600 From: Brooks Davis To: Kimmo Paasiala Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 Message-ID: <20130117151502.GF29437@lor.one-eyed-alien.net> References: <50F6D20A.6070306@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DO5DiztRLs659m5i" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Dimitry Andric 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, 17 Jan 2013 15:15:03 -0000 --DO5DiztRLs659m5i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2013 at 09:06:27AM +0200, Kimmo Paasiala wrote: > On Wed, Jan 16, 2013 at 8:01 PM, Kimmo Paasiala wrot= e: > > On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric wrote: > >> On 2013-01-16 13:05, Kimmo Paasiala wrote: > >>> > >>> I just updated my stable/9 system after clang3.2 was added. My system > >>> is amd64, both world and kernel are compiled with clang3.2 and the > >>> default compiler is clang. I'm tracking the sources with GIT and the > >>> version I have corresponds to SVN revision r245451. > >>> > >>> Everything else seems to work but the pam authentication module > >>> security/pam_ssh_agent_auth segfaults immediately. > >> > >> ... > >> > >>> #0 0x0000000800ef2070 in strsvis () from /lib/libc.so.7 > >>> #1 0x0000000800ef2584 in strvis () from /lib/libc.so.7 > >>> #2 0x0000000800ef25e5 in strnvis () from /lib/libc.so.7 > >>> #3 0x0000000801c0e2e7 in do_log () from > >>> /usr/local/lib/pam_ssh_agent_auth.so > >>> #4 0x0000000801c0e4ff in logit () from > >>> /usr/local/lib/pam_ssh_agent_auth.so > >> > >> ... > >> > >>> The str*vis() calls suggest that it's something in the libc maybe? > >> > >> > >> Brooks merged the new strvis implementations in r245439, so you may ha= ve > >> run into a bug with them. I don't think this is caused specifically by > >> clang, at least not without more proof. :-) > >> > >> Can you try reverting to the revision just before r245439, rebuilding > >> and reinstalling at least libc, and see if the pam_ssh_agent_auth crash > >> goes away? > > >=20 > Confirmed. Reverting world to one commit before r245439 and using the > version of the port I used before fixes the problem. >=20 > Trying to use the version I compiled with post r245439 world results > in "su: pam_start: system error" when used on pre r245439 world. >=20 > I have to repeat my question, isn't this the definition of ABI breakage? Not unless you consider adding new functions in a reserved namespace (str*) to be ABI breakage. The port should have continued to work unless it was recompiled so it should have preferred it's own version of the strnvis symbol. If it's makefiles were properly constructed it would have failed to compile due to the signature mismatch. It's unfortunate that NetBSD and OpenBSD picked different function signatures for strnvis, but it's beyond our control. -- Brooks --DO5DiztRLs659m5i Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQ+BV1XY6L6fI4GtQRAtaNAJsHQVYaNHXInS03N8GxQm0bWn8rVQCfSIhe dKJoNP/cECoGA7vD5z4B70U= =Hy/2 -----END PGP SIGNATURE----- --DO5DiztRLs659m5i-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 15:15:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D12F47F; Thu, 17 Jan 2013 15:15:28 +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 F17D972A; Thu, 17 Jan 2013 15:15:27 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:14d5:fd99:f891:7575] (unknown [IPv6:2001:7b8:3a7:0:14d5:fd99:f891:7575]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 47EC65C37; Thu, 17 Jan 2013 16:15:21 +0100 (CET) Message-ID: <50F81588.5020106@FreeBSD.org> Date: Thu, 17 Jan 2013 16:15:20 +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: Kimmo Paasiala Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 References: <50F6D20A.6070306@FreeBSD.org> <20130117001116.GD29437@lor.one-eyed-alien.net> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070106040403010701060104" Cc: Brooks Davis , 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, 17 Jan 2013 15:15:28 -0000 This is a multi-part message in MIME format. --------------070106040403010701060104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2013-01-17 14:07, Kimmo Paasiala wrote: > On Thu, Jan 17, 2013 at 2:11 AM, Brooks Davis wrote: ... >> NetBSD and OpenBSD use different signatures for strnvis(). :( >> pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD >> one but ours is the NetBSD one. The port will need to be patched to use >> the openbsd version like it was doing or to swap the second and third >> arguments when build on newer versions of FreeBSD. > It turns out that security/pam_ssh_agent_auth compiles its own version > of strnvis() when HAVE_STRNVIS is not defined. This in turn results in > an exported dynamic strnvis symbol in the plugin binary. I guess > that's what is breaking things when the plugin binary is loaded on > post r245439 world. > > First thing that comes to my mind for a fix is renaming the local > strnvis() to something else conditionally based on HAVE_STRNVIS. Please try the following patch, which tells configure that HAVE_STRNVIS is always false. I think this is the easiest way, unless we really want the port to use our own strnvis. --------------070106040403010701060104 Content-Type: text/x-diff; name="security__pam_ssh_agent_auth-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="security__pam_ssh_agent_auth-1.diff" Index: security/pam_ssh_agent_auth/Makefile =================================================================== --- security/pam_ssh_agent_auth/Makefile (revision 310549) +++ security/pam_ssh_agent_auth/Makefile (working copy) @@ -16,6 +16,7 @@ COMMENT= PAM module which permits authentication v USE_BZIP2= yes GNU_CONFIGURE= yes +CONFIGURE_ENV= ac_cv_func_strnvis="no" CONFIGURE_ARGS= --libexecdir=${LOCALBASE}/lib USE_PERL5= yes --------------070106040403010701060104-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 15:35:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7BB76DB1; Thu, 17 Jan 2013 15:35:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 371C78AB; Thu, 17 Jan 2013 15:35:31 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r0HFZUGi068466; Thu, 17 Jan 2013 10:35:30 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <50F81A3A.7080007@sentex.net> Date: Thu, 17 Jan 2013 10:35:22 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 References: <50F6D20A.6070306@FreeBSD.org> <20130117001116.GD29437@lor.one-eyed-alien.net> <50F81588.5020106@FreeBSD.org> In-Reply-To: <50F81588.5020106@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Kimmo Paasiala , Brooks Davis , 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, 17 Jan 2013 15:35:31 -0000 On 1/17/2013 10:15 AM, Dimitry Andric wrote: > CONFIGURE_ENV= ac_cv_func_strnvis="no" Still segfaults for me. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 18:41:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 28CB46DA; Thu, 17 Jan 2013 18:41:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0617B949; Thu, 17 Jan 2013 18:41:00 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 52165B96B; Thu, 17 Jan 2013 13:40:59 -0500 (EST) From: John Baldwin To: Sami Halabi Subject: Re: Failsafe on kernel panic Date: Thu, 17 Jan 2013 13:39:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301161513.27016.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301171339.15841.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 Jan 2013 13:40:59 -0500 (EST) Cc: freebsd-hackers@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: Thu, 17 Jan 2013 18:41:00 -0000 On Wednesday, January 16, 2013 4:27:53 pm Sami Halabi wrote: > Thank you for your response, very helpful. > one question - how do i configure auto-reboot once kernel panic occurs? Unless you've added DDB and KDB to your kernel it will reboot by default on a panic. Stable kernel configs also include the unattended option so that even with the debugger present they reboot by default on a panic. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 17 21:35:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6BEB2ED1; Thu, 17 Jan 2013 21:35:56 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 8A12C228; Thu, 17 Jan 2013 21:35:55 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id o1so2616312wic.6 for ; Thu, 17 Jan 2013 13:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FwOAsgqSsqjYCBq8hT6OSG/UY6Q4aGH3C5UNr2WgBGU=; b=xIqZy6Z30s306mrFlAXHfAQzDHZCz4miRsOf7uNDy4d66jke0oHFzRtYc9kh9pV8tJ sOTLvq1gmIkQC4EomKNE94sbfS6Tl2YCheRvhpB9R81NLyWFfnPE+5uBKJBE03tlaxNO z4NPG6mSPUZ64bBNh9xa/2i9Zi9l56nRNOan5P8Wnf+pzuRjv10okZ9hTlMbAgC0SMjy hF9aohKaGLB0Esa2spDssrtHWmOUa45q9P+X0cNYvlrrSaavqm0FHXV1UMzWsDCpEVDq vxREgFfJ4RdfiGFKCm0tzESRV/wvXFmwZR47IDgP3rrxs049hrnNRurlxao6zQor1Exx HK/Q== MIME-Version: 1.0 X-Received: by 10.194.23.37 with SMTP id j5mr10766612wjf.28.1358458548774; Thu, 17 Jan 2013 13:35:48 -0800 (PST) Received: by 10.216.172.197 with HTTP; Thu, 17 Jan 2013 13:35:48 -0800 (PST) In-Reply-To: <50F81588.5020106@FreeBSD.org> References: <50F6D20A.6070306@FreeBSD.org> <20130117001116.GD29437@lor.one-eyed-alien.net> <50F81588.5020106@FreeBSD.org> Date: Thu, 17 Jan 2013 23:35:48 +0200 Message-ID: Subject: Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9 From: Kimmo Paasiala To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: Brooks Davis , 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, 17 Jan 2013 21:35:56 -0000 On Thu, Jan 17, 2013 at 5:15 PM, Dimitry Andric wrote: > On 2013-01-17 14:07, Kimmo Paasiala wrote: >> >> On Thu, Jan 17, 2013 at 2:11 AM, Brooks Davis wrote: > > ... >>> >>> NetBSD and OpenBSD use different signatures for strnvis(). :( >>> pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD >>> one but ours is the NetBSD one. The port will need to be patched to use >>> the openbsd version like it was doing or to swap the second and third >>> arguments when build on newer versions of FreeBSD. >> >> It turns out that security/pam_ssh_agent_auth compiles its own version >> >> of strnvis() when HAVE_STRNVIS is not defined. This in turn results in >> an exported dynamic strnvis symbol in the plugin binary. I guess >> that's what is breaking things when the plugin binary is loaded on >> post r245439 world. >> >> First thing that comes to my mind for a fix is renaming the local >> strnvis() to something else conditionally based on HAVE_STRNVIS. > > > Please try the following patch, which tells configure that HAVE_STRNVIS > is always false. I think this is the easiest way, unless we really want > the port to use our own strnvis. This will still leave the exported symbol in the plugin binary with the name strnvis. What would be needed is renaming of the function to something else, like pam_ssh_agent_auth_strnvis(), maybe using a macro #define strnvis pam_ssh_agent_auth_strnvis somewhere. I can try my hand on coming up with a fix but its going to take some time, the source code of the plugin and not to mention the configure script look quite hairy. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 00:43:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 978B85FF for ; Fri, 18 Jan 2013 00:43:13 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 6409EFBD for ; Fri, 18 Jan 2013 00:43:12 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id A9B81450CE; Fri, 18 Jan 2013 00:43:11 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk A9B81450CE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1358469792; bh=ol6ynr0zo+XzTsu9GE6stiU6dUOiwsNMpFh2llh95Wg=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=zMt8BfRt/bB7zkj0KHCLHE1sjxasOrFGZg+J2ZhL4Q2rSwcvHxL1xSjhd4jwCOsd4 FP7E3G7Bf54hOb8hd65cMHw12FkPioeoZALmci/VUqXZYp4ZXVw7nUf9cgcAUuxG1S Wh7oSq4A1YyoGCldAjydhSyICDdECjIClunKh5Vw= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id A58668BFD; Fri, 18 Jan 2013 00:43:06 +0000 (GMT) Date: Fri, 18 Jan 2013 00:43:06 +0000 From: Ben Morrow To: feld@feld.me, freebsd-stable@freebsd.org Subject: Re: freebsd-update IDS Message-ID: <20130118004306.GA48310@anubis.morrow.me.uk> References: <50D56D4B.4060709@webmail.sub.ru> <20121222032541.0ceb9f56@tech304> <50F7FB12.5040602@webmail.sub.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: gmane.os.freebsd.devel.hardware,gmane.os.freebsd.stable Organization: morrow.me.uk 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: Fri, 18 Jan 2013 00:43:13 -0000 Quoth Mark Felder : > On Thu, 17 Jan 2013 07:22:26 -0600, Alex Povolotsky > wrote: > > > It was a break-in. Some dumb php script running with user privileges > > managed FreeBSD to hang on disk io up to stopping responding to anything > > besides reset. > > Yikes! Make sure to run freebsd-update IDS to check the base OS's > checksums and if you're using pkgng you can use "pkg check-s" to look for > any tampered with files owned by packages. Make sure you read the caveats in the freebsd-update manpage before trusting the IDS result. At the very least you need to delete /var/db/freebsd-update, /etc/freebsd-update.conf and /usr/sbin/freebsd-update itself and replace them with known-good copies. Ideally you should run the tests from an entirely separate known-good instance of the OS, though in practice it's probably easier to just replace the OS and packages from known-good sources and then set about recovering and verifying the data. cf. the story about patching cc to patch cc to patch login... Ben From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 08:20:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD51175E for ; Fri, 18 Jan 2013 08:20:45 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9D93C8 for ; Fri, 18 Jan 2013 08:20:44 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.5/8.14.5) with ESMTP id r0I8KfHt004214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Jan 2013 09:20:41 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.5/8.14.5/Submit) with ESMTP id r0I8KfjW004211 for ; Fri, 18 Jan 2013 09:20:41 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 18 Jan 2013 09:20:41 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable Subject: Unable to upgrade ZFS pool to feature flags, SPA version 5000, on stable/9 @ r243825 Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-588138518-1358497241=:41917" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no 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, 18 Jan 2013 08:20:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-588138518-1358497241=:41917 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I installed FreeBSD/amd64 9.1-RELEASE yesterday. I chose to do a manual installation due to the use of ZFS. I checked out stable/9 and recompiled both world and GENERIC kernel. Said kernel and world was installed without any problems. System is still up & running, with uname -a revealing r243825. I then decided to upgrade the root pool to feature flags, SPA version 5000, and was not so lucky. # zpool upgrade -a This system supports ZFS pool feature flags. cannot upgrade 'zroot': invalid argument for this pool operation Even the command: zpool upgrade zroot gives the same diagnostic as above. This isn't a critical system at all, but I guess everyone else will run into this snag when attempting to upgrade their ZFS pools. Any clues? -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-588138518-1358497241=:41917-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 09:26:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D2A6477 for ; Fri, 18 Jan 2013 09:26:35 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id 9D716908 for ; Fri, 18 Jan 2013 09:26:34 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id w5so1814900bku.25 for ; Fri, 18 Jan 2013 01:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=jTZ73A6ioorToZkptoCAX3SCUJOcgahZJjBQfrJEgqs=; b=QmZmktFjFkLOnLTfF+pzQOKNFqfGEiO48ydNaYsJwFLAohXWPqRcU9yMqClyCkBQdt 95ZzpqiGsdl2M9E0iH923herAoTF1Jbhq5Vr+C61CDaODz0wxVX5B/Fq6FbJ8xpTTfyl QDoRLIh/7gfvTrgDM7upouamGOKEPZJzTrNMBaUXlzQIlbdpHJw1rvSrYsUhLh6czVmz P4GeLb+MuyOZD63YrJk20s4wMkgYZB6mmBRBY7xji9WFr+0dpSFIave7G/OclHS6acsI L7z50ZL7tMktLQ9U4RyVJO2MUdBrmM+jp2FC5WhOW3vkDbavWcMGjQGKkCWqJRdFyzRB pQjQ== MIME-Version: 1.0 X-Received: by 10.204.9.22 with SMTP id j22mr2278581bkj.114.1358501193163; Fri, 18 Jan 2013 01:26:33 -0800 (PST) Received: by 10.204.70.139 with HTTP; Fri, 18 Jan 2013 01:26:33 -0800 (PST) Date: Fri, 18 Jan 2013 11:26:33 +0200 Message-ID: Subject: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: ml-freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 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, 18 Jan 2013 09:26:35 -0000 Hello, Usually I ask questions on the mailing lists when things are bad and can't find much info about the problem myself. This is one of these cases now :) Recently (started something like a week or two ago) my system which was running months without any issues spontaneously rebooted. Nothing in the logs about the reboot. Then a few days ago it rebooted by itself a few more times, sometimes a 3-4 times a day without a clear reason in the logs of why this happened. I'm monitoring the CPU temp, load, network traffic and other metrics in the monitoring system, but there's nothing strange there - no load, no high temp, no high traffic or anything that could explain why this is happening. The machine is connected to a UPS, so I thought this could be causing this, but I've tested the UPS and battery and they are all fine. Here's what last(1) says about today's reboot: --- boot time Fri Jan 18 00:29 --- It's like the system has been rebooted normally, but that isn't the case. Sometimes it's logged as "crash". I've enabled crash dumps, but still nothing in /var/crash after the failure. The only error I'm able to find in /var/log/messages during boot-time is this: --- Jan 18 11:03:19 tsunami kernel: acpi0: <_ASUS_ Notebook> on motherboard Jan 18 11:03:19 tsunami kernel: ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110527/psargs-392) Jan 18 11:03:19 tsunami kernel: ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110527/nsinit-380) --- Not sure if this is the root cause for this, cause I've seen this error before and at that time there were no reboots happening (months ago). Also I find it strange that it says Notebook above, as this is a desktop machine... And currently I'm out of ideas. Could you guys give any advice or hints what else I could check and sort this out? Thanks and regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 09:41:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC9F1897 for ; Fri, 18 Jan 2013 09:41:12 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) by mx1.freebsd.org (Postfix) with ESMTP id 241839E2 for ; Fri, 18 Jan 2013 09:41:11 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.5/8.14.5) with ESMTP id r0I9f77C005636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Jan 2013 10:41:07 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.5/8.14.5/Submit) with ESMTP id r0I9f7aQ005633 for ; Fri, 18 Jan 2013 10:41:07 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 18 Jan 2013 10:41:07 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable Subject: Re: Unable to upgrade ZFS pool to feature flags, SPA version 5000, on stable/9 @ r243825 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="2055831798-588138518-1358497241=:41917" Content-ID: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no 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, 18 Jan 2013 09:41:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-588138518-1358497241=:41917 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 18 Jan 2013 09:20+0100, Trond Endrestøl wrote: > I then decided to upgrade the root pool to feature flags, SPA version > 5000, and was not so lucky. > > # zpool upgrade -a > This system supports ZFS pool feature flags. > > cannot upgrade 'zroot': invalid argument for this pool operation Pilot error. For some reason I was still running the 9.1-RELEASE kernel. Now the system happily runs 9.1-STABLE @ r245552. Sorry for the noise. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-588138518-1358497241=:41917-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 11:58:23 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EE5B02C5 for ; Fri, 18 Jan 2013 11:58: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 4650D187 for ; Fri, 18 Jan 2013 11:58:23 +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 NAA20863; Fri, 18 Jan 2013 13:58:13 +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 1TwAaK-0001aD-IH; Fri, 18 Jan 2013 13:58:12 +0200 Message-ID: <50F938D2.80304@FreeBSD.org> Date: Fri, 18 Jan 2013 13:58:10 +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: Po-Li Soong Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1 References: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66DDB6@reactor.sldomain.com> <20130109234924.GM2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66E4F3@reactor.sldomain.com> In-Reply-To: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66E4F3@reactor.sldomain.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , "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, 18 Jan 2013 11:58:24 -0000 on 11/01/2013 17:09 Po-Li Soong said the following: > (kgdb) p/x *(struct vm_object *)0xffffffff81281580 [snip] > > (kgdb) p/x *(struct vm_page *)0xfffffe00cd733ab0 > $2 = {pageq = {tqe_next = 0x0, tqe_prev = 0xfffffe00c7e7d678}, listq = { > tqe_next = 0xfffffe00cd733b28, tqe_prev = 0xfffffe00cd7331d8}, > left = 0xfffffe00c9b31c38, right = 0xfffffe00cd735c70, > object = 0xfffffffb81281580 So, the correct object pointer is 0xffffffff81281580, but vm_page has object = 0xfffffffb81281580. 0xffffffff81281580 0xfffffffb81281580 One bit flip (0x400000000). Either there is some HW issue or we've got some code that arbitrarily flips bits in vm_page_array (and perhaps beyond it). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 11:59:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6FC13C7 for ; Fri, 18 Jan 2013 11:59:26 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp.insight.synacor.com [208.47.185.22]) by mx1.freebsd.org (Postfix) with ESMTP id 7953219F for ; Fri, 18 Jan 2013 11:59:25 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=fvJelSEf c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=6nzyuCKIu1sA:10 a=DvSzqBOGy98A:10 a=pedpZTtsAAAA:8 a=LmUnQtmFcx0A:10 a=haP97yNzP-jsKMrrYjYA:9 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=mueller6724@bellsouth.net; sender-id=neutral 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:54276] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id A3/0B-10746-71939F05; Fri, 18 Jan 2013 06:59:19 -0500 Date: Fri, 18 Jan 2013 06:59:19 -0500 Message-ID: From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 Cc: Marin Atanasov Nikolov 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, 18 Jan 2013 11:59:26 -0000 > Hello, > Usually I ask questions on the mailing lists when things are bad and can't > find much info about the problem myself. This is one of these cases now :) > Recently (started something like a week or two ago) my system which was > running months without any issues spontaneously rebooted. Nothing in the > logs about the reboot. > Then a few days ago it rebooted by itself a few more times, sometimes a 3-4 > times a day without a clear reason in the logs of why this happened. > I'm monitoring the CPU temp, load, network traffic and other metrics in the > monitoring system, but there's nothing strange there - no load, no high > temp, no high traffic or anything that could explain why this is happening. > The machine is connected to a UPS, so I thought this could be causing this, > but I've tested the UPS and battery and they are all fine. > Here's what last(1) says about today's reboot: > --- > boot time Fri Jan 18 00:29 > --- > It's like the system has been rebooted normally, but that isn't the case. > Sometimes it's logged as "crash". I've enabled crash dumps, but still > nothing in /var/crash after the failure. > The only error I'm able to find in /var/log/messages during boot-time is > this: > --- > Jan 18 11:03:19 tsunami kernel: acpi0: <_ASUS_ Notebook> on motherboard > Jan 18 11:03:19 tsunami kernel: ACPI Error: [RAMB] Namespace lookup > failure, AE_NOT_FOUND (20110527/psargs-392) > Jan 18 11:03:19 tsunami kernel: ACPI Exception: AE_NOT_FOUND, Could not > execute arguments for [RAMW] (Region) (20110527/nsinit-380) > --- > Not sure if this is the root cause for this, cause I've seen this error > before and at that time there were no reboots happening (months ago). Also > I find it strange that it says Notebook above, as this is a desktop > machine... > And currently I'm out of ideas. Could you guys give any advice or hints > what else I could check and sort this out? > Thanks and regards, > Marin > -- > Marin Atanasov Nikolov I had something like that with FreeBSD 9.0-RELEASE amd64 on a Sandy Bridge system, Intel i7. It started within two days after building and installing FreeBSD 9.0-RELEASE. My remedy, without consulting the emailing lists, was to switch to the STABLE branch. New computer hardware, needing the updates before the next release, was part of the reason for switching to STABLE. Now is post-9.1-RELEASE. Are you still on 9.0-RELEASE? Tom From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 12:03:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DAABC778 for ; Fri, 18 Jan 2013 12:03:29 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA8F239 for ; Fri, 18 Jan 2013 12:03:29 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so1957746bkc.27 for ; Fri, 18 Jan 2013 04:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V784y7syuUjaVDe5h4f7OZ/PsKA7tXJ5Jeq7FEgSfE8=; b=lG/q5fbz6WCwF5IYiTuXAhnyRp/zHm79umEK9ZczN7ltL2tEN6VZFCGL2dVm/HL7ip CnjO38YXDNM29A9gLhIU2CVKDgPBjbsteavib08jTAsnwnZ+20unHVVn2VO+rAvUaSs0 IgfS6RyKrIxaruasR0q24RcGmVvtmUhbKHJYxKf6EJbQVMLknv1dnUEcm8UB5qULFBrn J9z6nDO2JH5Yv5GA94/3IvTbH9JHZeSsKKv9oXyiSUqE7URjayooIWZzmnucpBep3fzv AG44RLhm14ukoSA6W0gs+XWJULzIta4QxAD/X1VYs48AtUXKk03nUW7j8Bgfry3BnBC8 6duA== MIME-Version: 1.0 X-Received: by 10.204.9.22 with SMTP id j22mr2413911bkj.114.1358510603216; Fri, 18 Jan 2013 04:03:23 -0800 (PST) Received: by 10.204.70.139 with HTTP; Fri, 18 Jan 2013 04:03:23 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Jan 2013 14:03:23 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: Thomas Mueller Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ml-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: Fri, 18 Jan 2013 12:03:29 -0000 Hi Thomas, Yes, I'm still running on 9.0-RELEASE. The strange thing here is that it was running fine for a couple of months without evening having a single reboot and a few weeks ago it all started. I am also planning to update to 9.1, probably I will do it in the next days. Hopefully the update will fix this. Thanks for the feedback. Regards, Marin On Fri, Jan 18, 2013 at 1:59 PM, Thomas Mueller wrote: > > Hello, > > > Usually I ask questions on the mailing lists when things are bad and > can't > > find much info about the problem myself. This is one of these cases now > :) > > > Recently (started something like a week or two ago) my system which was > > running months without any issues spontaneously rebooted. Nothing in the > > logs about the reboot. > > > Then a few days ago it rebooted by itself a few more times, sometimes a > 3-4 > > times a day without a clear reason in the logs of why this happened. > > > I'm monitoring the CPU temp, load, network traffic and other metrics in > the > > monitoring system, but there's nothing strange there - no load, no high > > temp, no high traffic or anything that could explain why this is > happening. > > > The machine is connected to a UPS, so I thought this could be causing > this, > > but I've tested the UPS and battery and they are all fine. > > > Here's what last(1) says about today's reboot: > > > --- > > boot time Fri Jan 18 00:29 > > --- > > > It's like the system has been rebooted normally, but that isn't the case. > > Sometimes it's logged as "crash". I've enabled crash dumps, but still > > nothing in /var/crash after the failure. > > > The only error I'm able to find in /var/log/messages during boot-time is > > this: > > > --- > > Jan 18 11:03:19 tsunami kernel: acpi0: <_ASUS_ Notebook> on motherboard > > Jan 18 11:03:19 tsunami kernel: ACPI Error: [RAMB] Namespace lookup > > failure, AE_NOT_FOUND (20110527/psargs-392) > > Jan 18 11:03:19 tsunami kernel: ACPI Exception: AE_NOT_FOUND, Could not > > execute arguments for [RAMW] (Region) (20110527/nsinit-380) > > --- > > > Not sure if this is the root cause for this, cause I've seen this error > > before and at that time there were no reboots happening (months ago). > Also > > I find it strange that it says Notebook above, as this is a desktop > > machine... > > > And currently I'm out of ideas. Could you guys give any advice or hints > > what else I could check and sort this out? > > > Thanks and regards, > > Marin > > > -- > > Marin Atanasov Nikolov > > I had something like that with FreeBSD 9.0-RELEASE amd64 on a Sandy Bridge > system, Intel i7. > > It started within two days after building and installing FreeBSD > 9.0-RELEASE. > > My remedy, without consulting the emailing lists, was to switch to the > STABLE branch. > > New computer hardware, needing the updates before the next release, was > part of the reason for switching to STABLE. > > Now is post-9.1-RELEASE. Are you still on 9.0-RELEASE? > > Tom > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 13:33:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DEA86236 for ; Fri, 18 Jan 2013 13:33:23 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 7A30B85D for ; Fri, 18 Jan 2013 13:33:23 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TwC4I-0007Av-MC for freebsd-stable@freebsd.org; Fri, 18 Jan 2013 14:33:15 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TwC4I-0006Db-S6 for freebsd-stable@freebsd.org; Fri, 18 Jan 2013 14:33:14 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 References: Date: Fri, 18 Jan 2013 14:33:13 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.12 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: d58e29c6f4e42f76447094ef3ccb23d2 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, 18 Jan 2013 13:33:23 -0000 On Fri, 18 Jan 2013 10:26:33 +0100, Marin Atanasov Nikolov wrote: > Hello, > > Usually I ask questions on the mailing lists when things are bad and > can't > find much info about the problem myself. This is one of these cases now > :) > > Recently (started something like a week or two ago) my system which was > running months without any issues spontaneously rebooted. Nothing in the > logs about the reboot. > > Then a few days ago it rebooted by itself a few more times, sometimes a > 3-4 > times a day without a clear reason in the logs of why this happened. > > I'm monitoring the CPU temp, load, network traffic and other metrics in > the > monitoring system, but there's nothing strange there - no load, no high > temp, no high traffic or anything that could explain why this is > happening. > > The machine is connected to a UPS, so I thought this could be causing > this, > but I've tested the UPS and battery and they are all fine. > > Here's what last(1) says about today's reboot: > > --- > boot time Fri Jan 18 00:29 > --- > > It's like the system has been rebooted normally, but that isn't the case. > Sometimes it's logged as "crash". I've enabled crash dumps, but still > nothing in /var/crash after the failure. > > The only error I'm able to find in /var/log/messages during boot-time is > this: > > --- > Jan 18 11:03:19 tsunami kernel: acpi0: <_ASUS_ Notebook> on motherboard > Jan 18 11:03:19 tsunami kernel: ACPI Error: [RAMB] Namespace lookup > failure, AE_NOT_FOUND (20110527/psargs-392) > Jan 18 11:03:19 tsunami kernel: ACPI Exception: AE_NOT_FOUND, Could not > execute arguments for [RAMW] (Region) (20110527/nsinit-380) > --- > > Not sure if this is the root cause for this, cause I've seen this error > before and at that time there were no reboots happening (months ago). > Also > I find it strange that it says Notebook above, as this is a desktop > machine... > > And currently I'm out of ideas. Could you guys give any advice or hints > what else I could check and sort this out? > > Thanks and regards, > Marin > Memory chips gone bad? Power (or other) cables gone loose? Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 14:16:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 174C7A08 for ; Fri, 18 Jan 2013 14:16:33 +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 CB2CBA30 for ; Fri, 18 Jan 2013 14:16:32 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TwCkO-00020H-PH for freebsd-stable@freebsd.org; Fri, 18 Jan 2013 15:16:44 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Jan 2013 15:16:44 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Jan 2013 15:16:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Subject: Adding process title to SIGSEGV messages? Date: Fri, 18 Jan 2013 15:16:16 +0100 Lines: 32 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig228D418DBF5D0C0494D64EFF" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 X-Enigmail-Version: 1.4.3 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, 18 Jan 2013 14:16:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig228D418DBF5D0C0494D64EFF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Is there a way to add a process title to SIGSEGV messages which are usually collected in /var/log/messages? Jan 18 15:08:06 www kernel: pid 95174 (process-name), uid 80: exited on signal 11 I'd like to inspect the process' titles alongside process-name. --------------enig228D418DBF5D0C0494D64EFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD5WTEACgkQ/QjVBj3/HSySaQCfUR9NX5xSbKXeDrtFRMp+y3Xu jtUAniB9XZCMlOVFF9oMi+ZM+r9uwpkV =jg+h -----END PGP SIGNATURE----- --------------enig228D418DBF5D0C0494D64EFF-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 15:04:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F648D7C for ; Fri, 18 Jan 2013 15:04:27 +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 1336FE52 for ; Fri, 18 Jan 2013 15:04:26 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0IF4Q85096729; Fri, 18 Jan 2013 08:04:26 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0IF4QmN096726; Fri, 18 Jan 2013 08:04:26 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 18 Jan 2013 08:04:26 -0700 (MST) From: Warren Block To: Ronald Klop Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 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]); Fri, 18 Jan 2013 08:04:26 -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: Fri, 18 Jan 2013 15:04:27 -0000 On Fri, 18 Jan 2013, Ronald Klop wrote: > Memory chips gone bad? Power (or other) cables gone loose? Memory failures will cause intermittent and mysterious things. Easy to test, too, just run memtest86 on it for a while. Do that before rebuilding. If memory is failing, corrupted data could be written to disk. I had a Crucial DIMM fail spontaneously a couple of weeks ago. Working one minute, totally failed the next. The machine rebooted, for no visible reason. After it came back up, compiles failed, always with different errors and in different places. Power supplies also fail, as do motherboards. These are both harder to swap out than memory, so test the memory first. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 16:48:23 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 27C4CA8E for ; Fri, 18 Jan 2013 16:48:23 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2478673B for ; Fri, 18 Jan 2013 16:48:15 +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 r0IGm8pe010326 for ; Fri, 18 Jan 2013 09:48:09 -0700 (MST) (envelope-from ian@FreeBSD.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 r0IGm5pt007879; Fri, 18 Jan 2013 09:48:05 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Ian Lepore To: Warren Block In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jan 2013 09:48:05 -0700 Message-ID: <1358527685.32417.237.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, Ronald Klop 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, 18 Jan 2013 16:48:23 -0000 On Fri, 2013-01-18 at 08:04 -0700, Warren Block wrote: > On Fri, 18 Jan 2013, Ronald Klop wrote: > > > Memory chips gone bad? Power (or other) cables gone loose? > > Memory failures will cause intermittent and mysterious things. Easy to > test, too, just run memtest86 on it for a while. Do that before > rebuilding. If memory is failing, corrupted data could be written to > disk. > > I had a Crucial DIMM fail spontaneously a couple of weeks ago. Working > one minute, totally failed the next. The machine rebooted, for no > visible reason. After it came back up, compiles failed, always with > different errors and in different places. > > Power supplies also fail, as do motherboards. These are both harder to > swap out than memory, so test the memory first. I tend to agree, a machine that starts rebooting spontaneously when nothing significant changed and it used to be stable is usually a sign of a failing power supply or memory. But I disagree about memtest86. It's probably not completely without value, but to me its value is only negative: if it tells you memory is bad, it is. If it tells you it's good, you know nothing. Over the years I've had 5 dimms fail. memtest86 found the error in one of them, but said all the others were fine in continuous 48-hour tests. I even tried running the tests on multiple systems. The thing that always reliably finds bad memory for me is /usr/ports/math/mprime run in test/benchmark mode. It often takes 24 or more hours of runtime, but it will find your bad memory. -- Ian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 17:35:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BF421E9 for ; Fri, 18 Jan 2013 17:35:16 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1C166B08 for ; Fri, 18 Jan 2013 17:35:15 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan01.get.basefarm.net ([10.5.16.4]) by get-mta-out03.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MGU00JRI0UK5Y90@get-mta-out03.get.basefarm.net> for freebsd-stable@freebsd.org; Fri, 18 Jan 2013 18:35:08 +0100 (MET) Received: from get-mta-scan01.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CA5FA179BC09_F987CCB for ; Fri, 18 Jan 2013 17:35:08 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan01.get.basefarm.net (Sophos Email Appliance) with ESMTPSA id A9BC617AC278_F987CCF for ; Fri, 18 Jan 2013 17:35:08 +0000 (GMT) Date: Fri, 18 Jan 2013 18:35:08 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 Message-id: <20130118183508.53fe965349b97bc1afa5303c@getmail.no> In-reply-to: References: X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) 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, 18 Jan 2013 17:35:16 -0000 On Fri, 18 Jan 2013 11:26:33 +0200 Marin Atanasov Nikolov wrote: > The only error I'm able to find in /var/log/messages during boot-time is > this: > > --- > Jan 18 11:03:19 tsunami kernel: acpi0: <_ASUS_ Notebook> on motherboard > Jan 18 11:03:19 tsunami kernel: ACPI Error: [RAMB] Namespace lookup > failure, AE_NOT_FOUND (20110527/psargs-392) > Jan 18 11:03:19 tsunami kernel: ACPI Exception: AE_NOT_FOUND, Could not > execute arguments for [RAMW] (Region) (20110527/nsinit-380) > --- > > Not sure if this is the root cause for this, cause I've seen this error > before and at that time there were no reboots happening (months ago). Also > I find it strange that it says Notebook above, as this is a desktop > machine... FWIW, the part above is a red herring / false alarm; it is caused by a bad / incorrect implementation of acpi on your machine. Blame those who wrote the bios ... -- Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 18:37:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A7329803; Fri, 18 Jan 2013 18:37:02 +0000 (UTC) (envelope-from dnaeon@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 702F1F2A; Fri, 18 Jan 2013 18:37:02 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id k11so886081iea.5 for ; Fri, 18 Jan 2013 10:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uZPYuDT1qMrS6BD65GoA9GtaHzacSWyL8iQAjO6FSwI=; b=II/jco/rxTXSdpf1JjlAwEnFcN3yl08MpkpH86t0++2rz/mHrmPA0AU19WNZwwB7Wj AXgIMBnExIKmjiajvzsOwpeUcBnklDbDyJ9SaTwCNabYrtrbulWth1VoNZpHjqqJqM6c iKO5LkXoXkS6AmN257QDlH6SdcpHeUhyMvZ4mUGR5vjmxAgV2EsE3MGAWm/Ttkt4QPRn fhmSC6zDVyJI3qP6oL2XBlr29His9uICJM3zZBmuzmsp1abjjIZVu6YWFRKyd/BC8//p ZOoG9+FZGMs6BzWGd8Hq4s/s2pO6cVomrD1YSe3rrF1et7ZtOOALpZ/3xyz0eYCQiMc+ 1J/w== MIME-Version: 1.0 X-Received: by 10.43.134.65 with SMTP id ib1mr5131736icc.12.1358534216718; Fri, 18 Jan 2013 10:36:56 -0800 (PST) Received: by 10.50.13.71 with HTTP; Fri, 18 Jan 2013 10:36:56 -0800 (PST) In-Reply-To: <20130118173602.GA76438@neutralgood.org> References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> Date: Fri, 18 Jan 2013 20:36:56 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: kpneal@pobox.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Warren Block , ml-freebsd-stable , Ian Lepore , Ronald Klop 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, 18 Jan 2013 18:37:02 -0000 Hello, Thanks everyone for the input. Here's what I did. * Checked power cables - everything okay * Checked for bad capacitors - everything okay * Ran memtest86+ test - everything okay I have to mention also that the machine's hardware is new one - hdds, motherboard, memory, power supply, etc.. The only thing I've replaced on this machine are 2 x 750Gb old Seagate disks with brand new 2 x 1000Gb Seagate ones. That was a month ago I think, but didn't have any issue until recently. smartd doesn't say anything to be worried about these disks, neither. I am also using this machine as a build host for months already and I build different projects on it using gcc, clang, scan-build and others and I've never had problems building or testing anything, so I would have noticed any issues if I had problems with gcc or clang for example. On one of my old machines I had issues with memory and bad disks in the past and then the system simply halted. I could see on the terminal that the system halted and some info about the problem itself, but never had a system that rebooted due to issues with hardware. If it was a problem with memory or disks I would expect that the system simply halts, and not reboots itself, and I'm a bit puzzled what could be the root cause of this. This system very rarely changes in terms of hardware or software. On the software side the one change that was done few weeks ago was to allow System V IPC primitives to be used in jails, but I don't see how that could cause these issues. I've had a power outage more than 2 weeks ago, but the UPS successfully shutdown the system and it's batteries have been exhausted at the time of the outage. They were recharged since then, but in the meantime I'm thinking of unplugging this system from the UPS control cables, just to be sure that this outage since 2 weeks ago didn't break the UPS in some way. Thanks again, Marin On Fri, Jan 18, 2013 at 7:36 PM, wrote: > On Fri, Jan 18, 2013 at 09:48:05AM -0700, Ian Lepore wrote: > > I tend to agree, a machine that starts rebooting spontaneously when > > nothing significant changed and it used to be stable is usually a sign > > of a failing power supply or memory. > > Agreed. > > > But I disagree about memtest86. It's probably not completely without > > value, but to me its value is only negative: if it tells you memory is > > bad, it is. If it tells you it's good, you know nothing. Over the > > years I've had 5 dimms fail. memtest86 found the error in one of them, > > but said all the others were fine in continuous 48-hour tests. I even > > tried running the tests on multiple systems. > > > > The thing that always reliably finds bad memory for me > > is /usr/ports/math/mprime run in test/benchmark mode. It often takes 24 > > or more hours of runtime, but it will find your bad memory. > > I've had "good" luck with gcc showing bad memory. If compiling a new kernel > produces seg faults then I know I have a hardware problem. I've seen > compilers at work failing due to bad memory as well. > > Some problems only happen with particular access patterns. So if a > compiler > works fine then, like memtest86, it doesn't say anything about the health > of the hardware. > > -- > Kevin P. Neal http://www.pobox.com/~kpn/ > 'Concerns about "rights" and "ownership" of domains are > inappropriate. > It is appropriate to be concerned about "responsibilities" and "service" > to the community.' -- RFC 1591, page 4: March 1994 > _______________________________________________ > 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" > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 20:23:11 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18139EA4; Fri, 18 Jan 2013 20:23:11 +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 B40BE607; Fri, 18 Jan 2013 20:23:10 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0IKN2vh001865; Fri, 18 Jan 2013 13:23:02 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0IKN0OW001862; Fri, 18 Jan 2013 13:23:01 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 18 Jan 2013 13:23:00 -0700 (MST) From: Warren Block To: kpneal@pobox.com Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 In-Reply-To: <20130118173602.GA76438@neutralgood.org> Message-ID: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> 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]); Fri, 18 Jan 2013 13:23:02 -0700 (MST) Cc: freebsd-stable@FreeBSD.org, Ian Lepore , Ronald Klop 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, 18 Jan 2013 20:23:11 -0000 On Fri, 18 Jan 2013, kpneal@pobox.com wrote: > On Fri, Jan 18, 2013 at 09:48:05AM -0700, Ian Lepore wrote: >> I tend to agree, a machine that starts rebooting spontaneously when >> nothing significant changed and it used to be stable is usually a sign >> of a failing power supply or memory. > > Agreed. > >> But I disagree about memtest86. It's probably not completely without >> value, but to me its value is only negative: if it tells you memory is >> bad, it is. If it tells you it's good, you know nothing. Over the >> years I've had 5 dimms fail. memtest86 found the error in one of them, >> but said all the others were fine in continuous 48-hour tests. I even >> tried running the tests on multiple systems. >> >> The thing that always reliably finds bad memory for me >> is /usr/ports/math/mprime run in test/benchmark mode. It often takes 24 >> or more hours of runtime, but it will find your bad memory. > > I've had "good" luck with gcc showing bad memory. If compiling a new kernel > produces seg faults then I know I have a hardware problem. I've seen > compilers at work failing due to bad memory as well. > > Some problems only happen with particular access patterns. So if a compiler > works fine then, like memtest86, it doesn't say anything about the health > of the hardware. Most test tools are like that. They might diagnose something as bad, but they often can't prove it is good. SMART has a reputation for not finding any problems on disks that are failing, and capacitors that aren't swollen or leaking still may not be working. But diagnostic tools can at least give a hint. In my case, memtest indicated a problem--a big problem. I removed one DIMM at random (there were only two) and the problems and memtest errors both went away. Replace the DIMM, and both came back. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 19 10:30:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9EC08AF1; Sat, 19 Jan 2013 10:30:20 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0E642658; Sat, 19 Jan 2013 10:30:19 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id ji2so2411759bkc.1 for ; Sat, 19 Jan 2013 02:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ioLY//4fsTdwuYPLya12x1a6QJ6Qe7kh0prVMIbzqq0=; b=rV78OsqBhzRIV7hmgOe4uClblybdJH9eJRXKAVGTml4CpxvjiCvZsuEO/69AF3e3x2 6PgSZ7nR6/i53YGpPkc0pkEEU29lrw8c+ZWhFn19kNQbBbUgLq776RBRyaW2een5iLG3 sne8h6sb6Bn+Qe4/bpP0/Pobn9rH4O3PPjPFr5OXu6z6RFeXDCg1qWtTSSbEo3RD0OQ4 iY+gz4XKiXX4SCMRGGzfRXGHqNEFwE4xTsodh1EjilberJRcSUJt82Nl+ELgtN9wyWLE lWLXIlj7J1+0N/pyFODNa3pNUI5OPnQndch5k9RFiKv0zhUPOyYbPl63QSrri1CMyVXE S5aw== MIME-Version: 1.0 X-Received: by 10.204.148.134 with SMTP id p6mr3186143bkv.75.1358591417181; Sat, 19 Jan 2013 02:30:17 -0800 (PST) Received: by 10.204.179.146 with HTTP; Sat, 19 Jan 2013 02:30:17 -0800 (PST) In-Reply-To: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> Date: Sat, 19 Jan 2013 12:30:17 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ml-freebsd-stable , Ian Lepore , kpneal@pobox.com, Ronald Klop 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, 19 Jan 2013 10:30:20 -0000 Hi, Re-sending this one, as I've attached an image which was too large to pass the mailing lists, sorry about that :) After starting the system last night I kept monitoring the memory usage just in case I see something strange and I've noticed a significant memory drop of the free memory between 03:00am and 03:05am time. I've taken a screenshot of the graph, which you can also see at the link below: * http://users.unix-heaven.org/~dnaeon/memory-usage.jpg At 03:00am I can see that periodic(8) runs, but I don't see what could have taken so much of the free memory. I'm also running this system on ZFS and have daily rotating ZFS snapshots created - currently the number of ZFS snapshots are > 1000, and not sure if that could be causing this. Here's a list of the periodic(8) daily scripts that run at 03:00am time. % ls -1 /etc/periodic/daily 100.clean-disks 110.clean-tmps 120.clean-preserve 130.clean-msgs 140.clean-rwho 150.clean-hoststat 200.backup-passwd 210.backup-aliases 220.backup-pkgdb 300.calendar 310.accounting 330.news 400.status-disks 404.status-zfs 405.status-ata-raid 406.status-gmirror 407.status-graid3 408.status-gstripe 409.status-gconcat 420.status-network 430.status-rwho 440.status-mailq 450.status-security 460.status-mail-rejects 470.status-named 480.status-ntpd 490.status-pkg-changes 500.queuerun 800.scrub-zfs 999.local % ls -1 /usr/local/etc/periodic/daily 402.zfSnap 403.zfSnap_delete 411.pkg-backup smart I'll keep monitoring the memory usage and will see if the free memory drops again by more than 50% on the next periodic(8) daily run. If the memory drop keeps the current trend that would mean that the system should crash in the next 1-2 days, so if that happens and the memory was low at that time I'll start debugging the periodic(8) scripts and see which one might be causing this. Thanks and regards, Marin On Fri, Jan 18, 2013 at 10:23 PM, Warren Block wrote: > On Fri, 18 Jan 2013, kpneal@pobox.com wrote: > > On Fri, Jan 18, 2013 at 09:48:05AM -0700, Ian Lepore wrote: >> >>> I tend to agree, a machine that starts rebooting spontaneously when >>> nothing significant changed and it used to be stable is usually a sign >>> of a failing power supply or memory. >>> >> >> Agreed. >> >> But I disagree about memtest86. It's probably not completely without >>> value, but to me its value is only negative: if it tells you memory is >>> bad, it is. If it tells you it's good, you know nothing. Over the >>> years I've had 5 dimms fail. memtest86 found the error in one of them, >>> but said all the others were fine in continuous 48-hour tests. I even >>> tried running the tests on multiple systems. >>> >>> The thing that always reliably finds bad memory for me >>> is /usr/ports/math/mprime run in test/benchmark mode. It often takes 24 >>> or more hours of runtime, but it will find your bad memory. >>> >> >> I've had "good" luck with gcc showing bad memory. If compiling a new >> kernel >> produces seg faults then I know I have a hardware problem. I've seen >> compilers at work failing due to bad memory as well. >> >> Some problems only happen with particular access patterns. So if a >> compiler >> works fine then, like memtest86, it doesn't say anything about the health >> of the hardware. >> > > Most test tools are like that. They might diagnose something as bad, but > they often can't prove it is good. SMART has a reputation for not finding > any problems on disks that are failing, and capacitors that aren't swollen > or leaking still may not be working. > > But diagnostic tools can at least give a hint. In my case, memtest > indicated a problem--a big problem. I removed one DIMM at random (there > were only two) and the problems and memtest errors both went away. Replace > the DIMM, and both came back. > > ______________________________**_________________ > 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 > " > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jan 19 13:09:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF5EFC4B for ; Sat, 19 Jan 2013 13:09:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82974A86 for ; Sat, 19 Jan 2013 13:09:29 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5E730B965; Sat, 19 Jan 2013 08:09:28 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org, prabhpal@digital-infotech.net Subject: Re: Failed to attach P_CNT - FreeBSD 9.1 RC3 Date: Sat, 19 Jan 2013 07:26:16 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301190726.16486.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 19 Jan 2013 08:09:28 -0500 (EST) 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, 19 Jan 2013 13:09:29 -0000 On Sunday, November 04, 2012 05:56:33 AM Shiv. Nath wrote: > Dear FreeBSD Community Friends, > > It is FreeBSD 9.1 RC3, i get the following warning in the message log > file. i need assistance to understand the meaning of this error, how > serious is it? > > acpi_throttle23: failed to attach P_CNT On newer CPUs that use est you don't want to use acpi_throttle anyway so you can ignore the errors. (est gives you power savings when it lowers your CPU speed, acpi_throttle generally does not, it only helps with lowering the temperature) -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Sat Jan 19 13:09:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F250BC4C for ; Sat, 19 Jan 2013 13:09:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C71F9A87 for ; Sat, 19 Jan 2013 13:09:29 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E1C0B989; Sat, 19 Jan 2013 08:09:29 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: Startup lapic messages Date: Sat, 19 Jan 2013 07:53:42 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <4474191355830105@web26h.yandex.ru> In-Reply-To: <4474191355830105@web26h.yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301190753.42376.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 19 Jan 2013 08:09:29 -0500 (EST) Cc: "S.N.Grigoriev" 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, 19 Jan 2013 13:09:30 -0000 On Tuesday, December 18, 2012 06:28:25 AM S.N.Grigoriev wrote: > Hi list, > > I've installed FreeBSD 9.1R amd64 on a new Intel server. > The following lapic messages appear during system startup: > > lapic18: Forcing LINT1 to edge trigger > SMP: AP CPU #2 Launched! > lapic50: Forcing LINT1 to edge trigger > SMP: AP CPU #6 Launched! > lapic20: Forcing LINT1 to edge trigger > SMP: AP CPU #3 Launched! > lapic32: Forcing LINT1 to edge trigger > SMP: AP CPU #4 Launched! > lapic2: Forcing LINT1 to edge trigger > SMP: AP CPU #1 Launched! > lapic34: Forcing LINT1 to edge trigger > SMP: AP CPU #5 Launched! > lapic52: Forcing LINT1 to edge trigger > SMP: AP CPU #7 Launched! > > I've never seen such messages in past. > Does it mean I have some hardware problem/misconfiguration? Your BIOS is slightly buggy, but in a harmless way. You can ignore these. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Sat Jan 19 13:09:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 675F6C4D for ; Sat, 19 Jan 2013 13:09:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 42530A88 for ; Sat, 19 Jan 2013 13:09:30 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AC833B98F; Sat, 19 Jan 2013 08:09:29 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: 9-STABLE -> NFS -> NetAPP: Date: Sat, 19 Jan 2013 07:57:26 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201301190757.26398.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 19 Jan 2013 08:09:29 -0500 (EST) Cc: Hub- Marketing 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, 19 Jan 2013 13:09:30 -0000 On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote: > I'm running a few servers sitting on top of a NetAPP file server =85 > everything runs great, but periodically I'm getting: >=20 > nfs_getpages: error 13 > vm_fault: pager read error, pid 11355 (https) Are you using interruptible mounts ("intr" mount option)? Also, can you get ps output that includes the 'l' flag to show what the processes are stuck on? =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Sat Jan 19 15:33:54 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96A8D890 for ; Sat, 19 Jan 2013 15:33:54 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE78DB for ; Sat, 19 Jan 2013 15:33:50 +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 r0JFXnDq012715 for ; Sat, 19 Jan 2013 08:33:49 -0700 (MST) (envelope-from ian@FreeBSD.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 r0JFXkfS009156; Sat, 19 Jan 2013 08:33:46 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Ian Lepore To: Marin Atanasov Nikolov In-Reply-To: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> Content-Type: text/plain; charset="us-ascii" Date: Sat, 19 Jan 2013 08:33:46 -0700 Message-ID: <1358609626.32417.266.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Warren Block , ml-freebsd-stable , kpneal@pobox.com, Ronald Klop 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, 19 Jan 2013 15:33:54 -0000 On Sat, 2013-01-19 at 12:30 +0200, Marin Atanasov Nikolov wrote: > Hi, > > Re-sending this one, as I've attached an image which was too large to pass > the mailing lists, sorry about that :) > > After starting the system last night I kept monitoring the memory usage > just in case I see something strange and I've noticed a significant memory > drop of the free memory between 03:00am and 03:05am time. I've taken a > screenshot of the graph, which you can also see at the link below: > > * http://users.unix-heaven.org/~dnaeon/memory-usage.jpg > > At 03:00am I can see that periodic(8) runs, but I don't see what could have > taken so much of the free memory. I'm also running this system on ZFS and > have daily rotating ZFS snapshots created - currently the number of ZFS > snapshots are > 1000, and not sure if that could be causing this. Here's a > list of the periodic(8) daily scripts that run at 03:00am time. > [...] > What exactly is that graph displaying for "available memory?" That is, what is the source of info on the graph? If it's just showing memory that appears in top as "Free" that's not the whole picture; the memory in the Inactive category is also available. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sat Jan 19 17:45:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 791DBB7D; Sat, 19 Jan 2013 17:45:40 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by mx1.freebsd.org (Postfix) with ESMTP id BEDAA9F8; Sat, 19 Jan 2013 17:45:39 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id jf3so2462282bkc.9 for ; Sat, 19 Jan 2013 09:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2JzNhyAvXcjbBcQO2vdrVWS+/VZjhevzYb8VAZE0DoM=; b=io+8d8Je+jAAIeTQx7YeN2JWZpb7ysXCooytFkAFixXKzQgaIs9sKScIKLE7kfgruU QLvqVYOFQrdAo4vERP3WFUZPOMV9VRufgBbCbcGZB2aCAErqAmy4Z2c2rZ4Jeppe3ZHB FG+mhRtHBx5t5mIOabADyDon7nf7tZ2fybH83HgeMktMqOCopbenoUJqnoAQSLQQ8oX0 jEyV9qCBtQ/M7e9pebG9nXLHpcuSiKNk2Tvq8yoM/AyH5EHDKbVFnQZJGgnOLPqFDYwQ gFFK0fKwd+uWgM9RCe1XOeByF4j9tfQU1gwBf3E9wAFyYW3QxnviKOZaguCo22K21djU qNZA== MIME-Version: 1.0 X-Received: by 10.204.9.22 with SMTP id j22mr3475590bkj.114.1358617532479; Sat, 19 Jan 2013 09:45:32 -0800 (PST) Received: by 10.204.179.146 with HTTP; Sat, 19 Jan 2013 09:45:32 -0800 (PST) In-Reply-To: <1358609626.32417.266.camel@revolution.hippie.lan> References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> <1358609626.32417.266.camel@revolution.hippie.lan> Date: Sat, 19 Jan 2013 19:45:32 +0200 Message-ID: Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 From: Marin Atanasov Nikolov To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Warren Block , ml-freebsd-stable , kpneal@pobox.com, Ronald Klop 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, 19 Jan 2013 17:45:40 -0000 > > What exactly is that graph displaying for "available memory?" That is, > what is the source of info on the graph? > > Hi Ian, > If it's just showing memory that appears in top as "Free" that's not the > whole picture; the memory in the Inactive category is also available. > > The graph takes into account the sum of the memory as displayed by top(1) in the "Free", "Cache" and "Inactive" categories. Regards, Marin > -- Ian > > > _______________________________________________ > 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" > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jan 19 20:25:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E0A7D3F for ; Sat, 19 Jan 2013 20:25:07 +0000 (UTC) (envelope-from john@theusgroup.com) Received: from theusgroup.com (theusgroup.com [64.122.243.222]) by mx1.freebsd.org (Postfix) with ESMTP id DDBDDEF6 for ; Sat, 19 Jan 2013 20:25:06 +0000 (UTC) To: Marin Atanasov Nikolov Subject: Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0 In-reply-to: References: <1358527685.32417.237.camel@revolution.hippie.lan> <20130118173602.GA76438@neutralgood.org> Comments: In-reply-to Marin Atanasov Nikolov message dated "Sat, 19 Jan 2013 12:30:17 +0200." Date: Sat, 19 Jan 2013 12:19:14 -0800 From: John Message-Id: <20130119201914.84B761CB@server.theusgroup.com> 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, 19 Jan 2013 20:25:07 -0000 >At 03:00am I can see that periodic(8) runs, but I don't see what could have >taken so much of the free memory. I'm also running this system on ZFS and >have daily rotating ZFS snapshots created - currently the number of ZFS >snapshots are > 1000, and not sure if that could be causing this. Here's a >list of the periodic(8) daily scripts that run at 03:00am time. > >% ls -1 /etc/periodic/daily >800.scrub-zfs > >% ls -1 /usr/local/etc/periodic/daily >402.zfSnap >403.zfSnap_delete On a couple of my zfs machines, I've found running a scrub along with other high file system users to be a problem. I therefore run scrub from cron and schedule it so it doesn't overlap with periodic. I also found on a machine with an i3 and 4G ram that overlapping scrubs and snapshot destroy would cause the machine to grind to the point of being non-responsive. This was not a problem when the machine was new, but became one as the pool got larger (dedup is off and the pool is at 45% capacity). I use my own zfs management script and it prevents snapshot destroys from overlapping scrubs, and with a lockfile it prevents a new destroy from being initiated when an old one is still running. zfSnap has its -S switch to prevent actions during a scrub which you should use if you haven't already. Since making these changes, a machine that would have to be rebooted several times a week has now been up 61 days. John Theus TheUs Group