From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 00:02:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E250F15; Sun, 31 Mar 2013 00:02:00 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 306CE15A; Sun, 31 Mar 2013 00:02:00 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id wd20so1129636obb.37 for ; Sat, 30 Mar 2013 17:01:59 -0700 (PDT) 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=dg3zakqtOUNC5DWD8GrQxhhR2zNp9Zrtzq1ObI2XVtg=; b=AmSBN5Oie+qoev9HMmCE8x97mveDdJLSALxiFca/BAvxe5xvevlnPKGssg/0l1tz2B 5hqp46+gGa6eQQPfhmcEoxxoKp03QWQo3rmiLI3mhjvEei92Up+qCyGX1ySrsiunh59d soJg75dwQUO0aauDRDVgTmBC5cOlFxrg2HELqkVspmhspZrFXcV3iJQgoM8JKnTtdXIr hBxiSEIxJOiGtGjpsW/5MfvqiysjN1y6S/o+xwvsslBHUwFpHPcYf6pMFl2N85a9QVQe ziYuVIjp/+CMa/81tOWElMpGIv1kgfvUfuK3kmdhGSTeT3WNkRCybQc0CXWXd4lqDlXu 5NKw== MIME-Version: 1.0 X-Received: by 10.60.133.75 with SMTP id pa11mr2372790oeb.70.1364688119762; Sat, 30 Mar 2013 17:01:59 -0700 (PDT) Received: by 10.182.116.196 with HTTP; Sat, 30 Mar 2013 17:01:59 -0700 (PDT) In-Reply-To: <20130330230931.GA1548@glenbarber.us> References: <20130330020311.GB1687@glenbarber.us> <20130330093352.58bb5539@X220.ovitrap.com> <20130330230931.GA1548@glenbarber.us> Date: Sat, 30 Mar 2013 20:01:59 -0400 Message-ID: Subject: Re: Question on building from sources. From: Super Bisquit To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Erich Dollansky , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 00:02:00 -0000 That was the error that came up, apologies for not specifying such. I'm not trying to disable clang but am trying to build the system using what is there. This is about the time I need a powerpc laptop or a connection...... On Sat, Mar 30, 2013 at 7:09 PM, Glen Barber wrote: > On Sat, Mar 30, 2013 at 07:05:47PM -0400, Super Bisquit wrote: > > Okay. I already have 10.0 on the machine from a year ago. What I have > come > > up against is CLANG_IS_CC ="no" when trying to build run(4). > > If you are trying to disable clang, you want to use: > > WITHOUT_CLANG_IS_CC=yes > > > What is the current state of clang as cc compiler on ppc32? <-- This > needs > > to be fixed first. > > I am not aware of any problems. > > Glen > > > Thanks for the replies and sorry for any noise. > > > > > > > > On Fri, Mar 29, 2013 at 10:33 PM, Erich Dollansky < > > erichsfreebsdlist@alogt.com> wrote: > > > > > Hi, > > > > > > On Fri, 29 Mar 2013 22:03:11 -0400 > > > Glen Barber wrote: > > > > > > > On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote: > > > > > I have my QuickSilver and no internet connection. I have a few > > > > > questions. 1. Do I download the latest for PowerPC(32bit) and then > > > > > download the sources according to the Makefile. > > > > > > > > For ports, yes, you will to do 'make fetch' or 'make fetch-recursive' > > > > for third-party software you want to install. > > > > > > > yes. > > > > > > > > 3. Has anyone else done this before? If yes, then what were your > > > > > results? > > > > > > > > > > > > > It is painful. My suggestion is to identify everything you > absolutely > > > > need, and do from a separate machine with internet access: > > > > > > > I do this all the while as I have only random Internet connection. But > > > I do this only for amd64. It works most of the time. Expect some > > > returns to the machine with an Internet connection. > > > > > > > Note that if anything is missing, build will fail at compile time on > > > > the internet-less machine. > > > > > > This should only be a problem for the ports. The sources can easily be > > > downloaded in one go. > > > > > > Erich > > > > From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 00:10:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7168128; Sun, 31 Mar 2013 00:10:39 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8C0198; Sun, 31 Mar 2013 00:10:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Dz8C6F+CjVItQvczKXQ0nHcokBDpwH6v0/GcroBtGX0=; b=dR3vXV9PQOzgzOFBHVOrvZLT009dBD+0I0NJkvWUs6+4KvsBVf9owt75wx+xTHjzqZZUHeeGQ+EIQAJFTDV3Lz4Dz2+UY9iSoz73g8N6ORPou7rvZ9SMofiyyQAoHIUjodudXjH5P+hqMThPbI9mcTin/Qbni/yRPrZcUqePpmQ=; Received: from [122.129.203.50] (port=57431 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UM5qy-001kdi-E1; Sat, 30 Mar 2013 18:10:33 -0600 Date: Sun, 31 Mar 2013 07:10:16 +0700 From: Erich Dollansky To: Super Bisquit Subject: Re: Question on building from sources. Message-ID: <20130331071016.3b0b3d9d@X220.ovitrap.com> In-Reply-To: References: <20130330020311.GB1687@glenbarber.us> <20130330093352.58bb5539@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Glen Barber , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 00:10:39 -0000 Hi, On Sat, 30 Mar 2013 19:05:47 -0400 Super Bisquit wrote: > Okay. I already have 10.0 on the machine from a year ago. What I have this sounds a bit old. > come up against is CLANG_IS_CC ="no" when trying to build run(4). > What is the current state of clang as cc compiler on ppc32? <-- This > needs to be fixed first. I do not use FreeBSD on any thing else but AMD64. > Thanks for the replies and sorry for any noise. Isn't the noise the idea behind this mailing list? Erich From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 04:00:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CB7A7400 for ; Sun, 31 Mar 2013 04:00:30 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8C93B86A for ; Sun, 31 Mar 2013 04:00:30 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id jz10so1579260veb.19 for ; Sat, 30 Mar 2013 21:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j3lEfUgl3ENIkRJe1asq24n4ZDTwwnC7JLLuXafk/pE=; b=CI+JNeVQ4WyrhFfGG539oN7s2qRlCq9fkBckNwKmZ4O1sSK84GeKWpvIXFnrr7i1ln +OYPeGVZaPjct55QdCJsKEkjsKMIFZ4GUVu7p2vuYC/ex6+buOCx+A+hdpdbjatrv1/b vhd24ZCieI3qvtn6FDYbX+72WTy+YdTplHqXY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=j3lEfUgl3ENIkRJe1asq24n4ZDTwwnC7JLLuXafk/pE=; b=eseLo6MLkvDOpWOC1sRAn+B0wthQGz3GuTsKNELow8pc2qjLbde34MryTHe6GmwgMB lZi7TETCyOXbZ8amLqMBXoBlbK4ALC+utO4ZWkSESu78SLYAR8rx//hAQK7n3HyUFawG zWIpKfmLgvfbDIq0yz6Lb02qV42Nh2yCr828cNKsP35SkcObbglC9PqsWabfzfejosWF pESlDipTuD6ALamzZnrbAude2DT94IqwVB/FsyueFpJWTgz8/EnEurbYBL4ro/XYYL3y +CQVj3N/dHDspOnMocPow/ZqvKiEbdhLQkJmu8L07BqbcyUgDiV/4IT5qAxWMQY/MZRx zfdA== MIME-Version: 1.0 X-Received: by 10.52.35.110 with SMTP id g14mr4933384vdj.61.1364702424376; Sat, 30 Mar 2013 21:00:24 -0700 (PDT) Received: by 10.221.11.72 with HTTP; Sat, 30 Mar 2013 21:00:24 -0700 (PDT) In-Reply-To: <5157756F.4040908@FreeBSD.org> References: <51536306.5030907@FreeBSD.org> <5157756F.4040908@FreeBSD.org> Date: Sat, 30 Mar 2013 21:00:24 -0700 Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Peter Wemm To: Matthias Andree Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl8EgaCFTVlxDVTwkXgE1ET/m3MuOYA0tb57G8vLFhvgQqL9a8XiUkeWBaxMnf9kEq8NuN6 Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 04:00:30 -0000 On Sat, Mar 30, 2013 at 4:29 PM, Matthias Andree wrote: > Am 27.03.2013 22:22, schrieb Alexander Motin: >> Hi. >> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA >> stack, using only some controller drivers of old ata(4) by having >> `options ATA_CAM` enabled in all kernels by default. I have a wish to >> drop non-ATA_CAM ata(4) code, unused since that time from the head >> branch to allow further ATA code cleanup. >> >> Does any one here still uses legacy ATA stack (kernel explicitly built >> without `options ATA_CAM`) for some reason, for example as workaround >> for some regression? Does anybody have good ideas why we should not drop >> it now? > > Alexander, > > The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397 > where the SATA NCQ slots stall for some Samsung drives in the new stack, > and consequently hang the computer for prolonged episodes where it is in > the NCQ error handling, disallows removal of the old driver. (Last > checked with 9.1-RELEASE at current patchlevel.) We're talking about 10.x, so if you want it fixed, you need update with 10.x information. Please put 10.x diagnostics in the PR. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 07:25:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06AAEB1B for ; Sun, 31 Mar 2013 07:25:08 +0000 (UTC) (envelope-from uzimac@da3m0n8t3r.com) Received: from z.umatar.com (z.umatar.com [66.135.39.87]) by mx1.freebsd.org (Postfix) with ESMTP id CBB58E09 for ; Sun, 31 Mar 2013 07:25:07 +0000 (UTC) Received: from z.umatar.com (localhost [127.0.0.1]) by z.umatar.com (8.14.5/8.14.3) with ESMTP id r2V7P1NC020936 for ; Sun, 31 Mar 2013 00:25:01 -0700 (PDT) (envelope-from uzimac@da3m0n8t3r.com) Received: (from uzimac@localhost) by z.umatar.com (8.14.5/8.14.3/Submit) id r2V7P1tm020935 for current@freebsd.org; Sun, 31 Mar 2013 00:25:01 -0700 (PDT) (envelope-from uzimac@da3m0n8t3r.com) X-Authentication-Warning: z.umatar.com: uzimac set sender to uzimac@da3m0n8t3r.com using -f From: "Waitman Gobble" Subject: rebooting nvidia + keyboard issues To: current@freebsd.org Message-Id: <1364714701.20926@da3m0n8t3r.com> X-Originating-IP: 50.197.134.190 X-Mailer: Usermin 1.510 Date: Sun, 31 Mar 2013 00:25:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1364714701" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 07:25:08 -0000 This is a multi-part message in MIME format. --bound1364714701 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, After updating my machine tonight with > uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248937: Sat Mar 30 21:53:14 PDT 2013 root@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 I noticed the machine rebooting randomly every 20 seconds to 5 minutes. Disabling the nvidia driver seems to fix the problem, and I was able to update after applying ports/177459 patch. The updated nvidia driver seems to have solved the rebooting issue. (it could (also?) be related to linux.ko?) If people are using the nvidia driver and are experiencing a constant reboot issue, it might be good to pop in that patch ASAP. The problem I am noticing now is keyboard related. Booting to single user mode, I cannot type anything at the login prompt with an attached USB keyboard. However in single user mode a PS2 keyboard will allow me to login. I would not say it's not working.. the keyboard functions fine until hitting the login prompt. There are no errors and everything appears to be working fine, however I cannot login. Numlock key lights on and off when pressed. Also, if I boot into multi user mode, I cannot type anything at the login prompt when a PS2 keyboard is attached. But the USB keyboard will work in mutli user mode. Thank you, -- Waitman Gobble San Jose California USA --bound1364714701-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 10:34:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 683EDAAD; Sun, 31 Mar 2013 10:34:25 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 105D323CEE1; Sun, 31 Mar 2013 12:26:43 +0200 (CEST) Message-ID: <51580F62.3080503@FreeBSD.org> Date: Sun, 31 Mar 2013 12:26:42 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Peter Wemm Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <5157756F.4040908@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 10:34:25 -0000 Am 31.03.2013 06:00, schrieb Peter Wemm: > We're talking about 10.x, so if you want it fixed, you need update > with 10.x information. > > Please put 10.x diagnostics in the PR. I will not. The PR was filed four months before 10-CURRENT branched; I have no reason to assume it were to be no longer pertinent -- no MFCs, no PR followups). (according to , 10-CURRENT appeared on 2011-09-26) From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 11:38:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7EBA6B1 for ; Sun, 31 Mar 2013 11:38:55 +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 4EC7A8E6 for ; Sun, 31 Mar 2013 11:38:55 +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 r2VBckcp040290; Sun, 31 Mar 2013 14:38:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r2VBckcp040290 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2VBck5M040289; Sun, 31 Mar 2013 14:38:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Mar 2013 14:38:46 +0300 From: Konstantin Belousov To: Maksim Yevmenkin Subject: Re: [RFC] vfs.read_min proposal Message-ID: <20130331113846.GK3794@kib.kiev.ua> References: <20130328075209.GL3794@kib.kiev.ua> <20130329205853.GB3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7mGvLjfjOoK1a/VV" Content-Disposition: inline In-Reply-To: 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: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 11:38:55 -0000 --7mGvLjfjOoK1a/VV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 29, 2013 at 04:57:48PM -0700, Maksim Yevmenkin wrote: > On Fri, Mar 29, 2013 at 1:58 PM, Konstantin Belousov > wrote: > > I think this is definitely a feature that should be set by a flag to > > either file descriptor used for aio_read, or aio_read call itself. > > Adding a flag to aio_read() might be cumbersome from the ABI perspectiv= e. >=20 > something along the lines of ioctl(F_READAHEAD)/f_seqcount might be > acceptable, dont you think? This is exactly what I talked about starting from the first response. aio_read proposal is some (not-neccessary) refinement. --7mGvLjfjOoK1a/VV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRWCBGAAoJEJDCuSvBvK1BF9sP/jNkaAia6m8uTAvQ3qj6pXPF vclBLALfCimGlgoRTZuncyP4UxatZ++EPfA2RAxqMfD6RuY0ooyIJB2riHirF1uG Gh0F6A0zRHiSphCb0UBUO4VHl8K76FAvTW4Z57WIVSLKGUR6EXgzDYbI9fMwHsRw tp9Em5T6BHsQkdnFwvNAp92A5G+kpE6AJ67DyimLZnGEMHKxQTbFxT4o9XvMwHzF l2lVon0R3nFILtOXFzNd9pUSnpjTMxesqnX2/9xHvgnFKizpep72wLjZ/+bZmDaO j2BL7M9nC5SzWZJgU3JLuGBfksEBiWXQh/F06tMlVIRaRxxQiFpoyf16T4+UV8J7 3Dv0CrVsM4AdVxwllp0EsvseeZ4hPlNoe/5IGZqG/9e3lDb54zxFxsfRxB3msELO /4ED61MXx30jnq/G7Ak/Qv90/feO5X/O5TZ91Q8i/ej8z1UAU2XQSTIoBhCd5jbm 5YU3aIvrL/LV5DYz14ymohsnK8qvy6g2PquiZtAj7hxgSRmk2p3rXYKVAd4S5+HN YK8Gd7xSCtQTyX0vUIh6OCRQujVgQIUVSPOWotuUOll41jYmGfF+v6RzcK9XTuJZ ZqXSXYLHoGbqWZd6N8SBDUyHiOJWyBn29a17qX7b3goKGDsxQ36s2A1F3kGSefZY GQ+wBHqVQFXarSEuY9H8 =e6W+ -----END PGP SIGNATURE----- --7mGvLjfjOoK1a/VV-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 12:37:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C35E7F1A for ; Sun, 31 Mar 2013 12:37: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 3AAEDAC9 for ; Sun, 31 Mar 2013 12:37:41 +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 r2VCbUCd050755; Sun, 31 Mar 2013 15:37:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r2VCbUCd050755 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2VCbUZp050754; Sun, 31 Mar 2013 15:37:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Mar 2013 15:37:30 +0300 From: Konstantin Belousov To: Scott Long Subject: Re: [RFC] vfs.read_min proposal Message-ID: <20130331123730.GL3794@kib.kiev.ua> References: <20130328075209.GL3794@kib.kiev.ua> <20130329205853.GB3794@kib.kiev.ua> <8F56D4EB-E63F-4D52-A495-903019E129AF@samsco.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQjLKkFQ1Ex4sAhM" Content-Disposition: inline In-Reply-To: <8F56D4EB-E63F-4D52-A495-903019E129AF@samsco.org> 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: current@freebsd.org, Maksim Yevmenkin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 12:37:41 -0000 --LQjLKkFQ1Ex4sAhM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 30, 2013 at 01:51:15AM -0600, Scott Long wrote: >=20 > On Mar 29, 2013, at 2:58 PM, Konstantin Belousov wr= ote: >=20 > >>=20 > > I think this is definitely a feature that should be set by a flag to > > either file descriptor used for aio_read, or aio_read call itself. > > Adding a flag to aio_read() might be cumbersome from the ABI perspectiv= e. > >=20 >=20 > Fine if you think that there should be a corresponding fcntl() operation,= but > I see good reason to also have a vfs.read_min that compliments vfs_read_m= ax. > It's no less obscure. >=20 > >>=20 > >> finally, vfs.read_min allows us to control size of orignal disk reads, > >> and, vfs.read_max allows us to control of additional read ahead. so, > >> ww control both sides here. in fact, we can have 1mb reads and 1mb > >> read aheads together. granted, its not going to be optimal for all > >> loads. that is why vfs.read_min default is 1. however, i strongly > >> suspect that there are quite a few workloads where this could really > >> help with disk i/o. > >=20 > > In fact, the existing OS behaviour is reasonable for the arguments > > which are passed to the syscall. The specified read size is 1, and the > > current read-ahead algorithm tries to satisfy the request with minimal > > latency and without creating additional load under memory pressure, > > while starting the useful optimization of the background read. > >=20 >=20 > The doubled transaction made a lot of sense back when disks were very > slow. Now, let's use a modern example: >=20 > Default UFS block size =3D 16k > Default vfs.read_max =3D 8 (128k) > Time spent transferring a 16k block over 3Gbps SATA: 54ns > Time spent transferring a 128k block over 3Gbps SATA: 436ns > Time spent seeking to the 16k/128k block: Average 8ms on modern disks. > % time spent on data vs seek, 16k: 0.68% > % time spent on data vs seek, 128k: 5.4% >=20 > It'll take you 5% longer to get a completion back. Not nothing, but it's > also not something that would be turned on by default, at least not > right now. For 6Gbps SATA, it'll be half of that. However, this is a > very idealized example. When you start getting a busy disk and the > seek times reach the hundreds of milliseconds, this overhead goes > well into the noise. At the same time, reducing the number of > concurrent, unbalanced transactions to the disk makes them perform > much better when they are at their performance saturation point, and > we have very solid numbers to prove it. Hm, what you are talking about is not what the patch does. Patch fakes the read size from the user. Let me reformulate this in the following way: assume that the file extent at the current point is contiguous, and the read-ahead was specified by the file system. Then, is makes absolutely no sense to not read the maximal available contigous extent up to maxra. Current code limits the amount of first clustered read to the amount specified in the usermode read request. I think this is bug, and we do not need a tunable to disable the bug. >=20 > I think that there's still a place for doubled transactions for read ahea= d, > and that place would likely be with low-latency flash, but there's a lot > of other factors that get in the way of that right now in FreeBSD, like t= he > overhead of the threaded handoffs in GEOM. As this area is developed > over the next 6 months, and as we have more time to build and test > more models, I'm sure well get some interesting data. But for now, I'll > argue that Max's proposal is sound and is low maintenance. Even with such low-latency disk, I think that not reading contiguous chunk when there is read-ahead, is wrong. Could you try this, please, instead of read_min ? The patch can be buggy, but it should demonstrate what I mean. diff --git a/sys/kern/vfs_cluster.c b/sys/kern/vfs_cluster.c index 91a0443..c926dda 100644 --- a/sys/kern/vfs_cluster.c +++ b/sys/kern/vfs_cluster.c @@ -201,7 +201,7 @@ cluster_read(struct vnode *vp, u_quad_t filesize, daddr= _t lblkno, long size, */ if (ncontig) { /* Account for our first block. */ - ncontig =3D min(ncontig + 1, nblks); + ncontig =3D min(ncontig + 1, maxra); if (ncontig < nblks) nblks =3D ncontig; bp =3D cluster_rbuild(vp, filesize, lblkno, --LQjLKkFQ1Ex4sAhM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRWC4JAAoJEJDCuSvBvK1BsCYP/1Bj+Sc4HuZjR2h9/JWCRlWr IqPeDDVTUocPTs0PSbKXzo5Q7wBH6DwF8ecrvKRim2wHtVi7hJi7MFiMQQx9s/Jj wa003MTGhsSogvBF82RFEn3yNubwF0jNci6RRw7CIkNDhOeIBfZa2BTnddT4w+9N QX8P6aMi+4GaOYQ7h+SPUppxbZRJN6A1LVl+pLuI75Q3Ie1rdnwd782HHqAwxDvc dCKsLHJGgimlmD4odVYT4QgIvnWAeUSPBXpL0cIbj+cTLWQ63sceMV932UnuPHvP gIWRpxqRh+3iVzFLSr73r9E/IcLLa2hapuoJdmlKjyrRh1ssctsBbqxXZUmw39ni faRFutWBfnNvL0IdRaNa3Hilp6ImOCvxrb6foyH3mbBKZFUXS5hrVjzNaTM6jju9 QdXpOv1Jm2y8zJp9z5rwSfFDymZo1nI/3l7/s2WSrMJjzFcgv6vX9+4hfUfJUjTT ez2ZqScePfTFVILMHD15yTa//3FO9cyhegZCkByWMp7ug1jsnTZlUQe7/MZdq5BO Cc5+34cVd3kJaouhB6eYWGLusDsB8GCfYb3ckyFiluZY/ZMNxEiJDuwIUPMbajSb kdV1KnYUuJ8WZH0DIz9fk3haCiapJBRbyimPRt7w78B+vVsWGw2PXDrZfpnHJUrU gPD8EmQ5fDamIeWIZsRk =K2KQ -----END PGP SIGNATURE----- --LQjLKkFQ1Ex4sAhM-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 13:12:13 2013 Return-Path: Delivered-To: freebsd-current@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 5E25AA0C; Sun, 31 Mar 2013 13:12:13 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD5ACB2; Sun, 31 Mar 2013 13:12:12 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id CE7472283F; Sun, 31 Mar 2013 15:04:09 +0200 (CEST) Date: Sun, 31 Mar 2013 15:04:09 +0200 From: Victor Balada Diaz To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130331130409.GO3178@equilibrium.bsdes.net> References: <51536306.5030907@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51536306.5030907@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 13:12:13 -0000 On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > Hi. > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. > > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Does anybody have good ideas why we should not drop > it now? Hello, At my previous job we had troubles with NCQ on some controllers. It caused failures and silent data corruption. As old ata code didn't use NCQ we just used it. I reported some of the problems on 8.2[1] but the problem existed with 8.3. I no longer have access to those systems, so i don't know if the problem still exists or have been fixed on newer versions. Regards. Victor. [1]: https://groups.google.com/forum/#!topic/muc.lists.freebsd.stable/dAMf028CtXM -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 17:21:50 2013 Return-Path: Delivered-To: freebsd-current@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 85F92344; Sun, 31 Mar 2013 17:21:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4ABF573B; Sun, 31 Mar 2013 17:21:50 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UMLws-000O0p-OZ>; Sun, 31 Mar 2013 19:21:42 +0200 Received: from e178185063.adsl.alicedsl.de ([85.178.185.63] helo=[192.168.0.128]) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UMLws-003G3h-Kp>; Sun, 31 Mar 2013 19:21:42 +0200 Subject: www/apache24: ports like lang/php5 or devel/subversion are disturbed by the apache24 port! From: "O. Hartmann" To: FreeBSD Current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-d2CE1VcFxN2/7NZpkkVj" Date: Sun, 31 Mar 2013 19:21:42 +0200 Message-ID: <1364750502.1715.34.camel@thor.walstatt.dyndns.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Originating-IP: 85.178.185.63 Cc: FreeBSD ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:21:50 -0000 --=-d2CE1VcFxN2/7NZpkkVj Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is hard to explain in the subject. I have Apache 2.4 running on a most recent FreeBSD 10.0: FreeBSD 10.0-CURRENT #1 r248935: Sat Mar 30 20:25:32 CET 2013 I have successfully running port www/apache24. The port is really bumpy, if not to say crappy. Whenever I want to rebuild a port that has alos a module provided for apache24, the port, like php5, ends up crashing just before it gets installed with an obscure error message, that one of the configuration files of Apache 2.4 seems to be wrong - which is a complete non-sense statement, since Apache 2.4 runs well and the log does not show any complains about a wrong config. Below, I provided the error message that comes at the end of the installation of port lang/php5 (a similar error message complaining about AuthzSVN-tags arise when building and reinstalling devel/subversion): =3D=3D=3D>>> Creating a backup package for old version php5-5.4.13 Creating package for php5-5.4.13 The following packages will be deinstalled: php5-5.4.13 The deinstallation will free 15 MB Deleting php5-5.4.13... php5-5.4.13 is required by: cups-pdf-2.6.1_1 cups-smb-backend-1.0_6 cups-base-1.5.4_1 drupal7-7.21 php5-ctype-5.4.13 php5-curl-5.4.13 php5-dom-5.4.13 php5-fileinfo-5.4.13 php5-filter-5.4.13 php5-gd-5.4.13 php5-gettext-5.4.13 php5-hash-5.4.13 php5-iconv-5.4.13 php5-json-5.4.13 php5-ldap-5.4.13 php5-mbstring-5.4.13 php5-mysql-5.4.13 php5-openssl-5.4.13 php5-pdo-5.4.13 php5-pdo_mysql-5.4.13 php5-pdo_pgsql-5.4.13 php5-pdo_sqlite-5.4.13 php5-pgsql-5.4.13 php5-session-5.4.13 php5-simplexml-5.4.13 php5-sqlite3-5.4.13 php5-xml-5.4.13 php5-xsl-5.4.13 php5-zip-5.4.13 php5-zlib-5.4.13 phpldapadmin-1.2.3,1 nagios-3.5.0 owncloud-5.0.0 websvn-2.3.3, deleting anyway [preparing module `php5' in /usr/local/etc/apache24/httpd.conf] done AH00526: Syntax error on line 199 of /usr/local/etc/apache24/extra/httpd-authnz_ldap.conf: Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration apxs:Error: Invalid query string `MPM_NAME'. "/usr/ports/Mk/bsd.apache.mk", line 284: warning: "/usr/local/sbin/apxs -q MPM_NAME" returned non-zero status =3D=3D=3D> php5-5.4.13 is marked as broken: : Error from bsd.apache.mk. apache is installed (or APACHE_PORT is defined) and port requires apache22 at least. *** [install] Error code 1 Stop in /usr/ports/lang/php5. =3D=3D=3D>>> A backup package for php5-5.4.13 should be located in /usr/ports/packages/portmaster-backup =3D=3D=3D>>> Installation of php5-5.4.13 (lang/php5) failed =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Update for php5-5.4.13 failed =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Killing background jobs Terminated --=-d2CE1VcFxN2/7NZpkkVj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJRWHCmAAoJEOgBcD7A/5N89fIIALTHRQeYbg7NELThW4KT7kji Chf1VfJP3clINTrZUGFZbOBKFjGRhUUp9nRjkq/aMccZSpoyU0/1um2PizFveUlY y79Avbk1TJdl5ZvCmsDTmjle+VmsYaczIBG7PGxTMacd7uS3drYAh0QPCKOH0RQ6 6KRfDdSmFYnm5MWvgUhZBO19HduCeKVNdggbLFt2jE0RaGOCR977UnPGLfOF9rGk N4degv7h6PFNd+pzIb64RcCvyaclU/eVFl5HgiVC81FLMKvwl5oGTL99RD9blk7o 4pbjfNF+5yEHCbhc8JGBZihLKhUQqdTFhEkOjYG+quMbsTFQbA3MTg3w2b/xh+A= =BsLI -----END PGP SIGNATURE----- --=-d2CE1VcFxN2/7NZpkkVj-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 17:42:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E43A189C; Sun, 31 Mar 2013 17:42:02 +0000 (UTC) (envelope-from ohauer@FreeBSD.org) Received: from p578be941.dip0.t-ipconnect.de (p578be941.dip0.t-ipconnect.de [87.139.233.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6B96E83A; Sun, 31 Mar 2013 17:42:02 +0000 (UTC) Received: from [192.168.0.100] (cde1100.uni.vrs [192.168.0.100]) (Authenticated sender: ohauer) by p578be941.dip0.t-ipconnect.de (Postfix) with ESMTPSA id 70CF120877; Sun, 31 Mar 2013 19:41:58 +0200 (CEST) Message-ID: <515875C8.1080201@FreeBSD.org> Date: Sun, 31 Mar 2013 19:43:36 +0200 From: Olli Hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: www/apache24: ports like lang/php5 or devel/subversion are disturbed by the apache24 port! References: <1364750502.1715.34.camel@thor.walstatt.dyndns.org> In-Reply-To: <1364750502.1715.34.camel@thor.walstatt.dyndns.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , FreeBSD ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:42:03 -0000 It will take a while until php is really apache24 ready. Work is in progress on php upstream. One of the issues is that APXS does not provide the MPM model which is needed for php and others to build. With a quick search I can find this entry https://bugs.php.net/bug.php?id=61172 Even php build I don't think it is ready for apache24 -- Regards, olli On 2013-03-31 19:21, O. Hartmann wrote: > It is hard to explain in the subject. > > I have Apache 2.4 running on a most recent FreeBSD 10.0: > FreeBSD 10.0-CURRENT #1 r248935: Sat Mar 30 20:25:32 CET 2013 > > I have successfully running port www/apache24. The port is really bumpy, > if not to say crappy. Whenever I want to rebuild a port that has alos a > module provided for apache24, the port, like php5, ends up crashing just > before it gets installed with an obscure error message, that one of the > configuration files of Apache 2.4 seems to be wrong - which is a > complete non-sense statement, since Apache 2.4 runs well and the log > does not show any complains about a wrong config. > > Below, I provided the error message that comes at the end of the > installation of port lang/php5 (a similar error message complaining > about AuthzSVN-tags arise when building and reinstalling > devel/subversion): > > > ===>>> Creating a backup package for old version php5-5.4.13 > Creating package for php5-5.4.13 > The following packages will be deinstalled: > > php5-5.4.13 > > The deinstallation will free 15 MB > Deleting php5-5.4.13... > php5-5.4.13 is required by: cups-pdf-2.6.1_1 cups-smb-backend-1.0_6 > cups-base-1.5.4_1 drupal7-7.21 php5-ctype-5.4.13 php5-curl-5.4.13 > php5-dom-5.4.13 php5-fileinfo-5.4.13 php5-filter-5.4.13 php5-gd-5.4.13 > php5-gettext-5.4.13 php5-hash-5.4.13 php5-iconv-5.4.13 php5-json-5.4.13 > php5-ldap-5.4.13 php5-mbstring-5.4.13 php5-mysql-5.4.13 > php5-openssl-5.4.13 php5-pdo-5.4.13 php5-pdo_mysql-5.4.13 > php5-pdo_pgsql-5.4.13 php5-pdo_sqlite-5.4.13 php5-pgsql-5.4.13 > php5-session-5.4.13 php5-simplexml-5.4.13 php5-sqlite3-5.4.13 > php5-xml-5.4.13 php5-xsl-5.4.13 php5-zip-5.4.13 php5-zlib-5.4.13 > phpldapadmin-1.2.3,1 nagios-3.5.0 owncloud-5.0.0 websvn-2.3.3, deleting > anyway > [preparing module `php5' in /usr/local/etc/apache24/httpd.conf] > done > > AH00526: Syntax error on line 199 > of /usr/local/etc/apache24/extra/httpd-authnz_ldap.conf: > Invalid command 'php_flag', perhaps misspelled or defined by a module > not included in the server configuration > apxs:Error: Invalid query string `MPM_NAME'. > "/usr/ports/Mk/bsd.apache.mk", line 284: warning: "/usr/local/sbin/apxs > -q MPM_NAME" returned non-zero status > ===> php5-5.4.13 is marked as broken: : Error from bsd.apache.mk. > apache is installed (or APACHE_PORT is defined) and port requires > apache22 at least. > *** [install] Error code 1 > > Stop in /usr/ports/lang/php5. > > ===>>> A backup package for php5-5.4.13 should > be located in /usr/ports/packages/portmaster-backup > > ===>>> Installation of php5-5.4.13 (lang/php5) failed > ===>>> Aborting update > > ===>>> Update for php5-5.4.13 failed > ===>>> Aborting update > > ===>>> Killing background jobs > Terminated > From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 21:02:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F047616C; Sun, 31 Mar 2013 21:02:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A6780F00; Sun, 31 Mar 2013 21:02:26 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2VL29hN079467; Sun, 31 Mar 2013 15:02:10 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: <20130331130409.GO3178@equilibrium.bsdes.net> Date: Sun, 31 Mar 2013 15:02:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> To: Victor Balada Diaz , Alexander Motin X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "freebsd-current@freebsd.org FreeBSD" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 21:02:27 -0000 On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz = wrote: > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: >> Hi. >>=20 >> Since FreeBSD 9.0 we are successfully running on the new CAM-based = ATA=20 >> stack, using only some controller drivers of old ata(4) by having=20 >> `options ATA_CAM` enabled in all kernels by default. I have a wish to=20= >> drop non-ATA_CAM ata(4) code, unused since that time from the head=20 >> branch to allow further ATA code cleanup. >>=20 >> Does any one here still uses legacy ATA stack (kernel explicitly = built=20 >> without `options ATA_CAM`) for some reason, for example as workaround=20= >> for some regression? Does anybody have good ideas why we should not = drop=20 >> it now? >=20 > Hello, >=20 > At my previous job we had troubles with NCQ on some controllers. It = caused > failures and silent data corruption. As old ata code didn't use NCQ we = just used > it. >=20 > I reported some of the problems on 8.2[1] but the problem existed with = 8.3. >=20 > I no longer have access to those systems, so i don't know if the = problem > still exists or have been fixed on newer versions. >=20 > Regards. > Victor. So what I hear you and Matthias saying, I believe, is that it should be = easier to force disks to fall back to non-NCQ mode, and/or have a more responsive black-list for problematic controllers. Would this help the situation? = It's hard to justify holding back overall forward progress because of some bad = controllers; we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD = 9.x, enough to make up a sizable percentage of the internet's traffic, and we = see no problems. How can we move forward but also take care of you guys with problematic hardware? Scott From owner-freebsd-current@FreeBSD.ORG Sun Mar 31 22:00:17 2013 Return-Path: Delivered-To: freebsd-current@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 F2281C52 for ; Sun, 31 Mar 2013 22:00:17 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id D5493265 for ; Sun, 31 Mar 2013 22:00:17 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta03.emeryville.ca.mail.comcast.net with comcast id JMhz1l0041afHeLA3N0Gfv; Sun, 31 Mar 2013 22:00:16 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta17.emeryville.ca.mail.comcast.net with comcast id JN0F1l00S1t3BNj8dN0FDE; Sun, 31 Mar 2013 22:00:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4054F73A1C; Sun, 31 Mar 2013 15:00:15 -0700 (PDT) Date: Sun, 31 Mar 2013 15:00:15 -0700 From: Jeremy Chadwick To: Scott Long Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130331220015.GA93163@icarus.home.lan> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364767216; bh=oEi+Vmoh2kow/fmLGUmSJyv2xSL78yJwl2XiEiIizA0=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=cZiU+mn0Z7D08KiOOxUXIF8rYqVUwbBG6/U5ALbwwtL+mOp+8AtiKSLY5fDA2zC6+ 4MWqlh7t9jzKmY5/ONYalB1w9dzJZj+9biO24YpEChHiNXuUxGe/VNOW1bp0ph6UCG NI3M3SIIOeJarngoU9dJTwq7TRZjdkliT5bDnF3FZmxYzCxcpxmMwTQ+fqxeuJUCG2 TNah3DMXB6PzPcTZCqb4SZaxQ0/VnUSRa3q0Cir8HMCr2Qa5rXcElpPX5H1CBNwCFY Nbf2yiUhi7ARFpd1LAOYXKg53xMnXNmMrbq4ioxBuDRw7U56azTxjbEp2yIPnu0OSu IDgRZJTCnJaYA== X-Mailman-Approved-At: Mon, 01 Apr 2013 01:25:06 +0000 Cc: Victor Balada Diaz , Alexander Motin , "freebsd-current@freebsd.org FreeBSD" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 22:00:18 -0000 On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote: > On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote: > > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? Does anybody have good ideas why we should not drop > >> it now? > > > > Hello, > > > > At my previous job we had troubles with NCQ on some controllers. It caused > > failures and silent data corruption. As old ata code didn't use NCQ we just used > > it. > > > > I reported some of the problems on 8.2[1] but the problem existed with 8.3. > > > > I no longer have access to those systems, so i don't know if the problem > > still exists or have been fixed on newer versions. > > So what I hear you and Matthias saying, I believe, is that it should be easier to > force disks to fall back to non-NCQ mode, and/or have a more responsive > black-list for problematic controllers. Would this help the situation? It's hard to > justify holding back overall forward progress because of some bad controllers; > we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, > enough to make up a sizable percentage of the internet's traffic, and we see no > problems. How can we move forward but also take care of you guys with > problematic hardware? I've read a referenced PR (157397) except there really isn't enough technical troubleshooting/detail to determine what the root cause is. That isn't the fault of the reporter either -- the reporter needs to be told what information they need to provide / how to troubleshoot it. Meaning: kernel folks who are in-the-know need to step up and help. That PR is soon-to-be 2 years old and is missing tons of information that, even as a non-kernel guy, that *I* would find useful: 1. Output from: - camcontrol tags ada1 -v - camcontrol identify ada1 - What sorts of filesystems are on ada1; if UFS, tunefs -p output would be greatly appreciated - If the timeouts happen during heavy I/O load, and if so, during what kinds of I/O load (reads or writes). 2. Does "camcontrol tags ada1 -N 31" help? I mention this because stated here: http://lists.freebsd.org/pipermail/freebsd-stable/2013-March/072985.html ...there are statements which imply decreasing queue length may solve the issue. What confuses me, however, is that the queue length on my own systems (with different models of disks, as well as an SSD) all have a limit of 32. I dug through the kernel source for a while but could not easily find where this number comes from. (I have very little familiarity with command queuing at the protocol level) 3. Why not find out why Linux (probably libata) has a 32 (or 31?) queue limit? They have commit logs, and there is the LVKM where you could ask. While I understand reluctance to add something "just because Linux does it", it doesn't appear anyone's stepped up to the plate to ask them why; I pray this is not caused by anti-Linux sentiment. 4. The ada1 device in the PR is a Samsung Spinpoint EcoGreen F2 hard drive (1TB, 5400rpm, 32MB cache). Possibly the drive has firmware bugs relating to its NCQ implementation, or possibly it's going into some power-saving mode (it is an EcoGreen model). I've always been wary of the EcoGreen disks since reading about the F4 EcoGreen firmware fiasco (even though the same page says the F1 and F3 EcoGreen had no issue): http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks 5. We really need to have some way to print "active quirks" for devices, even if it's only at boot-up, e.g.: ada3: quirks=0x0003<4K,NO_NCQ> I'd be happy to write the code for this (basing it on how we do CPU flags), but as I've said in the past, kernel-land is scary to me. 6. The controller referenced is an ATI IXP700. I cannot tell you how many times on the mailing lists I've seen "weird issues" reported by people using that controller. I am in no way/shape/form saying the issue is with the controller or with AHCI compatibility (FreeBSD vs. ATI), because I have no proof. I just find it very unnerving that so many issues have been reported where that controller is involved, and often across all sorts of different device/disk models. All that said: I agree a loader tunable to inhibit command queueing would be nice. sysctl would be even more convenient (easier for real-time testing) but I don't know the implications of turning CQ off in the middle of any pending I/O requests. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 02:14:48 2013 Return-Path: Delivered-To: freebsd-current@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 E239C935; Mon, 1 Apr 2013 02:14:48 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 94096DD8; Mon, 1 Apr 2013 02:14:48 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id er7so1552425obc.21 for ; Sun, 31 Mar 2013 19:14:48 -0700 (PDT) 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=7CKe9fcvaZZ81YeiwbsedV2xA/HsBoEDT0UHnoLieAI=; b=VmbeNK7dnD2gUC/TvSbN5LeB4ePo4/eAlV6pwsRrOUcYiamV/nJ3o62PiEI1QuJRe4 MB4lwvJyB6C0xltYl3YbnhPgas9Es/0uzAD1KNUVwmobOUgw3qoX5ZybRlwDwDjfkyvK DcbzB2eoBq1gev7hiR7XTEULSq9tFykGHzHELj1yk1/ikBscscn9oTpvKgxFRoJVs7Xz x58yUjK+yShBm/7NUcvOw7Oj/Ipv/zflmB9SMGJLdt9+ALGATJebv5mzP9iSpKft4shH KvB3w5j1mmkj36LxQDZALtneSDlIMqQuKEYZpEGMmornWUaA7Q/cCYqs9J574cglugQ6 qrBg== MIME-Version: 1.0 X-Received: by 10.182.116.70 with SMTP id ju6mr3348864obb.48.1364782488160; Sun, 31 Mar 2013 19:14:48 -0700 (PDT) Received: by 10.182.116.196 with HTTP; Sun, 31 Mar 2013 19:14:48 -0700 (PDT) In-Reply-To: <20130331071016.3b0b3d9d@X220.ovitrap.com> References: <20130330020311.GB1687@glenbarber.us> <20130330093352.58bb5539@X220.ovitrap.com> <20130331071016.3b0b3d9d@X220.ovitrap.com> Date: Sun, 31 Mar 2013 22:14:48 -0400 Message-ID: Subject: Re: Question on building from sources. From: Super Bisquit To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Glen Barber , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 02:14:49 -0000 Make fetch-recursive stops due to the vulnerability found in perl versions 5.8 to 5.16.3. What's the current status? Are there any patches? On Sat, Mar 30, 2013 at 8:10 PM, Erich Dollansky < erichsfreebsdlist@alogt.com> wrote: > Hi, > > On Sat, 30 Mar 2013 19:05:47 -0400 > Super Bisquit wrote: > > > Okay. I already have 10.0 on the machine from a year ago. What I have > > this sounds a bit old. > > > come up against is CLANG_IS_CC ="no" when trying to build run(4). > > What is the current state of clang as cc compiler on ppc32? <-- This > > needs to be fixed first. > > I do not use FreeBSD on any thing else but AMD64. > > > Thanks for the replies and sorry for any noise. > > Isn't the noise the idea behind this mailing list? > > Erich > From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 08:52:06 2013 Return-Path: Delivered-To: FreeBSD-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6052B264; Mon, 1 Apr 2013 08:52:06 +0000 (UTC) (envelope-from cnst++@FreeBSD.org) Received: from Cns.Cns.SU (unknown [IPv6:2001:470:7240::]) by mx1.freebsd.org (Postfix) with ESMTP id E81B3A35; Mon, 1 Apr 2013 08:52:05 +0000 (UTC) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by Cns.Cns.SU (8.14.5/8.14.5) with ESMTP id r318q4ca019732; Mon, 1 Apr 2013 01:52:04 -0700 (PDT) Message-ID: <51594AB3.4070002@FreeBSD.org> Date: Mon, 01 Apr 2013 01:52:03 -0700 From: "Constantine A. Murenin" Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 SeaMonkey/2.13.2 MIME-Version: 1.0 To: FreeBSD-current@FreeBSD.org, FreeBSD-hackers@FreeBSD.org Subject: BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 08:52:06 -0000 Dear FreeBSD-{current,hackers}@, It is my great pleasure to announce the immediate availability of a publicly private IPv6-only beta test of BXR.SU -- Super User's BSD Cross Reference. BXR.SU is based on an OpenGrok fork, but it's more than just OpenGrok. We've fixed a number of annoyances, eliminated features that just never worked right from the outright, and provided integration with tools like CVSweb (including awesome mirrors like allbsd.org), FreeBSD's ViewVC (SVN), as well as Gitweb from git.freebsd.your.org, plus a tad of other improvements, including a complete rewrite of an mdoc parser. Last, but definitely not least, is an extensive set of nginx rewrite rules that makes it a breeze to use BXR.SU as a deterministic URL compactor for referencing BSD source code. What's up with the publicly private beta test? We're launching today in a publicly private beta. Participation in the beta is invitation-only; everyone with IPv6 is invited. We're cooperating with ISPs around the world, and in order to be able to access BXR.SU during this beta phase, you must have a special token, also known as a publicly routable IPv6-address, with proper IPv6-connectivity and upstream peering. If you don't have IPv6 yet, but want to participate in this beta test ASAP, then ask your ISP for IPv6 ASAP! Else, if your ISP is not part of our beta rollout, you could try something like tunnelbroker.net from he.net. What's the release schedule? BXR.SU is available through IPv6 today, 2013-04-01. It is currently an IPv6-only site, with an IPv6-only glue, too. As an IPv6-only site, we hereby declare that 2013-04-04 is an IPv4 day. On April 4, we will temporarily enable IPv4 connectivity, for one day, to test the water. (We've heard that IPv4 has some connectivity issues related to NAT, double-NAT, carrier-grade NAT and NAT64, and some small percentage of users (but significant in absolute terms) might not be able to access the site if an A record is published, due to the plentiful of misconfigurations out there; so, we want to take things slow, and ensure our users don't suffer from any inferior connectivity.) If things do go well (we expect IPv6/IPv4-related improvements as time goes by), we will permanently publish an A record for BXR.SU on 2013-04-14. IPv4 glue records will be published shortly thereafter, on 2013-04-24 (we don't do this today, because we're afraid that the nameservers of some ISPs are not configured correctly, and our IPv6 users won't be able to access our site otherwise, so, we think it's a good idea to take things slow and in steps). But why another OpenGrok? Over the years, there have been a number of OpenGrok installations that have made it possible to study and grok BSD code, for which we are very thankful to their maintainers. However, as a general rule, none of them have been inclusive of all BSD flavours, all of them have had rather long and hard-to-remember URLs, which also didn't really look permanent at all, and, unfortunately, many of them no longer exist today, or some new uber-inclusive services like code.metager.de have recently flourished, with an astounding 8 second (yes, eight second) delay for satisfying any single search query (hot queries are returned in as little as just under 4 seconds by metager, yet everything is nonetheless buffered, so, you get no rendering at all for those whole 4 or 8 seconds). So, we thought this had to change. So, what's the deal? It's simple. Say, someone doesn't know who PHK is. You can point them to: http://bxr.su/s?q=phk Want to see if DragonFly keeps queue.h in sync? Take a look at: http://bxr.su/d/sys/sys/queue.h Want to look at FreeBSD's queue.h, to manually compare? Just change the "d" from "/d/" (or select and replace the whole world "DragonFly" from "/DragonFly/") to "f", and you're in FreeBSD: http://bxr.su/f/sys/sys/queue.h Too many /sys/sys/? We've still got you covered, thanks to nginx: http://bxr.su/o/queue.h Anyone uses TAILQ_SWAP? Is that a new thing? Check it out: http://bxr.su/search?q=TAILQ_SWAP Any mentions of "OpenBSD" or "NetBSD" in FreeBSD and DragonFly? http://bxr.su/f,d/s?q=OpenBSD+OR+NetBSD Who's this guy writing this email anyway? Is he BXR'able? http://bxr.su/s?q=%22Constantine%20A.%20Murenin%22%20OR%20cnst Etc. Just how fast is BXR.SU? We expect that most search requests should be fulfilled (search page results generated) in well under 100ms. In my tests, and according to OpenGrok metrics at the bottom of each search page, most search pages are generated in about 30 to 50ms, so, it does seem like there's some room to spare. In addition, of course we use nginx, so, once generated at 40ms, a page should be available immediately in no time should a subsequent identical request come along within a couple of seconds or so. How does it compare with fxr.watson.org? + we're based on OpenGrok, instead of LXR + we also index userland of all BSDs, not just the kernels like the fxr + we do daily updates and re-index of all 4 BSDs - we only track -CURRENT of each BSD + the -current that we track is actually current Is this a replacement to nxr.netbsd.org? Not necessarily. We've noted that the /gnu/ and /contrib/ directories of various BSDs have been constantly giving out lots of false positives on all kinds of search queries, and they have been excluded, for both the accuracy and disc space utilisation. This only affects userland, and mostly excludes stuff that noone really cares about anyways (some exceptions were made, and this is not really in stone anyways). Otherwise, BXR.SU is much faster than the nxr -- nxr search is unbuffered, but takes several seconds on cold runs, and about half a second on hot runs. How does it compare with code.metager.de? + we're over 20000% faster (0.04s vs. 8s). 'nuff said. I welcome comments, questions and suggestions. I hope that this site will be useful to the BSD community, and will join other great and invaluable BSD-related sites that we all use and depend on. In summary, what's unique about bxr.su? * Supports all 4 BSDs * Daily updates * Short URLs, deterministic URL shortener for BSD source code * Kernel + non-gnu userland * Very fast -- most search pages generated in under 50ms * IPv6-only for now, will be dual-stacked very soon Enjoy! Constantine. From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 08:34:59 2013 Return-Path: Delivered-To: FreeBSD-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5400FA77; Mon, 1 Apr 2013 08:34:59 +0000 (UTC) (envelope-from cnst++@FreeBSD.org) Received: from Cns.Cns.SU (unknown [IPv6:2001:470:7240::]) by mx1.freebsd.org (Postfix) with ESMTP id DB8518F1; Mon, 1 Apr 2013 08:34:52 +0000 (UTC) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by Cns.Cns.SU (8.14.5/8.14.5) with ESMTP id r318Yo3v011875; Mon, 1 Apr 2013 01:34:51 -0700 (PDT) Message-ID: <515946AA.2060703@FreeBSD.org> Date: Mon, 01 Apr 2013 01:34:50 -0700 From: "Constantine A. Murenin" Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 SeaMonkey/2.13.2 MIME-Version: 1.0 To: FreeBSD-current@FreeBSD.org, FreeBSD-hackers@FreeBSD.org Subject: BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Apr 2013 11:23:05 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 08:34:59 -0000 Dear FreeBSD-{current,hackers}@, It is my great pleasure to announce the immediate availability of a publicly private IPv6-only beta test of BXR.SU -- Super User's BSD Cross Reference. BXR.SU is based on an OpenGrok fork, but it's more than just OpenGrok. We've fixed a number of annoyances, eliminated features that just never worked right from the outright, and provided integration with tools like CVSweb (including awesome mirrors like allbsd.org), FreeBSD's ViewVC (SVN), as well as Gitweb from git.freebsd.your.org, plus a tad of other improvements, including a complete rewrite of an mdoc parser. Last, but definitely not least, is an extensive set of nginx rewrite rules that makes it a breeze to use BXR.SU as a deterministic URL compactor for referencing BSD source code. What's up with the publicly private beta test? We're launching today in a publicly private beta. Participation in the beta is invitation-only; everyone with IPv6 is invited. We're cooperating with ISPs around the world, and in order to be able to access BXR.SU during this beta phase, you must have a special token, also known as a publicly routable IPv6-address, with proper IPv6-connectivity and upstream peering. If you don't have IPv6 yet, but want to participate in this beta test ASAP, then ask your ISP for IPv6 ASAP! Else, if your ISP is not part of our beta rollout, you could try something like tunnelbroker.net from he.net. What's the release schedule? BXR.SU is available through IPv6 today, 2013-04-01. It is currently an IPv6-only site, with an IPv6-only glue, too. As an IPv6-only site, we hereby declare that 2013-04-04 is an IPv4 day. On April 4, we will temporarily enable IPv4 connectivity, for one day, to test the water. (We've heard that IPv4 has some connectivity issues related to NAT, double-NAT, carrier-grade NAT and NAT64, and some small percentage of users (but significant in absolute terms) might not be able to access the site if an A record is published, due to the plentiful of misconfigurations out there; so, we want to take things slow, and ensure our users don't suffer from any inferior connectivity.) If things do go well (we expect IPv6/IPv4-related improvements as time goes by), we will permanently publish an A record for BXR.SU on 2013-04-14. IPv4 glue records will be published shortly thereafter, on 2013-04-24 (we don't do this today, because we're afraid that the nameservers of some ISPs are not configured correctly, and our IPv6 users won't be able to access our site otherwise, so, we think it's a good idea to take things slow and in steps). But why another OpenGrok? Over the years, there have been a number of OpenGrok installations that have made it possible to study and grok BSD code, for which we are very thankful to their maintainers. However, as a general rule, none of them have been inclusive of all BSD flavours, all of them have had rather long and hard-to-remember URLs, which also didn't really look permanent at all, and, unfortunately, many of them no longer exist today, or some new uber-inclusive services like code.metager.de have recently flourished, with an astounding 8 second (yes, eight second) delay for satisfying any single search query (hot queries are returned in as little as just under 4 seconds by metager, yet everything is nonetheless buffered, so, you get no rendering at all for those whole 4 or 8 seconds). So, we thought this had to change. So, what's the deal? It's simple. Say, someone doesn't know who PHK is. You can point them to: http://bxr.su/s?q=phk Want to see if DragonFly keeps queue.h in sync? Take a look at: http://bxr.su/d/sys/sys/queue.h Want to look at FreeBSD's queue.h, to manually compare? Just change the "d" from "/d/" (or select and replace the whole world "DragonFly" from "/DragonFly/") to "f", and you're in FreeBSD: http://bxr.su/f/sys/sys/queue.h Too many /sys/sys/? We've still got you covered, thanks to nginx: http://bxr.su/o/queue.h Anyone uses TAILQ_SWAP? Is that a new thing? Check it out: http://bxr.su/search?q=TAILQ_SWAP Any mentions of "OpenBSD" or "NetBSD" in FreeBSD and DragonFly? http://bxr.su/f,d/s?q=OpenBSD+OR+NetBSD Who's this guy writing this email anyway? Is he BXR'able? http://bxr.su/s?q=%22Constantine%20A.%20Murenin%22%20OR%20cnst Etc. Just how fast is BXR.SU? We expect that most search requests should be fulfilled (search page results generated) in well under 100ms. In my tests, and according to OpenGrok metrics at the bottom of each search page, most search pages are generated in about 30 to 50ms, so, it does seem like there's some room to spare. In addition, of course we use nginx, so, once generated at 40ms, a page should be available immediately in no time should a subsequent identical request come along within a couple of seconds or so. How does it compare with fxr.watson.org? + we're based on OpenGrok, instead of LXR + we also index userland of all BSDs, not just the kernels like the fxr + we do daily updates and re-index of all 4 BSDs - we only track -CURRENT of each BSD + the -current that we track is actually current Is this a replacement to nxr.netbsd.org? Not necessarily. We've noted that the /gnu/ and /contrib/ directories of various BSDs have been constantly giving out lots of false positives on all kinds of search queries, and they have been excluded, for both the accuracy and disc space utilisation. This only affects userland, and mostly excludes stuff that noone really cares about anyways (some exceptions were made, and this is not really in stone anyways). Otherwise, BXR.SU is much faster than the nxr -- nxr search is unbuffered, but takes several seconds on cold runs, and about half a second on hot runs. How does it compare with code.metager.de? + we're over 20000% faster (0.04s vs. 8s). 'nuff said. I welcome comments, questions and suggestions. I hope that this site will be useful to the BSD community, and will join other great and invaluable BSD-related sites that we all use and depend on. In summary, what's unique about bxr.su? * Supports all 4 BSDs * Daily updates * Short URLs, deterministic URL shortener for BSD source code * Kernel + non-gnu userland * Very fast -- most search pages generated in under 50ms * IPv6-only for now, will be dual-stacked very soon Enjoy! Constantine. From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 12:20:29 2013 Return-Path: Delivered-To: current@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 8853AD06; Mon, 1 Apr 2013 12:20:29 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id BB419DA7; Mon, 1 Apr 2013 12:20:28 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jf3so898859bkc.35 for ; Mon, 01 Apr 2013 05:20:27 -0700 (PDT) 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=h0AzD+vOT4gbTQJpIwC6ruShtMiDfo+2jrYgHGtY+ko=; b=bhVHsW8+FndPEks3e3Wh78v4dfJjAwBBjPixCv31PiZIXOgO/MXNNW53ie8WyW4Han HUR3+fsPk6ut2LhKIAvuBwDdgwzTzl0ki8f7DLVk5xSLIBf99ko/VPzQG8rQjHy6GNRt QjcGCTFYxOXzCUC70vbJneCENQ08YSHALImqNE0V0lOCeH8SVZV81tuVdfR+0bsEU6Vh LJQlwewxYCjEyeYdcJF1SZUzX3rdJHgLteXV8uZAAH+z+D6hL9XR1/NJ1iLCDnvqOAd2 j1R8QfK6Ar8QB9lMUrBP/HjMW5Up2A9PaFsg7THCs1i19T6ak2G5ZcJJ1A8Q0vqxwaXT iciA== X-Received: by 10.204.231.143 with SMTP id jq15mr5038860bkb.76.1364818827784; Mon, 01 Apr 2013 05:20:27 -0700 (PDT) Received: from [192.168.1.128] ([91.196.229.122]) by mx.google.com with ESMTPS id n1sm2895157bkv.14.2013.04.01.05.20.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 05:20:27 -0700 (PDT) Message-ID: <51597B89.4000801@gmail.com> Date: Mon, 01 Apr 2013 15:20:25 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.1 MIME-Version: 1.0 To: Juergen Lock Subject: Re: ports/177488: qemu-1.4 References: <201303300112.r2U1Cr2Z015577@red.freebsd.org> <201303300120.r2U1K0te098396@freefall.freebsd.org> <20130330013337.GA19871@crysys.hu> <20130330082344.GA11534@triton8.kn-bremen.de> In-Reply-To: <20130330082344.GA11534@triton8.kn-bremen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ports-bugs@freebsd.org, Pinter Oliver ICTF , current@freebsd.org, bug-followup@freebsd.org, Oliver Pinter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 12:20:29 -0000 2013-03-30 10:23, Juergen Lock wrote: >> disable some unneeded function, and make qemu 1.4 compilable on FreeBSD 9.1 >> > > I think you are building qemu git head as the hexdump function at least > isn't in 1.4.0? Anyway I have meanwhile updated the qemu-devel port > to 1.4.0 with some similar patches to yours and (among other things) > preliminary bsd-user improvements mostly by ssson and cognet, will > leave the PR open for when I need the hexdump patch for a future > update. Doesn't build WITHOUT_CURL: block/qcow.o: In function `encrypt_sectors': /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow.c:250: undefined reference to `AES_cbc_encrypt' block/qcow2-cluster.o: In function `qcow2_encrypt_sectors': /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow2-cluster.c:309: undefined reference to `AES_cbc_encrypt' gmake: *** [qemu-nbd] Помилка 1 gmake: *** ÐžÑ‡Ñ–ÐºÑƒÐ²Ð°Ð½Ð½Ñ Ð·Ð°Ð²ÐµÑ€ÑˆÐµÐ½Ð½Ñ Ð·Ð°Ð²Ð´Ð°Ð½ÑŒ... block/qcow.o: In function `encrypt_sectors': /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow.c:250: undefined reference to `AES_cbc_encrypt' block/qcow2-cluster.o: In function `qcow2_encrypt_sectors': /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow2-cluster.c:309: undefined reference to `AES_cbc_encrypt' -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 13:14:24 2013 Return-Path: Delivered-To: freebsd-current@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 9464FE0C; Mon, 1 Apr 2013 13:14:24 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3648F296; Mon, 1 Apr 2013 13:14:23 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id D0DD92283F; Mon, 1 Apr 2013 15:14:15 +0200 (CEST) Date: Mon, 1 Apr 2013 15:14:15 +0200 From: Victor Balada Diaz To: Scott Long Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130401131415.GQ3178@equilibrium.bsdes.net> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , "freebsd-current@freebsd.org FreeBSD" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 13:14:24 -0000 On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote: > > On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote: > > > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? Does anybody have good ideas why we should not drop > >> it now? > > > > Hello, > > > > At my previous job we had troubles with NCQ on some controllers. It caused > > failures and silent data corruption. As old ata code didn't use NCQ we just used > > it. > > > > I reported some of the problems on 8.2[1] but the problem existed with 8.3. > > > > I no longer have access to those systems, so i don't know if the problem > > still exists or have been fixed on newer versions. > > > > Regards. > > Victor. > > > So what I hear you and Matthias saying, I believe, is that it should be easier to > force disks to fall back to non-NCQ mode, and/or have a more responsive > black-list for problematic controllers. Would this help the situation? It's hard to > justify holding back overall forward progress because of some bad controllers; > we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, > enough to make up a sizable percentage of the internet's traffic, and we see no > problems. How can we move forward but also take care of you guys with > problematic hardware? > > Scott Being able to configure quirks from loader.conf for disks AND controllers would be great and is not hard to do. If you want i can do a patch in two weeks and send it to you. That way it's easy to test disabling NCQ and/or other things in case of hitting a bug. Also being able to modify the configuration without a kernel recompile would be a big improvement because we could still use freebsd-update to keep systems updated. Anyway, my comment was not against dropping old ata code, but more on the "comments on regresssions on the new one". Regards. Victor. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 14:21:19 2013 Return-Path: Delivered-To: freebsd-current@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 1D2E0E30 for ; Mon, 1 Apr 2013 14:21:19 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by mx1.freebsd.org (Postfix) with ESMTP id 89D778EA for ; Mon, 1 Apr 2013 14:21:18 +0000 (UTC) Received: from [87.79.251.84] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UMfbi-00004z-Nm for freebsd-current@freebsd.org; Mon, 01 Apr 2013 16:21:10 +0200 Date: Mon, 1 Apr 2013 16:18:23 +0200 From: Fabian Keil To: FreeBSD Current Subject: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 Message-ID: <20130401161813.6e42e2a1@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/rndEUROgXS3aLZUHjnb9sGB"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:21:19 -0000 --Sig_/rndEUROgXS3aLZUHjnb9sGB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I got the following panic on 10.0-CURRENT from two days ago while receiving an incremental snapshot to a certain pool: (kgdb) where #0 doadump (textdump=3D0) at pcpu.h:229 #1 0xffffffff8031a3ce in db_dump (dummy=3D, dummy2=3D= 0, dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0xffffffff80319eca in db_command (last_cmdp=3D, cm= d_table=3D, dopager=3D1) at /usr/src/sys/ddb/db_comman= d.c:449 #3 0xffffffff80319c82 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:502 #4 0xffffffff8031c5d0 in db_trap (type=3D, code=3D0) = at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff805d0da3 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff8087fdc3 in trap (frame=3D0xffffff80dc9d6520) at /usr/src/sys= /amd64/amd64/trap.c:579 #7 0xffffffff80869cb2 in calltrap () at exception.S:228 #8 0xffffffff805d058e in kdb_enter (why=3D0xffffffff80a47e7a "panic", msg= =3D) at cpufunc.h:63 #9 0xffffffff80599216 in panic (fmt=3D) at /usr/src/s= ys/kern/kern_shutdown.c:747 #10 0xffffffff8130323f in assfail3 (a=3D, lv=3D, op=3D, rv=3D, f= =3D, l=3D) at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/= opensolaris_cmn_err.c:89 #11 0xffffffff8117924e in zfs_space_delta_cb (bonustype=3D, data=3D0xffffff8015eeb8c0, userp=3D0xfffffe004261c640, groupp=3D0xfff= ffe004261c648) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/zfs_vfsops.c:625 #12 0xffffffff8110003b in dmu_objset_userquota_get_ids (dn=3D0xfffffe004261= c358, before=3D0, tx=3D) at /usr/src/sys/modules/zfs/.= ./../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249 #13 0xffffffff811071b6 in dnode_sync (dn=3D0xfffffe004261c358, tx=3D0xfffff= e00186e1300) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts= /common/fs/zfs/dnode_sync.c:554 #14 0xffffffff810ff98b in dmu_objset_sync_dnodes (list=3D0xfffffe00691a5250= , newlist=3D, tx=3D) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dmu_objset.c:910 #15 0xffffffff810ff825 in dmu_objset_sync (os=3D0xfffffe00691a5000, pio=3D<= value optimized out>, tx=3D0xfffffe00186e1300) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dmu_objset.c:1027 #16 0xffffffff8110cb0d in dsl_dataset_sync (ds=3D0xfffffe001f3d0c00, zio=3D= 0x780, tx=3D0xfffffe00186e1300) at /usr/src/sys/modules/zfs/../../cddl/cont= rib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:1411 #17 0xffffffff8111399a in dsl_pool_sync (dp=3D0xfffffe0069ec4000, txg=3D) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensola= ris/uts/common/fs/zfs/dsl_pool.c:409 #18 0xffffffff8112f0ee in spa_sync (spa=3D0xfffffe0050f00000, txg=3D3292) a= t /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /spa.c:6328 #19 0xffffffff81137c45 in txg_sync_thread (arg=3D0xfffffe0069ec4000) at /us= r/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.= c:493 #20 0xffffffff80569c1a in fork_exit (callout=3D0xffffffff811378d0 , arg=3D0xfffffe0069ec4000, frame=3D0xffffff80dc9d6c00) at /usr/src= /sys/kern/kern_fork.c:991 #21 0xffffffff8086a1ee in fork_trampoline () at exception.S:602 #22 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) f 12 #12 0xffffffff8110003b in dmu_objset_userquota_get_ids (dn=3D0xfffffe004261= c358, before=3D0, tx=3D) at /usr/src/sys/modules/zfs/.= ./../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249 1249 error =3D used_cbs[os->os_phys->os_type](dn->dn_bonustype, data, (kgdb) p *dn $1 =3D {dn_struct_rwlock =3D {lock_object =3D {lo_name =3D 0xffffffff811da0= a9 "dn->dn_struct_rwlock", lo_flags =3D 40960000, lo_data =3D 0, lo_witness= =3D 0x0}, sx_lock =3D 1}, dn_link =3D {list_next =3D 0xfffffe0042629020,=20 list_prev =3D 0xfffffe00691a5360}, dn_objset =3D 0xfffffe00691a5000, dn= _object =3D 55652, dn_dbuf =3D 0xfffffe00427ad0e0, dn_handle =3D 0xfffffe00= 69f70128, dn_phys =3D 0xffffff8015eeb800,=20 dn_type =3D DMU_OT_PLAIN_FILE_CONTENTS, dn_bonuslen =3D 192, dn_bonustype= =3D 44 ',', dn_nblkptr =3D 1 '\001', dn_checksum =3D 0 '\0', dn_compress = =3D 0 '\0', dn_nlevels =3D 1 '\001', dn_indblkshift =3D 14 '\016',=20 dn_datablkshift =3D 0 '\0', dn_moved =3D 0 '\0', dn_datablkszsec =3D 10, = dn_datablksz =3D 5120, dn_maxblkid =3D 0, dn_next_nblkptr =3D "\000\000\000= ", dn_next_nlevels =3D "\000\000\000",=20 dn_next_indblkshift =3D "\000\000\000", dn_next_bonustype =3D ",\000\000"= , dn_rm_spillblk =3D "\000\000\000", dn_next_bonuslen =3D {192, 0, 0, 0}, d= n_next_blksz =3D {0, 0, 0, 0}, dn_dbufs_count =3D 0, dn_dirty_link =3D {{ list_next =3D 0xfffffe00691a51f0, list_prev =3D 0xfffffe0042628ab0}, = {list_next =3D 0x0, list_prev =3D 0x0}, {list_next =3D 0x0, list_prev =3D 0= x0}, {list_next =3D 0x0, list_prev =3D 0x0}}, dn_mtx =3D {lock_object =3D { lo_name =3D 0xffffffff811da0bf "dn->dn_mtx", lo_flags =3D 40960000, l= o_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, dn_dirty_records =3D {{l= ist_size =3D 208, list_offset =3D 0, list_head =3D { list_next =3D 0xfffffe004261c470, list_prev =3D 0xfffffe004261c470}= }, {list_size =3D 208, list_offset =3D 0, list_head =3D {list_next =3D 0xff= fffe004261c490, list_prev =3D 0xfffffe004261c490}}, {list_size =3D 208,=20 list_offset =3D 0, list_head =3D {list_next =3D 0xfffffe004261c4b0, l= ist_prev =3D 0xfffffe004261c4b0}}, {list_size =3D 208, list_offset =3D 0, l= ist_head =3D {list_next =3D 0xfffffe004261c4d0,=20 list_prev =3D 0xfffffe004261c4d0}}}, dn_ranges =3D {{avl_root =3D 0= x0, avl_compar =3D 0xffffffff81106ec0 , avl_offset =3D 0= , avl_numnodes =3D 0, avl_size =3D 40}, {avl_root =3D 0x0,=20 avl_compar =3D 0xffffffff81106ec0 , avl_offset =3D= 0, avl_numnodes =3D 0, avl_size =3D 40}, {avl_root =3D 0x0, avl_compar =3D= 0xffffffff81106ec0 , avl_offset =3D 0,=20 avl_numnodes =3D 0, avl_size =3D 40}, {avl_root =3D 0x0, avl_compar = =3D 0xffffffff81106ec0 , avl_offset =3D 0, avl_numnodes = =3D 0, avl_size =3D 40}}, dn_allocated_txg =3D 3292, dn_free_txg =3D 0,=20 dn_assigned_txg =3D 0, dn_notxholds =3D {cv_description =3D 0xffffffff811= da0dd "dn->dn_notxholds", cv_waiters =3D 0}, dn_dirtyctx =3D DN_UNDIRTIED, = dn_dirtyctx_firstset =3D 0x0, dn_tx_holds =3D {rc_count =3D 0},=20 dn_holds =3D {rc_count =3D 3}, dn_dbufs_mtx =3D {lock_object =3D {lo_name= =3D 0xffffffff811da0cb "dn->dn_dbufs_mtx", lo_flags =3D 40960000, lo_data = =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, dn_dbufs =3D {list_size =3D 224= ,=20 list_offset =3D 176, list_head =3D {list_next =3D 0xfffffe004261c5f8, l= ist_prev =3D 0xfffffe004261c5f8}}, dn_bonus =3D 0x0, dn_have_spill =3D 0, d= n_zio =3D 0xfffffe00695af000, dn_oldused =3D 2560, dn_oldflags =3D 3,=20 dn_olduid =3D 1001, dn_oldgid =3D 1001, dn_newuid =3D 0, dn_newgid =3D 0,= dn_id_flags =3D 5, dn_zfetch =3D {zf_rwlock =3D {lock_object =3D {lo_name = =3D 0xffffffff811dd156 "zf->zf_rwlock", lo_flags =3D 40960000, lo_data =3D = 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, zf_stream =3D {list_size =3D 1= 12, list_offset =3D 88, list_head =3D {list_next =3D 0xfffffe004261c688, li= st_prev =3D 0xfffffe004261c688}}, zf_dnode =3D 0xfffffe004261c358,=20 zf_stream_cnt =3D 0, zf_alloc_fail =3D 0}} The incremental was created with: zfs send -i @2013-03-28_14:21 tank/home/fk@2013-04-01_12:31 piped through mbuffer and received with: zfs receive -v -u -F rockbox/backup/r500/tank/home/fk Reading the incremental directly from a file triggers the panic as as well, but sometimes it takes more than one attempt. The offending sa_magic in the panic message is always the same. The receiving pool appears to be okay: fk@r500 ~ $zpool status rockbox pool: rockbox state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(7) for details. scan: scrub repaired 0 in 0h3m with 0 errors on Mon Apr 1 13:57:35 2013 config: NAME STATE READ WRITE CKSUM rockbox ONLINE 0 0 0 label/rockbox.eli ONLINE 0 0 0 errors: No known data errors The feature that isn't yet enabled is lz4 but after upgrading a copy of the pool the panic was still reproducible. On the receiving side gzip compression is enabled. Fabian --Sig_/rndEUROgXS3aLZUHjnb9sGB Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFZly4ACgkQBYqIVf93VJ1R4QCgoIwD4kojtAN8nO/m1yxVpbFS 4JMAn2INHipf/UWOAvwSkaWXlBc4teHB =ay0r -----END PGP SIGNATURE----- --Sig_/rndEUROgXS3aLZUHjnb9sGB-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 14:46:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12F593E4 for ; Mon, 1 Apr 2013 14:46:15 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id C9A41A15 for ; Mon, 1 Apr 2013 14:46:14 +0000 (UTC) Received: from [93.104.15.65] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UMfzr-0007sG-EV for freebsd-current@freebsd.org; Mon, 01 Apr 2013 16:46:07 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id r31Ek6UI003956 for ; Mon, 1 Apr 2013 16:46:06 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id r31Ek5ui003955 for freebsd-current@freebsd.org; Mon, 1 Apr 2013 16:46:05 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 1 Apr 2013 16:46:05 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: updating ports to HEAD Message-ID: <20130401144605.GA3932@tinyCurrent> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.15.65 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:46:15 -0000 Hello, I have a FreeBSD 10-CURRENT as of: $ uname -a FreeBSD aurora.Sisis.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235646: Sat May 19 15:52:36 CEST 2012 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 and I want to update /usr/ports with SVN to HEAD and compile the stuff I need; Is there something in the base system of r235646 which would not allow to do so, i.e. which is to old for HEAD of ports? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 15:01:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B3694A0E; Mon, 1 Apr 2013 15:01:28 +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 71BA4AE0; Mon, 1 Apr 2013 15:01:28 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 8F6FD1E007A1; Mon, 1 Apr 2013 17:01:27 +0200 (CEST) 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 r31F0uQG093286; Mon, 1 Apr 2013 17:00:56 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.5/8.14.3/Submit) id r31F0sOj093285; Mon, 1 Apr 2013 17:00:54 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Mon, 1 Apr 2013 17:00:54 +0200 To: Volodymyr Kostyrko Subject: Re: ports/177488: qemu-1.4 Message-ID: <20130401150054.GA93250@triton8.kn-bremen.de> References: <201303300112.r2U1Cr2Z015577@red.freebsd.org> <201303300120.r2U1K0te098396@freefall.freebsd.org> <20130330013337.GA19871@crysys.hu> <20130330082344.GA11534@triton8.kn-bremen.de> <51597B89.4000801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51597B89.4000801@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org, bug-followup@freebsd.org, freebsd-ports-bugs@freebsd.org, Juergen Lock , Oliver Pinter , Pinter Oliver ICTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:01:28 -0000 On Mon, Apr 01, 2013 at 03:20:25PM +0300, Volodymyr Kostyrko wrote: > [...] > > Doesn't build WITHOUT_CURL: > > block/qcow.o: In function `encrypt_sectors': > /tmp/ports/usr/ports/emulators/qemu-devel/work/qemu-1.4.0/block/qcow.c:250: > undefined reference to `AES_cbc_encrypt' > [...] Thanx, looks like --disable-curl is now broken upstream so I removed the knob. Juergen From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 15:17:46 2013 Return-Path: Delivered-To: freebsd-current@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 BEF46181 for ; Mon, 1 Apr 2013 15:17:46 +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 EC8D3CBE for ; Mon, 1 Apr 2013 15:17:45 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA25653; Mon, 01 Apr 2013 18:17:43 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5159A517.5070802@FreeBSD.org> Date: Mon, 01 Apr 2013 18:17:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fabian Keil Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 References: <20130401161813.6e42e2a1@fabiankeil.de> In-Reply-To: <20130401161813.6e42e2a1@fabiankeil.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:17:46 -0000 on 01/04/2013 17:18 Fabian Keil said the following: > #10 0xffffffff8130323f in assfail3 (a=, lv=, op=, rv=, f=, l=) > at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:89 > #11 0xffffffff8117924e in zfs_space_delta_cb (bonustype=, data=0xffffff8015eeb8c0, userp=0xfffffe004261c640, groupp=0xfffffe004261c648) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:625 > #12 0xffffffff8110003b in dmu_objset_userquota_get_ids (dn=0xfffffe004261c358, before=0, tx=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249 > #13 0xffffffff811071b6 in dnode_sync (dn=0xfffffe004261c358, tx=0xfffffe00186e1300) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c:554 > #14 0xffffffff810ff98b in dmu_objset_sync_dnodes (list=0xfffffe00691a5250, newlist=, tx=) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:910 > #15 0xffffffff810ff825 in dmu_objset_sync (os=0xfffffe00691a5000, pio=, tx=0xfffffe00186e1300) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1027 > #16 0xffffffff8110cb0d in dsl_dataset_sync (ds=0xfffffe001f3d0c00, zio=0x780, tx=0xfffffe00186e1300) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:1411 > #17 0xffffffff8111399a in dsl_pool_sync (dp=0xfffffe0069ec4000, txg=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:409 > #18 0xffffffff8112f0ee in spa_sync (spa=0xfffffe0050f00000, txg=3292) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6328 > #19 0xffffffff81137c45 in txg_sync_thread (arg=0xfffffe0069ec4000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:493 > #20 0xffffffff80569c1a in fork_exit (callout=0xffffffff811378d0 , arg=0xfffffe0069ec4000, frame=0xffffff80dc9d6c00) at /usr/src/sys/kern/kern_fork.c:991 > #21 0xffffffff8086a1ee in fork_trampoline () at exception.S:602 > #22 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) f 12 > #12 0xffffffff8110003b in dmu_objset_userquota_get_ids (dn=0xfffffe004261c358, before=0, tx=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249 > 1249 error = used_cbs[os->os_phys->os_type](dn->dn_bonustype, data, > (kgdb) p *dn Could you please also provide *dn->dn_phys? > The offending sa_magic in the panic message is always the same. Which part, left side or right side? Right side is the _expected_ value. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 15:36:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECEA1715; Mon, 1 Apr 2013 15:36:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id CAD90DC6; Mon, 1 Apr 2013 15:36:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F406DB91C; Mon, 1 Apr 2013 11:35:59 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: call suspend_cpus() under smp_ipi_mtx Date: Mon, 1 Apr 2013 10:52:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org> In-Reply-To: <514D7A82.9000105@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304011052.18370.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 11:36:00 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:36:01 -0000 On Saturday, March 23, 2013 5:48:50 am Andriy Gapon wrote: > > Looks like this issue needs more thinking and discussing. > > The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on > SMP systems). > This is for exactly the same reasons as to why we first take smp_ipi_mtx before > calling stop_cpus() in the shutdown path. Essentially one CPU could be holding > smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an > acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB shootdown), > while another CPU could be with interrupts disabled (explicitly - like in the > shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs. > > In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all > regular (non-NMI) synchronous IPI-based communication between CPUs. Otherwise a > deadlock is quite possible. > > Some obstacles for just going ahead and making the suggested change: > > - acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; currently > witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we > would have to make intr_table_lock and msi_lock the spin-locks as well; > - AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled and > currently it performs an action that requires memory allocation; again, with > interrupts disabled via intr_disable() this fact is not visible to witness, etc, > but with smp_ipi_mtx it needs to be somehow handled. > > I talked to ACPICA guys about the last issue and they told me that what is > currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts > disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and > _GTS support was removed. > > What do you think? > Thank you. Hmm, I think intr_table_lock used to be a spin lock at some point. I don't remember why we changed it to a regular mutex. It may be that there was a lock order reason for that. :( -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 15:31:10 2013 Return-Path: Delivered-To: freebsd-current@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 EF0E3662 for ; Mon, 1 Apr 2013 15:31:10 +0000 (UTC) (envelope-from miwi@bsdhash.org) Received: from bsdhash.org (bsdhash.org [94.23.250.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCABD7B for ; Mon, 1 Apr 2013 15:31:10 +0000 (UTC) Received: from [192.168.0.105] (unknown [175.139.51.241]) by bsdhash.org (Postfix) with ESMTPA id BB5E150F52; Mon, 1 Apr 2013 23:31:07 +0800 (MYT) Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Martin Wilke In-Reply-To: <20130401161813.6e42e2a1@fabiankeil.de> Date: Mon, 1 Apr 2013 23:31:05 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <01C45826-C32E-49F3-8E4E-4FDDE01569AD@bsdhash.org> References: <20130401161813.6e42e2a1@fabiankeil.de> To: Fabian Keil X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Mon, 01 Apr 2013 15:38:03 +0000 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:31:11 -0000 I can confirm this problem see the same. - Martin On Apr 1, 2013, at 10:18 PM, Fabian Keil = wrote: > I got the following panic on 10.0-CURRENT from two days ago > while receiving an incremental snapshot to a certain pool: >=20 > (kgdb) where > #0 doadump (textdump=3D0) at pcpu.h:229 > #1 0xffffffff8031a3ce in db_dump (dummy=3D, = dummy2=3D0, dummy3=3D0, dummy4=3D0x0) at = /usr/src/sys/ddb/db_command.c:543 > #2 0xffffffff80319eca in db_command (last_cmdp=3D, cmd_table=3D, dopager=3D1) at = /usr/src/sys/ddb/db_command.c:449 > #3 0xffffffff80319c82 in db_command_loop () at = /usr/src/sys/ddb/db_command.c:502 > #4 0xffffffff8031c5d0 in db_trap (type=3D, = code=3D0) at /usr/src/sys/ddb/db_main.c:231 > #5 0xffffffff805d0da3 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff8087fdc3 in trap (frame=3D0xffffff80dc9d6520) at = /usr/src/sys/amd64/amd64/trap.c:579 > #7 0xffffffff80869cb2 in calltrap () at exception.S:228 > #8 0xffffffff805d058e in kdb_enter (why=3D0xffffffff80a47e7a "panic", = msg=3D) at cpufunc.h:63 > #9 0xffffffff80599216 in panic (fmt=3D) at = /usr/src/sys/kern/kern_shutdown.c:747 > #10 0xffffffff8130323f in assfail3 (a=3D, = lv=3D, op=3D, rv=3D, f=3D, l=3D) > at = /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/openso= laris_cmn_err.c:89 > #11 0xffffffff8117924e in zfs_space_delta_cb (bonustype=3D, data=3D0xffffff8015eeb8c0, userp=3D0xfffffe004261c640, = groupp=3D0xfffffe004261c648) > at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= zfs_vfsops.c:625 > #12 0xffffffff8110003b in dmu_objset_userquota_get_ids = (dn=3D0xfffffe004261c358, before=3D0, tx=3D) at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= dmu_objset.c:1249 > #13 0xffffffff811071b6 in dnode_sync (dn=3D0xfffffe004261c358, = tx=3D0xfffffe00186e1300) at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= dnode_sync.c:554 > #14 0xffffffff810ff98b in dmu_objset_sync_dnodes = (list=3D0xfffffe00691a5250, newlist=3D, tx=3D) > at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= dmu_objset.c:910 > #15 0xffffffff810ff825 in dmu_objset_sync (os=3D0xfffffe00691a5000, = pio=3D, tx=3D0xfffffe00186e1300) > at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= dmu_objset.c:1027 > #16 0xffffffff8110cb0d in dsl_dataset_sync (ds=3D0xfffffe001f3d0c00, = zio=3D0x780, tx=3D0xfffffe00186e1300) at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= dsl_dataset.c:1411 > #17 0xffffffff8111399a in dsl_pool_sync (dp=3D0xfffffe0069ec4000, = txg=3D) at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= dsl_pool.c:409 > #18 0xffffffff8112f0ee in spa_sync (spa=3D0xfffffe0050f00000, = txg=3D3292) at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= spa.c:6328 > #19 0xffffffff81137c45 in txg_sync_thread (arg=3D0xfffffe0069ec4000) = at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= txg.c:493 > #20 0xffffffff80569c1a in fork_exit (callout=3D0xffffffff811378d0 = , arg=3D0xfffffe0069ec4000, frame=3D0xffffff80dc9d6c00) = at /usr/src/sys/kern/kern_fork.c:991 > #21 0xffffffff8086a1ee in fork_trampoline () at exception.S:602 > #22 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) f 12 > #12 0xffffffff8110003b in dmu_objset_userquota_get_ids = (dn=3D0xfffffe004261c358, before=3D0, tx=3D) at = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= dmu_objset.c:1249 > 1249 error =3D = used_cbs[os->os_phys->os_type](dn->dn_bonustype, data, > (kgdb) p *dn > $1 =3D {dn_struct_rwlock =3D {lock_object =3D {lo_name =3D = 0xffffffff811da0a9 "dn->dn_struct_rwlock", lo_flags =3D 40960000, = lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, dn_link =3D = {list_next =3D 0xfffffe0042629020,=20 > list_prev =3D 0xfffffe00691a5360}, dn_objset =3D = 0xfffffe00691a5000, dn_object =3D 55652, dn_dbuf =3D 0xfffffe00427ad0e0, = dn_handle =3D 0xfffffe0069f70128, dn_phys =3D 0xffffff8015eeb800,=20 > dn_type =3D DMU_OT_PLAIN_FILE_CONTENTS, dn_bonuslen =3D 192, = dn_bonustype =3D 44 ',', dn_nblkptr =3D 1 '\001', dn_checksum =3D 0 = '\0', dn_compress =3D 0 '\0', dn_nlevels =3D 1 '\001', dn_indblkshift =3D = 14 '\016',=20 > dn_datablkshift =3D 0 '\0', dn_moved =3D 0 '\0', dn_datablkszsec =3D = 10, dn_datablksz =3D 5120, dn_maxblkid =3D 0, dn_next_nblkptr =3D = "\000\000\000", dn_next_nlevels =3D "\000\000\000",=20 > dn_next_indblkshift =3D "\000\000\000", dn_next_bonustype =3D = ",\000\000", dn_rm_spillblk =3D "\000\000\000", dn_next_bonuslen =3D = {192, 0, 0, 0}, dn_next_blksz =3D {0, 0, 0, 0}, dn_dbufs_count =3D 0, = dn_dirty_link =3D {{ > list_next =3D 0xfffffe00691a51f0, list_prev =3D = 0xfffffe0042628ab0}, {list_next =3D 0x0, list_prev =3D 0x0}, {list_next = =3D 0x0, list_prev =3D 0x0}, {list_next =3D 0x0, list_prev =3D 0x0}}, = dn_mtx =3D {lock_object =3D { > lo_name =3D 0xffffffff811da0bf "dn->dn_mtx", lo_flags =3D = 40960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, = dn_dirty_records =3D {{list_size =3D 208, list_offset =3D 0, list_head =3D= { > list_next =3D 0xfffffe004261c470, list_prev =3D = 0xfffffe004261c470}}, {list_size =3D 208, list_offset =3D 0, list_head =3D= {list_next =3D 0xfffffe004261c490, list_prev =3D 0xfffffe004261c490}}, = {list_size =3D 208,=20 > list_offset =3D 0, list_head =3D {list_next =3D = 0xfffffe004261c4b0, list_prev =3D 0xfffffe004261c4b0}}, {list_size =3D = 208, list_offset =3D 0, list_head =3D {list_next =3D 0xfffffe004261c4d0,=20= > list_prev =3D 0xfffffe004261c4d0}}}, dn_ranges =3D {{avl_root =3D= 0x0, avl_compar =3D 0xffffffff81106ec0 , avl_offset = =3D 0, avl_numnodes =3D 0, avl_size =3D 40}, {avl_root =3D 0x0,=20 > avl_compar =3D 0xffffffff81106ec0 , avl_offset = =3D 0, avl_numnodes =3D 0, avl_size =3D 40}, {avl_root =3D 0x0, = avl_compar =3D 0xffffffff81106ec0 , avl_offset =3D 0,=20= > avl_numnodes =3D 0, avl_size =3D 40}, {avl_root =3D 0x0, = avl_compar =3D 0xffffffff81106ec0 , avl_offset =3D 0, = avl_numnodes =3D 0, avl_size =3D 40}}, dn_allocated_txg =3D 3292, = dn_free_txg =3D 0,=20 > dn_assigned_txg =3D 0, dn_notxholds =3D {cv_description =3D = 0xffffffff811da0dd "dn->dn_notxholds", cv_waiters =3D 0}, dn_dirtyctx =3D = DN_UNDIRTIED, dn_dirtyctx_firstset =3D 0x0, dn_tx_holds =3D {rc_count =3D = 0},=20 > dn_holds =3D {rc_count =3D 3}, dn_dbufs_mtx =3D {lock_object =3D = {lo_name =3D 0xffffffff811da0cb "dn->dn_dbufs_mtx", lo_flags =3D = 40960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, dn_dbufs =3D= {list_size =3D 224,=20 > list_offset =3D 176, list_head =3D {list_next =3D = 0xfffffe004261c5f8, list_prev =3D 0xfffffe004261c5f8}}, dn_bonus =3D = 0x0, dn_have_spill =3D 0, dn_zio =3D 0xfffffe00695af000, dn_oldused =3D = 2560, dn_oldflags =3D 3,=20 > dn_olduid =3D 1001, dn_oldgid =3D 1001, dn_newuid =3D 0, dn_newgid =3D = 0, dn_id_flags =3D 5, dn_zfetch =3D {zf_rwlock =3D {lock_object =3D = {lo_name =3D 0xffffffff811dd156 "zf->zf_rwlock", lo_flags =3D 40960000, = lo_data =3D 0,=20 > lo_witness =3D 0x0}, sx_lock =3D 1}, zf_stream =3D {list_size =3D= 112, list_offset =3D 88, list_head =3D {list_next =3D = 0xfffffe004261c688, list_prev =3D 0xfffffe004261c688}}, zf_dnode =3D = 0xfffffe004261c358,=20 > zf_stream_cnt =3D 0, zf_alloc_fail =3D 0}} >=20 > The incremental was created with: > zfs send -i @2013-03-28_14:21 tank/home/fk@2013-04-01_12:31 > piped through mbuffer and received with: > zfs receive -v -u -F rockbox/backup/r500/tank/home/fk >=20 > Reading the incremental directly from a file triggers the > panic as as well, but sometimes it takes more than one attempt. >=20 > The offending sa_magic in the panic message is always the same. >=20 > The receiving pool appears to be okay: >=20 > fk@r500 ~ $zpool status rockbox > pool: rockbox > state: ONLINE > status: Some supported features are not enabled on the pool. The pool = can > still be used, but some features are unavailable. > action: Enable all features using 'zpool upgrade'. Once this is done, > the pool may no longer be accessible by software that does not = support > the features. See zpool-features(7) for details. > scan: scrub repaired 0 in 0h3m with 0 errors on Mon Apr 1 13:57:35 = 2013 > config: >=20 > NAME STATE READ WRITE CKSUM > rockbox ONLINE 0 0 0 > label/rockbox.eli ONLINE 0 0 0 >=20 > errors: No known data errors >=20 > The feature that isn't yet enabled is lz4 but after upgrading > a copy of the pool the panic was still reproducible. On the > receiving side gzip compression is enabled. >=20 > Fabian +-----------------oOO--(_)--OOo-------------------------+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 15:52:11 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D2B31FE9; Mon, 1 Apr 2013 15:52:11 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE0CEC6; Mon, 1 Apr 2013 15:52:11 +0000 (UTC) Received: from [87.79.251.84] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UMh1g-0005mj-0V; Mon, 01 Apr 2013 17:52:04 +0200 Date: Mon, 1 Apr 2013 17:51:30 +0200 From: Fabian Keil To: Andriy Gapon Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 Message-ID: <20130401175126.1d28b0f4@fabiankeil.de> In-Reply-To: <5159A517.5070802@FreeBSD.org> References: <20130401161813.6e42e2a1@fabiankeil.de> <5159A517.5070802@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/N2bYarDm3IOk.gkHS0qDag6"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:52:11 -0000 --Sig_/N2bYarDm3IOk.gkHS0qDag6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 01/04/2013 17:18 Fabian Keil said the following: > > #10 0xffffffff8130323f in assfail3 (a=3D, lv=3D, op=3D, rv=3D,= f=3D, l=3D) > > at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/k= ern/opensolaris_cmn_err.c:89 > > #11 0xffffffff8117924e in zfs_space_delta_cb (bonustype=3D, data=3D0xffffff8015eeb8c0, userp=3D0xfffffe004261c640, groupp=3D0= xfffffe004261c648) > > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/comm= on/fs/zfs/zfs_vfsops.c:625 > > #12 0xffffffff8110003b in dmu_objset_userquota_get_ids (dn=3D0xfffffe00= 4261c358, before=3D0, tx=3D) at /usr/src/sys/modules/z= fs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249 > > #13 0xffffffff811071b6 in dnode_sync (dn=3D0xfffffe004261c358, tx=3D0xf= ffffe00186e1300) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris= /uts/common/fs/zfs/dnode_sync.c:554 > > #14 0xffffffff810ff98b in dmu_objset_sync_dnodes (list=3D0xfffffe00691a= 5250, newlist=3D, tx=3D) > > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/comm= on/fs/zfs/dmu_objset.c:910 > > #15 0xffffffff810ff825 in dmu_objset_sync (os=3D0xfffffe00691a5000, pio= =3D, tx=3D0xfffffe00186e1300) > > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/comm= on/fs/zfs/dmu_objset.c:1027 > > #16 0xffffffff8110cb0d in dsl_dataset_sync (ds=3D0xfffffe001f3d0c00, zi= o=3D0x780, tx=3D0xfffffe00186e1300) at /usr/src/sys/modules/zfs/../../cddl/= contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:1411 > > #17 0xffffffff8111399a in dsl_pool_sync (dp=3D0xfffffe0069ec4000, txg= =3D) at /usr/src/sys/modules/zfs/../../cddl/contrib/op= ensolaris/uts/common/fs/zfs/dsl_pool.c:409 > > #18 0xffffffff8112f0ee in spa_sync (spa=3D0xfffffe0050f00000, txg=3D329= 2) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs= /zfs/spa.c:6328 > > #19 0xffffffff81137c45 in txg_sync_thread (arg=3D0xfffffe0069ec4000) at= /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= txg.c:493 > > #20 0xffffffff80569c1a in fork_exit (callout=3D0xffffffff811378d0 , arg=3D0xfffffe0069ec4000, frame=3D0xffffff80dc9d6c00) at /usr= /src/sys/kern/kern_fork.c:991 > > #21 0xffffffff8086a1ee in fork_trampoline () at exception.S:602 > > #22 0x0000000000000000 in ?? () > > Current language: auto; currently minimal > > (kgdb) f 12 > > #12 0xffffffff8110003b in dmu_objset_userquota_get_ids (dn=3D0xfffffe00= 4261c358, before=3D0, tx=3D) at /usr/src/sys/modules/z= fs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1249 > > 1249 error =3D used_cbs[os->os_phys->os_type](dn->dn_bonustype, data, > > (kgdb) p *dn >=20 > Could you please also provide *dn->dn_phys? vmcore.12: (kgdb) p *dn->dn_phys Cannot access memory at address 0xffffff8019492800 (kgdb) p *dn->dn_dbuf $1 =3D {db =3D {db_object =3D 0, db_offset =3D 28491776, db_size =3D 16384,= db_data =3D 0xffffff8019492000}, db_objset =3D 0xfffffe002bc62400, db_dnod= e_handle =3D 0xfffffe002bc62420, db_parent =3D 0xfffffe005f1071c0,=20 db_hash_next =3D 0x0, db_blkid =3D 1739, db_blkptr =3D 0xffffff801936c580= , db_level =3D 0 '\0', db_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff8= 11d8696 "db->db_mtx", lo_flags =3D 40960000, lo_data =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, db_state =3D DB_CACHED, db_holds= =3D {rc_count =3D 2}, db_buf =3D 0xfffffe005f34c798, db_changed =3D {cv_de= scription =3D 0xffffffff811d86a2 "db->db_changed", cv_waiters =3D 0},=20 db_data_pending =3D 0xfffffe004bcc0c00, db_last_dirty =3D 0xfffffe004bcc0= c00, db_link =3D {list_next =3D 0xfffffe005f3506d0, list_prev =3D 0xfffffe0= 030c392a0}, db_user_ptr =3D 0xfffffe005f269000,=20 db_user_data_ptr_ptr =3D 0x0, db_evict_func =3D 0xffffffff81105770 , db_immediate_evict =3D 0 '\0', db_freed_in_flight =3D 0 '\0'= , db_dirtycnt =3D 1 '\001'} vmcore.13: (kgdb) p *dn->dn_phys Cannot access memory at address 0xffffff8015eeb800 (kgdb) p *dn->dn_dbuf $1 =3D {db =3D {db_object =3D 0, db_offset =3D 28491776, db_size =3D 16384,= db_data =3D 0xffffff8015eeb000}, db_objset =3D 0xfffffe00691a5000, db_dnod= e_handle =3D 0xfffffe00691a5020, db_parent =3D 0xfffffe004254ab60,=20 db_hash_next =3D 0x0, db_blkid =3D 1739, db_blkptr =3D 0xffffff8015d65580= , db_level =3D 0 '\0', db_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff8= 11d8696 "db->db_mtx", lo_flags =3D 40960000, lo_data =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, db_state =3D DB_CACHED, db_holds= =3D {rc_count =3D 2}, db_buf =3D 0xfffffe0042bedcf0, db_changed =3D {cv_de= scription =3D 0xffffffff811d86a2 "db->db_changed", cv_waiters =3D 0},=20 db_data_pending =3D 0xfffffe00406d6500, db_last_dirty =3D 0xfffffe00406d6= 500, db_link =3D {list_next =3D 0xfffffe0042758c10, list_prev =3D 0xfffffe0= 069cab5f8}, db_user_ptr =3D 0xfffffe0069f70000,=20 db_user_data_ptr_ptr =3D 0x0, db_evict_func =3D 0xffffffff81105770 , db_immediate_evict =3D 0 '\0', db_freed_in_flight =3D 0 '\0'= , db_dirtycnt =3D 1 '\001'} vmcore.14: (kgdb) p *dn->dn_phys Cannot access memory at address 0xffffff8014d21800 (kgdb) p *dn->dn_dbuf $1 =3D {db =3D {db_object =3D 0, db_offset =3D 28508160, db_size =3D 16384,= db_data =3D 0xffffff8014d21000}, db_objset =3D 0xfffffe0073372000, db_dnod= e_handle =3D 0xfffffe0073372020, db_parent =3D 0xfffffe00369eec40,=20 db_hash_next =3D 0x0, db_blkid =3D 1740, db_blkptr =3D 0xffffff8014ac3600= , db_level =3D 0 '\0', db_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff8= 11d8696 "db->db_mtx", lo_flags =3D 40960000, lo_data =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, db_state =3D DB_CACHED, db_holds= =3D {rc_count =3D 2}, db_buf =3D 0xfffffe0036b759d8, db_changed =3D {cv_de= scription =3D 0xffffffff811d86a2 "db->db_changed", cv_waiters =3D 0},=20 db_data_pending =3D 0xfffffe0034467700, db_last_dirty =3D 0xfffffe0034467= 700, db_link =3D {list_next =3D 0xfffffe0036c17970, list_prev =3D 0xfffffe0= 0737bc950}, db_user_ptr =3D 0xfffffe00369fe000,=20 db_user_data_ptr_ptr =3D 0x0, db_evict_func =3D 0xffffffff81105770 , db_immediate_evict =3D 0 '\0', db_freed_in_flight =3D 0 '\0'= , db_dirtycnt =3D 1 '\001'} vmcore.15: (kgdb) p *dn->dn_phys Cannot access memory at address 0xffffff8030e73800 (kgdb) p *dn->dn_dbuf $1 =3D {db =3D {db_object =3D 0, db_offset =3D 28508160, db_size =3D 16384,= db_data =3D 0xffffff8030e73000}, db_objset =3D 0xfffffe0028fe2800, db_dnod= e_handle =3D 0xfffffe0028fe2820, db_parent =3D 0xfffffe005ac4dd20,=20 db_hash_next =3D 0x0, db_blkid =3D 1740, db_blkptr =3D 0xffffff8030d49600= , db_level =3D 0 '\0', db_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff8= 11d8696 "db->db_mtx", lo_flags =3D 40960000, lo_data =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, db_state =3D DB_CACHED, db_holds= =3D {rc_count =3D 2}, db_buf =3D 0xfffffe0010130a68, db_changed =3D {cv_de= scription =3D 0xffffffff811d86a2 "db->db_changed", cv_waiters =3D 0},=20 db_data_pending =3D 0xfffffe0057b85200, db_last_dirty =3D 0xfffffe0057b85= 200, db_link =3D {list_next =3D 0xfffffe005ad57890, list_prev =3D 0xfffffe0= 0568765f8}, db_user_ptr =3D 0xfffffe005a7a1000,=20 db_user_data_ptr_ptr =3D 0x0, db_evict_func =3D 0xffffffff81105770 , db_immediate_evict =3D 0 '\0', db_freed_in_flight =3D 0 '\0'= , db_dirtycnt =3D 1 '\001'} > > The offending sa_magic in the panic message is always the same. >=20 > Which part, left side or right side? I meant the left side, but it looks like I only compared the first two pani= cs: fk@r500 /usr/crash $grep ^panic: core.txt.1[2-5] core.txt.12:panic: solaris assert: sa.sa_magic =3D=3D 0x2F505A (0x4d5ea364 = =3D=3D 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensol= aris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 core.txt.13:panic: solaris assert: sa.sa_magic =3D=3D 0x2F505A (0x4d5ea364 = =3D=3D 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensol= aris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 core.txt.14:panic: solaris assert: sa.sa_magic =3D=3D 0x2F505A (0x4be9810a = =3D=3D 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensol= aris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 core.txt.15:panic: solaris assert: sa.sa_magic =3D=3D 0x2F505A (0x4be9810a = =3D=3D 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensol= aris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 The matches seem to correlate with the matching dn->dn_dbuf->db->db_offset values above. Fabian --Sig_/N2bYarDm3IOk.gkHS0qDag6 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFZrQEACgkQBYqIVf93VJ3e1QCeODdEVTiD6TksAu/p815aOPmE 40QAnAhaLasLYhXXXRCfMydh3GPIPq2l =OcRh -----END PGP SIGNATURE----- --Sig_/N2bYarDm3IOk.gkHS0qDag6-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 16:22:36 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0282AD3D for ; Mon, 1 Apr 2013 16:22:36 +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 4C234F8 for ; Mon, 1 Apr 2013 16:22:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA26193; Mon, 01 Apr 2013 19:22:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5159B448.2080500@FreeBSD.org> Date: Mon, 01 Apr 2013 19:22:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fabian Keil Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 References: <20130401161813.6e42e2a1@fabiankeil.de> <5159A517.5070802@FreeBSD.org> <20130401175126.1d28b0f4@fabiankeil.de> In-Reply-To: <20130401175126.1d28b0f4@fabiankeil.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:22:36 -0000 on 01/04/2013 18:51 Fabian Keil said the following: > vmcore.13: > > (kgdb) p *dn->dn_phys > Cannot access memory at address 0xffffff8015eeb800 > (kgdb) p *dn->dn_dbuf > $1 = {db = {db_object = 0, db_offset = 28491776, db_size = 16384, db_data = 0xffffff8015eeb000}, db_objset = 0xfffffe00691a5000, db_dnode_handle = 0xfffffe00691a5020, db_parent = 0xfffffe004254ab60, > db_hash_next = 0x0, db_blkid = 1739, db_blkptr = 0xffffff8015d65580, db_level = 0 '\0', db_mtx = {lock_object = {lo_name = 0xffffffff811d8696 "db->db_mtx", lo_flags = 40960000, lo_data = 0, > lo_witness = 0x0}, sx_lock = 1}, db_state = DB_CACHED, db_holds = {rc_count = 2}, db_buf = 0xfffffe0042bedcf0, db_changed = {cv_description = 0xffffffff811d86a2 "db->db_changed", cv_waiters = 0}, > db_data_pending = 0xfffffe00406d6500, db_last_dirty = 0xfffffe00406d6500, db_link = {list_next = 0xfffffe0042758c10, list_prev = 0xfffffe0069cab5f8}, db_user_ptr = 0xfffffe0069f70000, > db_user_data_ptr_ptr = 0x0, db_evict_func = 0xffffffff81105770 , db_immediate_evict = 0 '\0', db_freed_in_flight = 0 '\0', db_dirtycnt = 1 '\001'} That's interesting. So db.db_data has a bogus address. Not sure how that could happen and what to make of it yet. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 18:06:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 22C6E769; Mon, 1 Apr 2013 18:06:03 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 94C7E728; Mon, 1 Apr 2013 18:06:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:Sender:From:Date; bh=YgemlfPkw3rv05ZYyxcYMyGj7L8twhvlrnt04klICWw=; b=o86g+QH/BhSTIEb5bX5xezS32lu8ZVUBpq4A9ABRHkooIZOkc8qkWQeNC28ueZU+oWFUXDxN6evWGKONQ0Bk0nWcQ56LiMZrYHqAj2RHLYPx+vDD9p2w+8iC2IG+40mFqdCRP5rGk/H+aFGc4O6GUGutm/34iEOsAPsAOWz3f+c=; Received: from cpe-72-182-19-162.austin.res.rr.com ([72.182.19.162]:27290 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UMj7A-0008HD-Kg; Mon, 01 Apr 2013 13:06:01 -0500 Date: Mon, 1 Apr 2013 13:05:49 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: [CRASH] ZFS recv (fwd)/CURRENT Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 2.6 (++) X-LERCTR-Spam-Score: 2.6 (++) X-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5 X-LERCTR-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:06:03 -0000 Re-Sending. Any ideas, guys/gals? This really gets in my way. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---------- Forwarded message ---------- Date: Mon, 25 Mar 2013 09:01:30 -0500 (CDT) From: Larry Rosenman To: freebsd-current@freebsd.org Subject: [CRASH] ZFS recv Greetings, I'm getting a zfs recv crash on 10.0-CURRENT.... I was ssh'd to my 8.4 box and did: zfs send -R -D vault@2013-03-24 | ssh home.lerctr.org zfs recv -F -u -v -d zroot/backups/TBH And on the 2nd (or so) filesystem got the following panic. I have the vmcore as well as sources, and can give ssh access. I can also reproduce this at will. ideas? borg.lerctr.org dumped core - see /var/crash/vmcore.4 Mon Mar 25 08:52:46 CDT 2013 FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #129 r248695: Mon Mar 25 05:03:32 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x378 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80531426 stack pointer = 0x28:0xffffff91579193d0 frame pointer = 0x28:0xffffff9157919470 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1044 (zfs) trap number = 12 panic: page fault cpuid = 0 Uptime: 2m10s Dumping 4913 out of 64747 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/acl_nfs4.ko...Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. done. Loaded symbols for /boot/kernel/acl_nfs4.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichsmb.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /boot/kernel/ichwd.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichwd.ko Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. done. Loaded symbols for /boot/kernel/cpuctl.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. done. Loaded symbols for /boot/kernel/cryptodev.ko Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtraceall.ko Reading symbols from /boot/kernel/profile.ko...Reading symbols from /boot/kernel/profile.ko.symbols...done. done. Loaded symbols for /boot/kernel/profile.ko Reading symbols from /boot/kernel/cyclic.ko...Reading symbols from /boot/kernel/cyclic.ko.symbols...done. done. Loaded symbols for /boot/kernel/cyclic.ko Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /boot/kernel/dtrace.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtrace.ko Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /boot/kernel/systrace.ko.symbols...done. done. Loaded symbols for /boot/kernel/systrace.ko Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /boot/kernel/sdt.ko.symbols...done. done. Loaded symbols for /boot/kernel/sdt.ko Reading symbols from /boot/kernel/lockstat.ko...Reading symbols from /boot/kernel/lockstat.ko.symbols...done. done. Loaded symbols for /boot/kernel/lockstat.ko Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. done. Loaded symbols for /boot/kernel/fasttrap.ko Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /boot/kernel/fbt.ko.symbols...done. done. Loaded symbols for /boot/kernel/fbt.ko Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtnfscl.ko Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtmalloc.ko Reading symbols from /boot/kernel/dtio.ko...Reading symbols from /boot/kernel/dtio.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtio.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /boot/kernel/uhid.ko...Reading symbols from /boot/kernel/uhid.ko.symbols...done. done. Loaded symbols for /boot/kernel/uhid.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:229 #1 0xffffffff80529060 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff805293e7 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff80732cd5 in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:872 #4 0xffffffff807330d9 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:730 #5 0xffffffff807326bc in trap (frame=0xffffff9157919320) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff8071cc62 in calltrap () at exception.S:228 #7 0xffffffff80531426 in _sx_xlock_hard (sx=0xfffffe01d5b64db8, tid=18446741877920023696, opts=, file=0x0, line=250541281) at /usr/src/sys/kern/kern_sx.c:556 #8 0xffffffff80530f8c in _sx_xlock (sx=0x0, opts=0, file=0x0, line=0) at sx.h:152 #9 0xffffffff80e67251 in dmu_objset_from_ds (ds=0xfffffe01d5b64c00, osp=0xffffff91579195b0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:434 #10 0xffffffff80e649ef in dmu_recv_stream (drc=0xffffff9157919750, fp=, voffp=0xffffff9157919740, cleanup_fd=8, action_handlep=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:1318 #11 0xffffffff80ed9226 in zfs_ioc_recv (zc=0xffffff8012cc8000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:4084 #12 0xffffffff80ed44a1 in zfsdev_ioctl (dev=, zcmd=, arg=0xffffff8012cc8000 "zroot/backups/TBH/home", flag=, td=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:5902 #13 0xffffffff80427e0f in devfs_ioctl_f (fp=0xfffffe00c0b360a0, com=3517471259, data=0xffffff8012cc8000, cred=, td=0xfffffe00c0bec490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #14 0xffffffff8057359b in kern_ioctl (td=0xfffffe00c0bec490, fd=, com=18446741877920023696) at file.h:306 #15 0xffffffff8057331f in sys_ioctl (td=0xfffffe00c0bec490, uap=0xffffff9157919b80) at /usr/src/sys/kern/sys_generic.c:693 #16 0xffffffff807335d7 in amd64_syscall (td=0xfffffe00c0bec490, traced=0) at subr_syscall.c:134 #17 0xffffffff8071cf4b in Xfast_syscall () at exception.S:387 #18 0x00000008019dacea in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs - 0:02.51 [kernel] 0 1 0 0 20 0 9428 0 wait DLs - 0:00.10 [init] 0 2 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 3 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto returns 0 4 0 0 -16 0 0 0 - DL - 0:00.00 [fdc0] 0 5 0 0 -8 0 0 0 tx->tx_s DL - 0:00.08 [zfskern] 0 6 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator] 0 7 0 0 -16 0 0 0 ccb_scan DL - 0:00.00 [xpt_thrd] 0 8 0 0 -16 0 0 0 - RL - 0:00.00 [pagedaemon] 0 9 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 6:41.28 [idle] 0 12 0 0 -84 0 0 0 - WL - 0:00.26 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.33 [geom] 0 14 0 0 -16 0 0 0 - DL - 0:00.01 [yarrow] 0 15 0 0 -68 0 0 0 - DL - 0:00.01 [usb] 0 16 0 0 -20 0 0 0 VBoxIS DL - 0:00.00 [TIMER] 0 17 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 18 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 19 0 0 16 0 0 0 - RL - 0:00.00 [syncer] 0 20 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 632 1 0 20 0 13196 0 select Ds - 0:00.00 [devd] 0 757 1 0 20 0 14376 0 select Ds - 0:00.04 [syslogd] 0 760 1 0 -52 0 6180 2088 - Rs - 0:00.00 [watchdogd] 0 774 1 0 20 0 16456 0 select Ds - 0:00.01 [rpcbind] 0 809 1 0 52 0 38948 0 select Ds - 0:00.02 [mountd] 0 815 1 0 52 0 36792 0 select Ds - 0:00.04 [nfsd] 0 817 815 0 52 0 12216 0 rpcsvc D - 0:00.00 [nfsd] 0 853 1 0 20 0 25196 0 select Ds - 0:00.01 [ntpd] 0 874 0 0 -16 0 0 0 sleep DL - 0:00.00 [ng_queue] 0 886 1 0 20 0 34708 0 nanslp Ds - 0:00.01 [perl] 0 890 1 0 52 0 30780 0 nanslp D - 0:00.43 [smartd] 70 899 1 0 20 0 84416 0 select Ds - 0:00.22 [postgres] 70 903 899 0 20 0 84416 0 select Ds - 0:00.00 [postgres] 70 904 899 0 20 0 84416 0 select Ds - 0:00.00 [postgres] 70 905 899 0 20 0 84416 0 select Ds - 0:00.00 [postgres] 70 906 899 0 20 0 44120 0 select Ds - 0:00.00 [postgres] 26 928 1 0 52 0 48644 0 select Ds - 0:00.00 [exim-4.80.1-2] 0 938 1 0 20 0 103216 0 - Rs - 0:00.02 [cupsd] 1028 944 1 0 155 0 40308 0 select Ds - 0:00.05 [boinc_client] 910 948 1 0 20 0 59412 0 uwait Ds - 0:00.00 [bacula-sd] 0 951 1 0 20 0 57068 0 uwait Ds - 0:00.00 [bacula-fd] 910 954 1 0 20 0 72404 0 - Rs - 0:00.00 [bacula-dir] 0 959 1 0 20 0 56264 0 select Ds - 0:00.00 [sshd] 0 969 1 0 20 0 16460 0 nanslp Ds - 0:00.00 [cron] 0 990 1 0 52 0 18576 0 select Ds - 0:00.00 [inetd] 0 1010 1 0 21 0 47584 0 wait Ds - 0:00.00 [login] 0 1011 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1012 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1013 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1014 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1015 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1016 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1017 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1020 1010 0 20 0 16928 0 wait D - 0:00.00 [sh] 0 1022 1020 0 20 0 47640 0 select D+ - 0:00.00 [ssh] 1028 1024 944 0 155 19 54272 0 - RN - 0:17.51 [wcg_hpf2_roset 1028 1025 944 0 155 19 54272 0 - RN - 0:18.11 [wcg_hpf2_roset 1028 1026 944 0 155 19 129292 0 - RN - 0:03.57 [wcgrid_faah_7. 1028 1027 944 0 155 19 1892 0 - RN - 0:00.03 [wcgrid_cep2_6. 1028 1028 944 0 155 19 74216 0 m DN - 0:17.23 [setiathome-6.1 1028 1029 944 0 155 19 74216 0 - RN - 0:19.34 [setiathome-6.1 1028 1030 944 0 155 19 74216 0 m DN - 0:16.21 [setiathome-6.1 1028 1031 944 0 155 19 129292 0 i DN - 0:00.00 [wcgrid_faah_7. 1028 1032 944 0 155 19 74216 0 m DN - 0:17.25 [setiathome-6.1 1028 1033 1027 0 155 19 1892 0 i DN - 0:00.00 [wcgrid_cep2_6. 1028 1034 1033 0 155 19 1892 0 i DN - 0:00.00 [wcgrid_cep2_6. 1028 1035 1024 0 155 19 54272 0 6 DN - 0:00.00 [wcg_hpf2_roset 1028 1036 1035 0 155 19 54272 0 - RN - 0:00.00 [wcg_hpf2_roset 1028 1037 1025 0 155 19 54272 0 6 DN - 0:00.00 [wcg_hpf2_roset 1028 1038 1037 0 155 19 54272 0 6 DN - 0:00.00 [wcg_hpf2_roset 0 1040 959 0 20 0 81532 0 select Ds - 0:00.00 [sshd] 0 1042 1040 0 27 0 20304 0 pause Ds - 0:00.00 [csh] 0 1044 1042 0 21 0 39968 0 - R - 0:00.00 [zfs] ------------------------------------------------------------------------ vmstat -s 339379 cpu context switches 36990 device interrupts 6821 software interrupts 362408 traps 34071033 system calls 21 kernel threads created 834 fork() calls 182 vfork() calls 7 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 1567 vnode pager pageins 11054 vnode pager pages paged in 8 vnode pager pageouts 16 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 11 pages reactivated 33160 copy-on-write faults 209 copy-on-write optimized faults 284971 zero fill pages zeroed 0 zero fill pages prezeroed 107 intransit blocking page faults 405648 total VM faults taken 3427 page faults requiring I/O 0 pages affected by kernel thread creation 32298 pages affected by fork() 6408 pages affected by vfork() 22897 pages affected by rfork() 0 pages cached 407800 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 67444 pages active 20205 pages inactive 8 pages in VM cache 860785 pages wired down 15199607 pages free 4096 bytes per page 247996 total name lookups cache hits (93% pos + 1% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) DEVFS3 207 52K - 226 256 filedesc 78 251K - 1058 16,32,64,128,2048,4096 filedesc_to_leader 11 1K - 11 64 sigio 1 1K - 1 64 kdtrace 500 112K - 1633 64,256 kenv 84 11K - 112 16,32,64,128 kqueue 2 3K - 52 256,2048 proc-args 46 4K - 373 16,32,64,128,256 DEVFS1 181 91K - 199 512 hhook 2 1K - 2 128 ithread 119 21K - 119 32,128,256 KTRACE 100 13K - 100 128 DEVFS 40 1K - 41 16,128 linker 351 171K - 477 16,32,64,128,256,512,1024,2048,4096 DEVFSP 1 1K - 11 64 lockf 50 6K - 86 64,128 loginclass 2 1K - 6 64 cache 1 1K - 1 32 devbuf 17037 34759K - 17243 16,32,64,128,256,512,1024,2048,4096 temp 56 35K - 10350 16,32,64,128,256,512,1024,2048,4096 ip6ndp 5 1K - 6 64,128 module 293 37K - 293 128 mtx_pool 2 16K - 2 osd 8 1K - 20 16,32,64,128 pmchooks 1 1K - 1 128 pgrp 36 5K - 51 128 session 34 5K - 45 128 proc 2 256K - 2 subproc 231 350K - 1202 512,4096 cred 108 17K - 8456 64,256 plimit 19 5K - 202 256 uidinfo 6 33K - 9 128 NFS fh 1 1K - 7 16 sysctl 0 0K - 380 16,32,64 sysctloid 6406 317K - 6553 16,32,64,128 sysctltmp 0 0K - 338 16,32,64,128,256,4096 tidhash 1 256K - 1 callout 9 3208K - 9 umtx 1062 133K - 1062 128 p1003.1b 1 1K - 1 16 SWAP 12 19681K - 12 64 bus 900 86K - 4751 16,32,64,128,256,512,1024 bus-sc 135 290K - 1989 16,32,64,128,256,512,1024,2048,4096 devstat 24 49K - 24 32,4096 eventhandler 86 7K - 86 64,128 kobj 169 676K - 681 4096 Per-cpu 1 1K - 1 32 rman 292 33K - 686 16,32,128 sbuf 0 0K - 2785 16,32,64,128,256,512,1024,2048,4096 stack 0 0K - 2 256 taskqueue 105 16K - 135 16,32,64,256,1024 Unitno 19 2K - 227 32,64 ioctlops 1 8K - 13701 16,32,64,128,256,512,1024,2048 select 34 5K - 34 128 iov 0 0K - 1301 16,64,128,256,512 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 11 40K - 22 2048 tty 19 19K - 21 1024,2048 mbuf_tag 0 0K - 58 32,128 shmfd 1 8K - 1 soname 7 1K - 697 16,32,128 pcb 38 8341K - 95 16,32,128,1024,2048 vfscache 1 16384K - 1 vfs_hash 1 8192K - 1 vnodes 1 1K - 1 256 mount 397 20K - 1897 16,32,64,128,256,512 vnodemarker 0 0K - 202 512 BPF 3 1K - 3 128 ifnet 4 7K - 4 128,2048 ifaddr 48 15K - 48 32,64,128,256,512,2048,4096 ether_multi 40 3K - 46 16,32,64 clone 6 1K - 6 128 arpcom 2 1K - 2 16 lltable 12 5K - 12 256,512 newnfsmnt 1 1K - 1 1024 pfs_nodes 21 6K - 21 256 pfs_vncache 76 5K - 81 64 GEOM 344 60K - 2226 16,32,64,128,256,512,1024,2048 routetbl 35 5K - 240 32,64,128,256,512 igmp 3 1K - 3 256 in_multi 2 1K - 2 256 ppbusdev 2 1K - 2 256 entropy 1024 64K - 1024 64 sctp_a_it 0 0K - 3 16 sctp_vrf 1 1K - 1 64 sctp_ifa 5 1K - 5 128 sctp_ifn 2 1K - 2 128 sctp_iter 0 0K - 3 256 hostcache 1 28K - 1 syncache 1 100K - 1 in6_mfilter 1 1K - 1 1024 in6_multi 22 3K - 22 32,256 ip6_moptions 2 1K - 2 32,256 CAM DEV 15 30K - 24 2048 UART 6 5K - 6 16,1024 mld 3 1K - 3 128 ata_pci 1 1K - 1 64 CAM CCB 13 26K - 101 2048 rpc 22 6K - 28 32,64,128,256,512,1024 audit_evclass 188 6K - 227 32 vm_pgdata 7 8193K - 7 128 UMAHash 1 1K - 1 512 raid_data 0 0K - 336 32,128,256 acpiintr 1 1K - 1 64 acpica 1830 187K - 57239 16,32,64,128,256,512,1024,2048 CAM path 22 1K - 68 32 CAM periph 16 4K - 41 16,32,64,128,256 acpitask 1 8K - 1 acpisem 21 3K - 21 128 CAM queue 39 2K - 133 16,32,64 memdesc 1 4K - 1 4096 acpidev 36 3K - 36 64 atkbddev 2 1K - 2 64 CAM dev queue 8 1K - 8 128 USB 38 41K - 40 16,32,64,128,256,512,1024,4096 md_nvidia_data 0 0K - 54 512 USBdev 30 6K - 40 64,128,512 md_sii_data 0 0K - 54 512 CAM SIM 8 2K - 8 256 CAM XPT 58 4K - 204 16,32,64,128,1024 kbdmux 7 18K - 7 16,512,1024,2048 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 LED 4 1K - 4 16,128 isadev 5 1K - 5 128 io_apic 2 4K - 2 2048 MCA 8 1K - 8 128 pci_link 16 2K - 16 32,64,128 msi 2 1K - 2 128 nexusdev 4 1K - 4 16 acpi_perf 8 1K - 8 64 scsi_cd 0 0K - 11 16 cdev 8 2K - 8 256 solaris 62374 344297K - 749641 16,32,64,128,256,512,1024,2048,4096 linux 36 2K - 36 32,64 cpuctl 1 1K - 9 64,4096 crypto 1 1K - 1 512 xform 0 0K - 206 16,32 cyclic 32 3K - 32 16,64,128 kstat_data 5 1K - 5 64 fbt 1 256K - 1 iprtheap 23 56K - 23 32,64,128,256,2048 fdesc_mount 1 1K - 1 16 netgraph_node 4 1K - 4 128,256 netgraph 2 1K - 2 64 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 254, 1, 254, 0, 0 UMA Zones: 1408, 0, 254, 0, 254, 0, 0 UMA Slabs: 568, 0, 16533, 120, 31690, 0, 0 UMA RCntSlabs: 568, 0, 1217, 1, 1217, 0, 0 UMA Hash: 256, 0, 82, 8, 83, 0, 0 16 Bucket: 152, 0, 391, 9, 391, 0, 0 32 Bucket: 280, 0, 317, 5, 317, 15, 0 64 Bucket: 536, 0, 358, 6, 358, 84, 0 128 Bucket: 1048, 0, 1365, 0, 1365,4185, 0 VM OBJECT: 240, 0, 3359, 257, 14724, 0, 0 RADIX NODE: 144, 16148184, 20410,16127826, 76441, 0, 0 MAP: 232, 0, 8, 24, 8, 0, 0 KMAP ENTRY: 120, 4230725, 255, 1233, 48042, 0, 0 MAP ENTRY: 120, 0, 1670, 407, 34695, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 283, 22, 283, 0, 0 16: 16, 0, 6, 1170, 8417, 0, 0 16: 16, 0, 3274, 758, 56874, 0, 0 16: 16, 0, 2, 166, 2, 0, 0 16: 16, 0, 87, 1089, 23969, 0, 0 16: 16, 0, 2339, 1021, 2911, 0, 0 16: 16, 0, 550, 962, 3590, 0, 0 16: 16, 0, 8, 832, 41, 0, 0 16: 16, 0, 62, 946, 270, 0, 0 32: 32, 0, 31, 878, 4358, 0, 0 32: 32, 0, 2152, 1989, 31736, 0, 0 32: 32, 0, 29, 577, 29, 0, 0 32: 32, 0, 122, 787, 4245, 0, 0 32: 32, 0, 2388, 945, 2665, 0, 0 32: 32, 0, 241, 971, 2379, 0, 0 32: 32, 0, 71, 838, 280, 0, 0 32: 32, 0, 200, 406, 329, 0, 0 64: 64, 0, 84, 476, 810, 0, 0 64: 64, 0, 24198, 3130, 222936, 0, 0 64: 64, 0, 1107, 517, 2080, 0, 0 64: 64, 0, 729, 559, 25092, 0, 0 64: 64, 0, 324, 460, 358, 0, 0 64: 64, 0, 8983, 873, 16224, 0, 0 64: 64, 0, 33, 135, 33, 0, 0 64: 64, 0, 65, 495, 237, 0, 0 128: 128, 0, 34, 198, 80, 0, 0 128: 128, 0, 9778, 1300, 81357, 0, 0 128: 128, 0, 85, 234, 100, 0, 0 128: 128, 0, 1220, 404, 2193, 0, 0 128: 128, 0, 2953, 585, 3025, 0, 0 128: 128, 0, 567, 361, 1209, 0, 0 128: 128, 0, 16, 100, 16, 0, 0 128: 128, 0, 80, 239, 427, 0, 0 256: 256, 0, 10, 20, 12, 0, 0 256: 256, 0, 2880, 3525, 105923, 0, 0 256: 256, 0, 490, 80, 783, 0, 0 256: 256, 0, 240, 75, 1045, 0, 0 256: 256, 0, 5, 70, 7, 0, 0 256: 256, 0, 302, 208, 4700, 0, 0 256: 256, 0, 22, 23, 22, 0, 0 256: 256, 0, 129, 216, 1507, 0, 0 512: 512, 0, 169, 41, 210, 0, 0 512: 512, 0, 10146, 347, 128131, 0, 0 512: 512, 0, 4, 59, 76, 0, 0 512: 512, 0, 217, 77, 1180, 0, 0 512: 512, 0, 12, 44, 120, 0, 0 512: 512, 0, 137, 136, 357, 0, 0 512: 512, 0, 0, 0, 0, 0, 0 512: 512, 0, 0, 252, 877, 0, 0 1024: 1024, 0, 2, 66, 84, 0, 0 1024: 1024, 0, 325, 187, 2938, 0, 0 1024: 1024, 0, 4, 4, 4, 0, 0 1024: 1024, 0, 6, 14, 1917, 0, 0 1024: 1024, 0, 19, 9, 19, 0, 0 1024: 1024, 0, 15, 321, 2674, 0, 0 1024: 1024, 0, 1, 7, 1, 0, 0 1024: 1024, 0, 13, 15, 164, 0, 0 2048: 2048, 0, 38, 96, 326, 0, 0 2048: 2048, 0, 411, 237, 4477, 0, 0 2048: 2048, 0, 0, 0, 0, 0, 0 2048: 2048, 0, 81, 133, 1080, 0, 0 2048: 2048, 0, 1, 7, 3, 0, 0 2048: 2048, 0, 23, 95, 170, 0, 0 2048: 2048, 0, 0, 0, 0, 0, 0 2048: 2048, 0, 0, 8, 65, 0, 0 4096: 4096, 0, 67, 100, 1038, 0, 0 4096: 4096, 0, 6394, 4781, 99018, 0, 0 4096: 4096, 0, 169, 100, 681, 0, 0 4096: 4096, 0, 24, 41, 28, 0, 0 4096: 4096, 0, 10, 44, 12, 0, 0 4096: 4096, 0, 27, 63, 7787, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 Files: 80, 0, 192, 393, 17327, 0, 0 TURNSTILE: 136, 0, 532, 108, 532, 0, 0 rl_entry: 40, 0, 75, 681, 75, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 73, 89, 1044, 0, 0 THREAD: 1168, 0, 425, 106, 587, 0, 0 SLEEPQUEUE: 80, 0, 532, 164, 532, 0, 0 VMSPACE: 392, 0, 46, 134, 1022, 0, 0 cpuset: 72, 0, 274, 326, 425, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1240, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 26520435, 1023, 1163, 1760, 0, 0 mbuf: 256, 26520435, 7, 1027, 1874, 0, 0 mbuf_cluster: 2048, 4143818, 2176, 230, 2176, 0, 0 mbuf_jumbo_page: 4096, 2071909, 0, 14, 7, 0, 0 mbuf_jumbo_9k: 9216, 1841694, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1381272, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 2, 538, 109938, 0, 0 ttyinq: 160, 0, 120, 144, 255, 0, 0 ttyoutq: 256, 0, 64, 101, 136, 0, 0 ata_request: 336, 0, 0, 143, 77, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 504, 92, 0, 0 VNODE: 472, 0, 9393, 279, 9518, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 128, 53101, 0, 0 S VFS Cache: 108, 0, 9441, 360, 11402, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 84, 132, 112, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 1, 13, 1, 0, 0 pipe: 744, 0, 12, 93, 553, 0, 0 space_seg_cache: 64, 0, 9593, 80007, 278530, 0, 0 zio_cache: 944, 0, 5, 7883, 318981, 0, 0 zio_link_cache: 48, 0, 3, 8709, 303395, 0, 0 zio_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_data_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_data_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_data_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_data_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_data_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_data_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_data_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_data_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_data_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_data_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_data_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_data_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_data_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_data_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_data_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_data_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_data_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_data_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_data_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_data_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_data_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_data_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_data_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_data_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_data_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_data_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_data_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 0, 0, 0, 0, 0 zio_data_buf_131072: 131072, 0, 0, 0, 0, 0, 0 sa_cache: 80, 0, 9194, 211, 9286, 0, 0 dnode_t: 856, 0, 9829, 335, 11053, 0, 0 dmu_buf_impl_t: 224, 0, 17993, 384, 21797, 0, 0 arc_buf_hdr_t: 216, 0, 11850, 264, 12999, 0, 0 arc_buf_t: 72, 0, 10407, 443, 14007, 0, 0 zil_lwb_cache: 192, 0, 4, 176, 56, 0, 0 zfs_znode_cache: 368, 0, 9194, 226, 9286, 0, 0 Mountpoints: 816, 0, 30, 25, 30, 0, 0 ksiginfo: 112, 0, 313, 842, 3205, 0, 0 itimer: 352, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 6, 226, 67, 0, 0 socket: 680, 2071914, 57, 93, 480, 0, 0 unpcb: 240, 2071920, 11, 165, 114, 0, 0 ipq: 56, 129528, 0, 0, 0, 0, 0 udp_inpcb: 392, 2071920, 21, 99, 324, 0, 0 udpcb: 16, 2071944, 21, 1155, 324, 0, 0 tcp_inpcb: 392, 2071920, 24, 96, 36, 0, 0 tcpcb: 1016, 2071916, 24, 44, 36, 0, 0 tcptw: 72, 27800, 0, 100, 2, 0, 0 syncache: 152, 15375, 0, 50, 1, 0, 0 hostcache: 136, 15372, 0, 0, 0, 0, 0 tcpreass: 40, 259056, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1408, 2071914, 0, 0, 0, 0, 0 sctp_asoc: 2344, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 288, 4, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400032, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 2071920, 0, 0, 0, 0, 0 rtentry: 200, 0, 17, 135, 17, 0, 0 selfd: 56, 0, 83, 484, 5931, 0, 0 SWAPMETA: 288, 8074092, 0, 0, 0, 0, 0 NetGraph items: 72, 4118, 0, 0, 0, 0, 0 NetGraph data items: 72, 522, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 2 0 irq6: fdc0 22 0 irq14: ata0 131 0 irq17: uhci0 ehci0 371 1 irq19: uhci1 ahci0+ 35224 136 cpu0:timer 21581 83 irq256: em0 1240 4 cpu7:timer 18860 72 cpu1:timer 17194 66 cpu2:timer 22448 86 cpu3:timer 17242 66 cpu4:timer 21918 84 cpu6:timer 19999 77 cpu5:timer 20715 79 Total 196947 760 ------------------------------------------------------------------------ pstat -T 192/2071909 files 0M/147455M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/gpt/swap0 50331392 0 50331392 0% /dev/gpt/swap1 50331392 0 50331392 0% /dev/gpt/swap2 50331392 0 50331392 0% /dev/gpt/swap3 50331392 0 50331392 0% /dev/gpt/swap4 50331392 0 50331392 0% /dev/gpt/swap5 50331392 0 50331392 0% Total 301988352 0 301988352 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 ada1 ada2 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 14.49 24 0.33 14.56 23 0.32 14.28 24 0.33 0 10 2 0 88 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME m 65536 5432001 --rw------- pgsql pgsql pgsql pgsql 4 41263104 899 899 8:44:47 8:45:50 8:44:47 m 65537 28975112 --rw-rw-rw- boinc nobody boinc nobody 2 8192 944 1028 8:45:34 8:45:34 8:45:33 m 65538 28975113 --rw-rw-rw- boinc nobody boinc nobody 2 8192 944 1029 8:45:34 8:45:34 8:45:33 m 65539 28975114 --rw-rw-rw- boinc nobody boinc nobody 2 8192 944 1030 8:45:34 8:45:34 8:45:33 m 65540 28975115 --rw-rw-rw- boinc nobody boinc nobody 2 8192 944 1032 8:45:34 8:45:34 8:45:34 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME s 65536 5432001 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65537 5432002 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65538 5432003 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65539 5432004 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65540 5432005 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65541 5432006 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65542 5432007 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 2 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 1 1 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 4 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 541 packets sent 224 data packets (18558 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 308 ack-only packets (123 delayed) 0 URG only packets 0 window probe packets 0 window update packets 9 control packets 541 packets received 208 acks (for 17554 bytes) 3 duplicate acks 0 acks for unsent data 511 packets (432616 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 1 window update packet 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 6 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 7 connections established (including accepts) 12 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 208 segments updated rtt (of 178 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 7 correct ACK header predictions 318 correct data packet header predictions 1 syncache entry added 0 retransmitted 0 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 120 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 26 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 94 delivered 95 datagrams output 0 times multicast source filter matched ip: 612 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 610 packets for this host 2 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 585 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 2 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 1 V1/V2 membership query received 0 V3 membership queries received 0 membership queries received with invalid field(s) 1 general query received 0 group queries received 0 group-source queries received 0 group-source queries dropped 1 membership report received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 4 ARP requests sent 3 ARP replies sent 40 ARP requests received 2 ARP replies received 42 ARP packets received 1 total packet dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 51 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 51 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 58 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 9 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Input histogram: UDP: 51 Mbuf statistics: 27 one mbuf 24 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: neighbor solicitation: 1 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 1030/2190/3220 mbufs in use (current/cache/total) 1013/1393/2406/4143818 mbuf clusters in use (current/cache/total/max) 1023/1163 mbuf+clusters out of packet secondary zone in use (current/cache) 0/14/14/2071909 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/1841694 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1381272 16k jumbo clusters in use (current/cache/total/max) 2283K/3389K/5673K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:30:48:f2:29:9c 654 0 0 591 0 0 0 em0 1500 192.168.200.0 borg 588 - - 585 - - - em0 1500 fe80::230:48f fe80::230:48ff:fe 0 - - 4 - - - em1* 1500 00:30:48:f2:29:9d 0 0 0 0 0 0 0 lo0 16384 51 0 0 51 0 0 0 lo0 16384 localhost ::1 51 - - 51 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 0 - - 0 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.200.11 UGS 0 560 em0 127.0.0.1 link#3 UH 0 0 lo0 192.168.200.0/24 link#1 U 0 25 em0 192.168.200.4 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#3 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#1 U em0 fe80::230:48ff:fef2:299c%em0 link#1 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01::%em0/32 fe80::230:48ff:fef2:299c%em0 U em0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 fe80::230:48ff:fef2:299c%em0 U em0 ff02::%lo0/32 ::1 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) fffffe01c28423f8 tcp4 0 1008 192.168.200.4.22 192.147.25.65.4400 ESTABLISHED fffffe01038a5000 tcp4 0 0 192.168.200.4.1391 198.20.8.246.80 CLOSE_WAIT fffffe01c2272be8 tcp4 0 0 127.0.0.1.31416 *.* LISTEN fffffe01d5855be8 tcp4 0 0 192.168.200.4.1551 192.147.25.65.22 ESTABLISHED fffffe01c28427f0 tcp4 0 0 *.9101 *.* LISTEN fffffe010370f7f0 tcp4 0 0 *.22 *.* LISTEN fffffe010370fbe8 tcp6 0 0 *.22 *.* LISTEN fffffe010381dbe8 tcp4 0 0 *.9102 *.* LISTEN fffffe01c2273000 tcp4 0 0 *.9103 *.* LISTEN fffffe0103a3bbe8 tcp4 0 0 *.631 *.* LISTEN fffffe0103a3c000 tcp6 0 0 *.631 *.* LISTEN fffffe010381a000 tcp4 0 0 127.0.0.1.587 *.* LISTEN fffffe010381a3f8 tcp4 0 0 127.0.0.1.25 *.* LISTEN fffffe010381a7f0 tcp4 0 0 192.168.200.4.587 *.* LISTEN fffffe010381abe8 tcp4 0 0 192.168.200.4.25 *.* LISTEN fffffe010370e7f0 tcp4 0 0 127.0.0.1.5432 *.* LISTEN fffffe010370e000 tcp6 0 0 ::1.5432 *.* LISTEN fffffe01038a7000 tcp6 0 0 *.2049 *.* LISTEN fffffe01038a73f8 tcp4 0 0 *.2049 *.* LISTEN fffffe010381b000 tcp4 0 0 *.843 *.* LISTEN fffffe010381b3f8 tcp6 0 0 *.843 *.* LISTEN fffffe010381d3f8 tcp4 0 0 *.111 *.* LISTEN fffffe010381d7f0 tcp6 0 0 *.111 *.* LISTEN fffffe010370e3f8 tcp4 0 0 192.168.200.4.952 192.168.200.23.204 ESTABLISHED fffffe010313bdc8 udp4 0 0 *.69 *.* fffffe0103106930 udp4 0 0 *.631 *.* fffffe0103131ab8 udp6 0 0 ::1.47400 ::1.47400 fffffe0103199930 udp4 0 0 127.0.0.1.123 *.* fffffe010319a188 udp6 0 0 fe80:3::1.123 *.* fffffe010319a620 udp6 0 0 ::1.123 *.* fffffe010319a310 udp6 0 0 fe80:1::230:48ff.1 *.* fffffe010319a000 udp4 0 0 192.168.200.4.123 *.* fffffe0103199dc8 udp6 0 0 *.123 *.* fffffe0103199ab8 udp4 0 0 *.123 *.* fffffe0103199000 udp6 0 0 *.2049 *.* fffffe0103199498 udp4 0 0 *.2049 *.* fffffe0103197930 udp4 0 0 *.843 *.* fffffe0103197620 udp6 0 0 *.843 *.* fffffe0103199c40 udp6 0 0 *.* *.* fffffe010314cab8 udp4 0 0 *.1009 *.* fffffe010314c7a8 udp4 0 0 *.111 *.* fffffe010314c498 udp6 0 0 *.998 *.* fffffe010314c188 udp6 0 0 *.111 *.* fffffe0103197310 udp4 0 0 *.514 *.* fffffe0103197498 udp6 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe0103a5b870 stream 0 0 fffffe01c22c71d8 0 0 0 /var/run/cups.sock fffffe010349ed20 stream 0 0 fffffe0103e66588 0 0 0 /tmp/.s.PGSQL.5432 fffffe01034a60f0 stream 0 0 fffffe0103457938 0 0 0 /var/run/rpcbind.sock fffffe01034a63c0 stream 0 0 fffffe01034981d8 0 0 0 /var/run/devd.pipe fffffe0103a5b780 dgram 0 0 0 fffffe0103517b40 0 fffffe010349b0f0 fffffe01035174b0 dgram 0 0 0 fffffe0103517c30 0 fffffe010349dc30 fffffe010349dc30 dgram 0 0 0 fffffe0103517c30 0 fffffe0103a5b960 fffffe0103a5b960 dgram 0 0 0 fffffe0103517c30 0 0 fffffe010349b0f0 dgram 0 0 0 fffffe0103517b40 0 0 fffffe0103517b40 dgram 0 0 fffffe01037f1000 0 fffffe0103a5b780 0 /var/run/logpriv fffffe0103517c30 dgram 0 0 fffffe00c0b14ce8 0 fffffe01035174b0 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 localhost.31416 tcp4 0/0/50 *.bacula-dir tcp4 0/0/128 *.ssh tcp6 0/0/128 *.ssh tcp4 0/0/50 *.bacula-fd tcp4 0/0/50 *.bacula-sd tcp4 0/0/128 *.ipp tcp6 0/0/128 *.ipp tcp4 0/0/20 localhost.submission tcp4 0/0/20 localhost.smtp tcp4 0/0/20 borg.submission tcp4 0/0/20 borg.smtp tcp4 0/0/128 localhost.postgresql tcp6 0/0/128 localhost.postgresql tcp6 0/0/5 *.nfsd tcp4 0/0/5 *.nfsd tcp4 0/0/128 *.843 tcp6 0/0/128 *.843 tcp4 0/0/128 *.sunrpc tcp6 0/0/128 *.sunrpc unix 0/0/128 /var/run/cups.sock unix 0/0/128 /tmp/.s.PGSQL.5432 unix 0/0/128 /var/run/rpcbind.sock unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read file 13 at 0xfffffffffffffff fstat: can't read file 14 at 0x78 fstat: can't read file 16 at 0xffff fstat: can't read file 19 at 0xfffffffffffffff fstat: can't read file 20 at 0x78 fstat: can't read file 22 at 0xffff fstat: can't read file 23 at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read file 13 at 0xfffffffffffffff fstat: can't read file 14 at 0x78 fstat: can't read file 16 at 0xffff fstat: can't read file 19 at 0xfffffffffffffff fstat: can't read file 20 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root zfs 1044 root - - error - root zfs 1044 wd - - error - root zfs 1044 text - - error - root zfs 1044 0* pipe fffffe00c0d6f000 <-> fffffe00c0d6f160 65224 rw root zfs 1044 6* pipe fffffe00c0d97730 <-> fffffe00c0d975d0 0 rw root csh 1042 root - - error - root csh 1042 wd - - error - root csh 1042 text - - error - root sshd 1040 root - - error - root sshd 1040 wd - - error - root sshd 1040 text - - error - root sshd 1040 0 /dev 28 crw-rw-rw- null rw root sshd 1040 6 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1038 root - - error - boinc wcg_hpf2_rosetta_6 1038 wd - - error - boinc wcg_hpf2_rosetta_6 1038 text - - error - boinc wcg_hpf2_rosetta_6 1038 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1038 6 - - error - boinc wcg_hpf2_rosetta_6 1037 root - - error - boinc wcg_hpf2_rosetta_6 1037 wd - - error - boinc wcg_hpf2_rosetta_6 1037 text - - error - boinc wcg_hpf2_rosetta_6 1037 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1037 6 - - error - boinc wcg_hpf2_rosetta_6 1036 root - - error - boinc wcg_hpf2_rosetta_6 1036 wd - - error - boinc wcg_hpf2_rosetta_6 1036 text - - error - boinc wcg_hpf2_rosetta_6 1036 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1036 6 - - error - boinc wcg_hpf2_rosetta_6 1035 root - - error - boinc wcg_hpf2_rosetta_6 1035 wd - - error - boinc wcg_hpf2_rosetta_6 1035 text - - error - boinc wcg_hpf2_rosetta_6 1035 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1035 6 - - error - boinc wcgrid_cep2_6.40_i 1034 root - - error - boinc wcgrid_cep2_6.40_i 1034 wd - - error - boinc wcgrid_cep2_6.40_i 1034 text - - error - boinc wcgrid_cep2_6.40_i 1034 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1034 6 - - error - boinc wcgrid_cep2_6.40_i 1033 root - - error - boinc wcgrid_cep2_6.40_i 1033 wd - - error - boinc wcgrid_cep2_6.40_i 1033 text - - error - boinc wcgrid_cep2_6.40_i 1033 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1033 6 - - error - boinc setiathome-6.12.am 1032 root - - error - boinc setiathome-6.12.am 1032 wd - - error - boinc setiathome-6.12.am 1032 text - - error - boinc setiathome-6.12.am 1032 0 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1032 6 /dev 28 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1031 root - - error - boinc wcgrid_faah_7.15_i 1031 wd - - error - boinc wcgrid_faah_7.15_i 1031 text - - error - boinc wcgrid_faah_7.15_i 1031 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1031 6 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1030 root - - error - boinc setiathome-6.12.am 1030 wd - - error - boinc setiathome-6.12.am 1030 text - - error - boinc setiathome-6.12.am 1030 0 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1030 6 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1029 root - - error - boinc setiathome-6.12.am 1029 wd - - error - boinc setiathome-6.12.am 1029 text - - error - boinc setiathome-6.12.am 1029 0 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1029 6 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1028 root - - error - boinc setiathome-6.12.am 1028 wd - - error - boinc setiathome-6.12.am 1028 text - - error - boinc setiathome-6.12.am 1028 0 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1028 6 /dev 28 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1027 root - - error - boinc wcgrid_cep2_6.40_i 1027 wd - - error - boinc wcgrid_cep2_6.40_i 1027 text - - error - boinc wcgrid_cep2_6.40_i 1027 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1027 6 - - error - boinc wcgrid_faah_7.15_i 1026 root - - error - boinc wcgrid_faah_7.15_i 1026 wd - - error - boinc wcgrid_faah_7.15_i 1026 text - - error - boinc wcgrid_faah_7.15_i 1026 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1026 6 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1025 root - - error - boinc wcg_hpf2_rosetta_6 1025 wd - - error - boinc wcg_hpf2_rosetta_6 1025 text - - error - boinc wcg_hpf2_rosetta_6 1025 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1025 6 - - error - boinc wcg_hpf2_rosetta_6 1024 root - - error - boinc wcg_hpf2_rosetta_6 1024 wd - - error - boinc wcg_hpf2_rosetta_6 1024 text - - error - boinc wcg_hpf2_rosetta_6 1024 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1024 6 - - error - root ssh 1022 root - - error - root ssh 1022 wd - - error - root ssh 1022 text - - error - root ssh 1022 ctty /dev 71 crw------- ttyv0 rw root ssh 1022 0 /dev 71 crw------- ttyv0 rw root ssh 1022 6 /dev 71 crw------- ttyv0 rw root sh 1020 root - - error - root sh 1020 wd - - error - root sh 1020 text - - error - root sh 1020 ctty /dev 71 crw------- ttyv0 rw root sh 1020 0 /dev 71 crw------- ttyv0 rw root sh 1020 6 /dev 71 crw------- ttyv0 rw root getty 1017 root - - error - root getty 1017 wd - - error - root getty 1017 text - - error - root getty 1017 ctty /dev 78 crw------- ttyv7 rw root getty 1017 0 /dev 78 crw------- ttyv7 rw root getty 1016 root - - error - root getty 1016 wd - - error - root getty 1016 text - - error - root getty 1016 ctty /dev 77 crw------- ttyv6 rw root getty 1016 0 /dev 77 crw------- ttyv6 rw root getty 1015 root - - error - root getty 1015 wd - - error - root getty 1015 text - - error - root getty 1015 ctty /dev 76 crw------- ttyv5 rw root getty 1015 0 /dev 76 crw------- ttyv5 rw root getty 1014 root - - error - root getty 1014 wd - - error - root getty 1014 text - - error - root getty 1014 ctty /dev 75 crw------- ttyv4 rw root getty 1014 0 /dev 75 crw------- ttyv4 rw root getty 1013 root - - error - root getty 1013 wd - - error - root getty 1013 text - - error - root getty 1013 ctty /dev 74 crw------- ttyv3 rw root getty 1013 0 /dev 74 crw------- ttyv3 rw root getty 1012 root - - error - root getty 1012 wd - - error - root getty 1012 text - - error - root getty 1012 ctty /dev 73 crw------- ttyv2 rw root getty 1012 0 /dev 73 crw------- ttyv2 rw root getty 1011 root - - error - root getty 1011 wd - - error - root getty 1011 text - - error - root getty 1011 ctty /dev 72 crw------- ttyv1 rw root getty 1011 0 /dev 72 crw------- ttyv1 rw root login 1010 root - - error - root login 1010 wd - - error - root login 1010 text - - error - root login 1010 ctty /dev 71 crw------- ttyv0 rw root login 1010 0 /dev 71 crw------- ttyv0 rw root inetd 990 root - - error - root inetd 990 wd - - error - root inetd 990 text - - error - root inetd 990 0 /dev 28 crw-rw-rw- null rw root inetd 990 6 /dev 28 crw-rw-rw- null rw root cron 969 root - - error - root cron 969 wd - - error - root cron 969 text - - error - root cron 969 0 /dev 28 crw-rw-rw- null rw root sshd 959 root - - error - root sshd 959 wd - - error - root sshd 959 text - - error - root sshd 959 0 /dev 28 crw-rw-rw- null rw bacula bacula-dir 954 root - - error - bacula bacula-dir 954 wd - - error - bacula bacula-dir 954 text - - error - bacula bacula-dir 954 0 /dev 28 crw-rw-rw- null r root bacula-fd 951 root - - error - root bacula-fd 951 wd - - error - root bacula-fd 951 text - - error - root bacula-fd 951 0 /dev 28 crw-rw-rw- null r bacula bacula-sd 948 root - - error - bacula bacula-sd 948 wd - - error - bacula bacula-sd 948 text - - error - bacula bacula-sd 948 0 /dev 28 crw-rw-rw- null r boinc boinc_client 944 root - - error - boinc boinc_client 944 wd - - error - boinc boinc_client 944 text - - error - boinc boinc_client 944 0 /dev 28 crw-rw-rw- null rw boinc boinc_client 944 6 - - error - root cupsd 938 root - - error - root cupsd 938 wd - - error - root cupsd 938 text - - error - root cupsd 938 0 /dev 28 crw-rw-rw- null r root cupsd 938 6 /dev 28 crw-rw-rw- null w root cupsd 938 12 /dev 28 crw-rw-rw- null w mailnull exim-4.80.1-2 928 root - - error - mailnull exim-4.80.1-2 928 wd - - error - mailnull exim-4.80.1-2 928 text - - error - mailnull exim-4.80.1-2 928 0 /dev 28 crw-rw-rw- null rw mailnull exim-4.80.1-2 928 6 /dev 28 crw-rw-rw- null rw pgsql postgres 906 root - - error - pgsql postgres 906 wd - - error - pgsql postgres 906 text - - error - pgsql postgres 906 0 /dev 28 crw-rw-rw- null r pgsql postgres 906 6 - - error - pgsql postgres 905 root - - error - pgsql postgres 905 wd - - error - pgsql postgres 905 text - - error - pgsql postgres 905 0 /dev 28 crw-rw-rw- null r pgsql postgres 905 6 - - error - pgsql postgres 904 root - - error - pgsql postgres 904 wd - - error - pgsql postgres 904 text - - error - pgsql postgres 904 0 /dev 28 crw-rw-rw- null r pgsql postgres 904 6 - - error - pgsql postgres 903 root - - error - pgsql postgres 903 wd - - error - pgsql postgres 903 text - - error - pgsql postgres 903 0 /dev 28 crw-rw-rw- null r pgsql postgres 903 6 - - error - pgsql postgres 899 root - - error - pgsql postgres 899 wd - - error - pgsql postgres 899 text - - error - pgsql postgres 899 0 /dev 28 crw-rw-rw- null r pgsql postgres 899 6 - - error - root smartd 890 root - - error - root smartd 890 wd - - error - root smartd 890 text - - error - root smartd 890 0 /dev 28 crw-rw-rw- null rw root perl 886 root - - error - root perl 886 wd - - error - root perl 886 text - - error - root perl 886 0 - - error - root ng_queue 874 root - - error - root ng_queue 874 wd - - error - root ntpd 853 root - - error - root ntpd 853 wd - - error - root ntpd 853 text - - error - root ntpd 853 0 /dev 28 crw-rw-rw- null rw root ntpd 853 6 /dev 28 crw-rw-rw- null rw root ntpd 853 12 /dev 28 crw-rw-rw- null rw root ntpd 853 18* local dgram fffffe010349b0f0 <-> fffffe0103517b40 root nfsd 817 root - - error - root nfsd 817 wd - - error - root nfsd 817 text - - error - root nfsd 817 0 /dev 28 crw-rw-rw- null rw root nfsd 815 root - - error - root nfsd 815 wd - - error - root nfsd 815 text - - error - root nfsd 815 0 /dev 28 crw-rw-rw- null rw root nfsd 815 6 /dev 28 crw-rw-rw- null rw root mountd 809 root - - error - root mountd 809 wd - - error - root mountd 809 text - - error - root mountd 809 0 /dev 28 crw-rw-rw- null rw root mountd 809 6 /dev 28 crw-rw-rw- null rw root rpcbind 774 root - - error - root rpcbind 774 wd - - error - root rpcbind 774 text - - error - root rpcbind 774 0 /dev 28 crw-rw-rw- null rw root rpcbind 774 6 /dev 28 crw-rw-rw- null rw root watchdogd 760 root - - error - root watchdogd 760 wd - - error - root watchdogd 760 text - - error - root watchdogd 760 0 /dev 28 crw-rw-rw- null rw root syslogd 757 root - - error - root syslogd 757 wd - - error - root syslogd 757 text - - error - root syslogd 757 0 /dev 28 crw-rw-rw- null rw root syslogd 757 6 /dev 28 crw-rw-rw- null rw root syslogd 757 12 /dev 28 crw-rw-rw- null rw root syslogd 757 18 - - error - root devd 632 root - - error - root devd 632 wd - - error - root devd 632 text - - error - root devd 632 0 /dev 28 crw-rw-rw- null rw root init 1 root - - error - root init 1 wd - - error - root init 1 text - - error - root kernel 0 root - - error - root kernel 0 wd - - error - ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #129 r248695: Mon Mar 25 05:03:32 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.54-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 63193878528 (60266 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 netmap: loaded module cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd8020000-0xd803ffff,0xd8000000-0xd801ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c 001.000008 netmap_attach [1680] success for em0 em1: port 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d 001.000009 netmap_attach [1680] success for em1 pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd8500400-0xd85007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib11: at device 30.0 on pci0 pci11: on pcib11 vgapci0: port 0x3000-0x30ff mem 0xd0000000-0xd7ffffff,0xd8200000-0xd820ffff irq 18 at device 1.0 on pci11 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd8500800-0xd8500bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x40c offMax=0x58d usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ugen3.1: at usbus3 uhub2: on usbus3 ugen2.1: at usbus2 uhub3: on usbus2 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #7 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 uhub2: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ffclock reset: HPET (14318180 Hz), time = 1364219053.500000000 Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. Setting hostid: 0xf53a926e. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: Mounting local file systems:. Writing entropy file:. Setting hostname: borg.lerctr.org. Starting Network: lo0 em0 em1. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 em0: flags=8843 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9c inet 192.168.200.4 netmask 0xffffff00 broadcast 192.168.200.255 inet6 fe80::230:48ff:fef2:299c%em0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect status: no carrier em1: flags=8c02 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9d nd6 options=29 media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=8c02 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9d nd6 options=29 media: Ethernet autoselect status: no carrier uhid0: on usbus3 add net default: gateway 192.168.200.11 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Mounting NFS file systems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/kde4/lib /usr/local/lib/compat /usr/local/lib/dbmail /usr/local/lib/event2 /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/virtualbox 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat Creating and/or trimming log files. Starting syslogd. Starting watchdogd. No core dumps found. Additional ABI support: linux. Starting rpcbind. NFS access cache time=60 Clearing /tmp (X related). Starting mountd. NFSv4 is disabled Starting nfsd. Updating motd:. Starting ntpd. Starting sshblock. Starting smartd. Updating cpucodes... /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl0 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl1 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl2 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl3 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl4 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl5 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl6 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl7 from rev 0x60c to rev 0x60f... done. Done. Starting exim. Starting cupsd. Starting boinc_client. Starting bacula_sd. Starting bacula_fd. Starting bacula_dir. Performing sanity check on sshd configuration. Starting sshd. Configuring syscons: blanktime. Starting cron. Starting inetd. Starting background file system checks in 60 seconds. Mon Mar 25 08:44:56 CDT 2013 Mar 25 08:45:03 borg login: ROOT LOGIN (root) ON ttyv0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x378 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80531426 stack pointer = 0x28:0xffffff91579193d0 frame pointer = 0x28:0xffffff9157919470 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1044 (zfs) trap number = 12 panic: page fault cpuid = 0 Uptime: 2m10s Dumping 4913 out of 64747 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident BORG-DTRACE machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options FFCLOCK options USB_DEBUG options RDRAND_RNG options PADLOCK_RNG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options CTL_DISABLE options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options MALLOC_DEBUG_MAXZONES=8 options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options QUOTA options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device esp device isci device scbus device ch device da device sa device cd device pass device ses device ctl device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device uart device ppc device ppbus device lpt device ppi device em device miibus device cas device gem device hme device nfe device nge device loop device random device ether device vlan device tun device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device netmap ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 19:01:57 2013 Return-Path: Delivered-To: freebsd-current@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 10010D50; Mon, 1 Apr 2013 19:01:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id E337D9C7; Mon, 1 Apr 2013 19:01:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 47BFAB960; Mon, 1 Apr 2013 15:01:56 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: rc.subr: disabling globbing while processing devfs rules Date: Mon, 1 Apr 2013 14:06:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <514D6AC5.8010409@FreeBSD.org> In-Reply-To: <514D6AC5.8010409@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304011406.50417.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 15:01:56 -0400 (EDT) Cc: freebsd-rc@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:01:57 -0000 On Saturday, March 23, 2013 4:41:41 am Andriy Gapon wrote: > > Any objections / concerns for the following change? > > An example. > This rule in devfs.rules: > add path da* mode 660 group operator > and this directory: > /data > result in the following rule being actually installed: > 100 path data group operator mode 660 > > Of course, I could refine the pattern in the rule, but I shouldn't have to do > it, because the pattern is for /dev/ entries, not arbitrary files in the > filesystem namespace. > > commit 7ce5e9ca5c107e2669f18efa472c1ab14999247c > Author: Andriy Gapon > Date: Sat Mar 23 10:29:39 2013 +0200 > > rc.subr: disabling globbing while processing devfs rules in > devfs_rulesets_from_file() > > The rules themselves typically have shell-like patterns and it is incorrect > when they get replaced with matching filesystem entries. > > Shell magic by: jilles > > diff --git a/etc/rc.subr b/etc/rc.subr > index f37ede7..9952c82 100644 > --- a/etc/rc.subr > +++ b/etc/rc.subr > @@ -1301,7 +1301,7 @@ make_symlink() > # > devfs_rulesets_from_file() > { > - local file _err _me > + local file _err _me _opts > file="$1" > _me="devfs_rulesets_from_file" > _err=0 > @@ -1314,6 +1314,11 @@ devfs_rulesets_from_file() > debug "$_me: no such file ($file)" > return 0 > fi > + > + # Disable globbing so that the rule patterns are not expanded > + # by accident with matching filesystem entries. > + _opts=$-; set -f > + > debug "reading rulesets from file ($file)" > { while read line > do > @@ -1360,6 +1365,7 @@ devfs_rulesets_from_file() > break > fi > done } < $file > + case $_opts in *f*) ;; *) set +f ;; esac > return $_err > } Why not use 'local -' instead of the $- magic? That is: devfs_rulesets_from_file() { local file _err _me - ... set -f ... } That would seem to be simpler. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 19:56:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A1A4B81D; Mon, 1 Apr 2013 19:56:20 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1AAD4D; Mon, 1 Apr 2013 19:56:20 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id B17BE1203CC; Mon, 1 Apr 2013 21:56:04 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 82D3B2848C; Mon, 1 Apr 2013 21:56:01 +0200 (CEST) Date: Mon, 1 Apr 2013 21:56:01 +0200 From: Jilles Tjoelker To: John Baldwin Subject: Re: rc.subr: disabling globbing while processing devfs rules Message-ID: <20130401195601.GA47384@stack.nl> References: <514D6AC5.8010409@FreeBSD.org> <201304011406.50417.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201304011406.50417.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-rc@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:56:20 -0000 On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote: > Why not use 'local -' instead of the $- magic? That is: > devfs_rulesets_from_file() > { > local file _err _me - > > ... > set -f > ... > } > That would seem to be simpler. I had mentioned this possibility on IRC, but this feature is specific to Almquist-derived shells (ash) and so something more portable was selected. (It's still not standard because POSIX does not specify "local" but it works on most shells in use.) -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 20:12:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0164B8 for ; Mon, 1 Apr 2013 20:12:52 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9406CE0A for ; Mon, 1 Apr 2013 20:12:52 +0000 (UTC) Received: from outgoing.leidinger.net (p5DD45F3A.dip.t-dialin.net [93.212.95.58]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 83B0C8446AA; Mon, 1 Apr 2013 22:04:02 +0200 (CEST) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id 08E461384; Mon, 1 Apr 2013 22:04:00 +0200 (CEST) Date: Mon, 1 Apr 2013 14:36:52 +0200 From: Alexander Leidinger To: "J.R. Oldroyd" Subject: Re: DTrace of radeonkms on 9.1 Message-ID: <20130401143652.00001870@unknown> In-Reply-To: <20130327180714.5beae7d6@shibato> References: <20130327180714.5beae7d6@shibato> X-Mailer: Claws Mail 3.9.0cvs12 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 83B0C8446AA.A3CF5 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.691, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.86, DATE_IN_PAST_06_12 1.10, TW_KM 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1365451443.20069@oS9ez27gD23DOTeQYLRwTg X-EBL-Spam-Status: No Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:12:52 -0000 On Wed, 27 Mar 2013 18:07:14 -0400 "J.R. Oldroyd" wrote: > Is there any known magic involved in getting DTrace to do its thing on > 9.1-release? > > I am trying to use it to debug a memory leak problem with the > radeonkms driver under 9.x. Can you check if you have the same dtrace-problem with -current? I would expect that 9.1 already has some dtrace-fixes regarding new probes in run-time loaded modules, this is just to verify this assumption. Assuming there is some kind of dead-lock in this module-load interaction with dtrace, you could modify the radeonkms module to do it's initialization magic once a sysctl is set to 1, instead of doing this magic at module-load time. This way you could load the module, start the dtrace script and then issue the magic sysctl. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 20:17:05 2013 Return-Path: Delivered-To: freebsd-current@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 0A6C01F7; Mon, 1 Apr 2013 20:17:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id DC422E34; Mon, 1 Apr 2013 20:17:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EF67EB977; Mon, 1 Apr 2013 16:17:03 -0400 (EDT) From: John Baldwin To: Jilles Tjoelker Subject: Re: rc.subr: disabling globbing while processing devfs rules Date: Mon, 1 Apr 2013 16:16:15 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <514D6AC5.8010409@FreeBSD.org> <201304011406.50417.jhb@freebsd.org> <20130401195601.GA47384@stack.nl> In-Reply-To: <20130401195601.GA47384@stack.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304011616.15191.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Apr 2013 16:17:04 -0400 (EDT) Cc: freebsd-current@freebsd.org, freebsd-rc@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:17:05 -0000 On Monday, April 01, 2013 3:56:01 pm Jilles Tjoelker wrote: > On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote: > > Why not use 'local -' instead of the $- magic? That is: > > > devfs_rulesets_from_file() > > { > > local file _err _me - > > > > ... > > set -f > > ... > > } > > > That would seem to be simpler. > > I had mentioned this possibility on IRC, but this feature is specific to > Almquist-derived shells (ash) and so something more portable was > selected. (It's still not standard because POSIX does not specify > "local" but it works on most shells in use.) rc.subr isn't meant to be portable, it's a script that is part of the FreeBSD base system. I find the 'local -' syntax more readable (and used the feature quite a bit in etcupdate). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 20:30:18 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF5EE76D; Mon, 1 Apr 2013 20:30:18 +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 D085BEF3; Mon, 1 Apr 2013 20:30:16 +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 XAA28419; Mon, 01 Apr 2013 23:30:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UMlMt-0006Ta-0F; Mon, 01 Apr 2013 23:30:15 +0300 Message-ID: <5159EE54.8070906@FreeBSD.org> Date: Mon, 01 Apr 2013 23:30:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Baldwin Subject: Re: rc.subr: disabling globbing while processing devfs rules References: <514D6AC5.8010409@FreeBSD.org> <201304011406.50417.jhb@freebsd.org> <20130401195601.GA47384@stack.nl> <201304011616.15191.jhb@freebsd.org> In-Reply-To: <201304011616.15191.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org, Jilles Tjoelker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:30:19 -0000 on 01/04/2013 23:16 John Baldwin said the following: > On Monday, April 01, 2013 3:56:01 pm Jilles Tjoelker wrote: >> On Mon, Apr 01, 2013 at 02:06:50PM -0400, John Baldwin wrote: >>> Why not use 'local -' instead of the $- magic? That is: >> >>> devfs_rulesets_from_file() >>> { >>> local file _err _me - >>> >>> ... >>> set -f >>> ... >>> } >> >>> That would seem to be simpler. >> >> I had mentioned this possibility on IRC, but this feature is specific to >> Almquist-derived shells (ash) and so something more portable was >> selected. (It's still not standard because POSIX does not specify >> "local" but it works on most shells in use.) > > rc.subr isn't meant to be portable, it's a script that is part of the FreeBSD > base system. I find the 'local -' syntax more readable (and used the feature > quite a bit in etcupdate). > You have to set an example in etc/ :-) I used a script in etc/rc.d as a starting point, Jilles guided me from there. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 20:33:48 2013 Return-Path: Delivered-To: freebsd-current@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 9E68C8E8; Mon, 1 Apr 2013 20:33:48 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id 61904F24; Mon, 1 Apr 2013 20:33:48 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 4FE9F33B17; Mon, 1 Apr 2013 22:33:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id cNUY_opO7ciw; Mon, 1 Apr 2013 22:33:45 +0200 (CEST) Received: from [10.9.8.1] (chello085216226145.chello.sk [85.216.226.145]) by mail.vx.sk (Postfix) with ESMTPSA id 5527333B0E; Mon, 1 Apr 2013 22:33:44 +0200 (CEST) Message-ID: <5159EF29.6000503@FreeBSD.org> Date: Mon, 01 Apr 2013 22:33:45 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Larry Rosenman Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:33:48 -0000 This error seems to be limited to sending deduplicated streams. Does sending without "-D" work ok? This might be a vendor error as well. On 1.4.2013 20:05, Larry Rosenman wrote: > Re-Sending. Any ideas, guys/gals? > > This really gets in my way. > -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 22:59:26 2013 Return-Path: Delivered-To: freebsd-current@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 2AAD2A46 for ; Mon, 1 Apr 2013 22:59:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id BD90F755 for ; Mon, 1 Apr 2013 22:59:25 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi18so1974253wib.9 for ; Mon, 01 Apr 2013 15:59:24 -0700 (PDT) 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:cc :content-type; bh=WZq9qyeoXjAc/6Fztz3muVOJpXmvLl4bDshObBGI/I0=; b=bvmJRtmq4kstOxqxhodtzBy3QC8L6l05v91Af3Du4TdO52lJrT6EaL3hfmTckkJErH d7IQOVvP+lOiWqimSlhe88qfj8cCtlmTkmUoQ6Q+JFuXf6k5i4S91iRk8XHEAYvvgTSh mfLz0E6BLywMK9j5sOXqJlhnaI1V1sFSkrl/HG4KLlOJ4g1IPtnvD26SVnvXwkG9n4nR mBgFH5WyeO0rJOdFNEGMTfvMjDWsRC8erBEHv89z8Y0sYT9oIebzkBlD5tUjcGiPGnWk dE2/plt8IpC6qXf16kNCm7sDjJfbCXXCwKdc2f0Wt81PeW3kE5n7HI4vsd97rVxFGOHh x8GQ== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr12328437wid.29.1364857164952; Mon, 01 Apr 2013 15:59:24 -0700 (PDT) Received: by 10.216.108.130 with HTTP; Mon, 1 Apr 2013 15:59:24 -0700 (PDT) Date: Mon, 1 Apr 2013 15:59:24 -0700 Message-ID: Subject: Patch ath3kfw to accept other device ids; blacklist ath bluetooth devices From: Adrian Chadd To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:59:26 -0000 Hi, Please find a patch which does two things: * it allows ath3kfw to be given a vendor/productid, in order to load firmware into other NICs that only have a very basic firmware (sflash); * it blacklists all the NICs that have this particular behaviour (sourced from linux-next btusb.c driver). I've tested this on: * AR9285 + bluetooth (WB195) * AR9287 + bluetooht (WB197) I haven't yet opened the NICs up to see _exactly_ which BT chip is in them; I'll do that soon. There's some future work to do to allow for ROM patching and HCI configuration of later atheros bluetooth NICs; check the linux ath3k driver for more information. I'm not going to try and address these in this commit. I'd like to commit this to -HEAD if there are no objections. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 03:55:00 2013 Return-Path: Delivered-To: freebsd-current@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 B85F589D for ; Tue, 2 Apr 2013 03:55:00 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8947F373 for ; Tue, 2 Apr 2013 03:55:00 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id k14so2534658oag.39 for ; Mon, 01 Apr 2013 20:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jmHleY/uNZRVpjtEEO2M2GVwr6Xckm9E3ZB7P20udn8=; b=Z3e1W6rGjL/qPqFBzOvYFPBtkVM6ja/8nuYX4Ye1kUXGX+0134mDCzcotYs0/39TVM 7rGqKIYKCx/4X+nXW2lyBc/IXMhdogVoDC4U43W4r9Uxj2wlvrxajR5FI6l9aJApxoIo 9oa1MSeaLxobd7lkypgGYu8345Jb0GTz6B9LYFIcBMbpuBwyLpNoLzNnQayZYyI4xczE rVBO+7Q5sKUcSZuZQ+YW6Bhwz7IqBJ1C+PFvtrqeJVmyU25ZdNZfqaLSctNNkHEw6QoR Zfy4J/SUKPWVrYqip/szo80VIgzCOcjQEDBBsBCGz1F6FzK1q29My3Ae8TFJp6lUvnvj ONqw== MIME-Version: 1.0 X-Received: by 10.60.62.70 with SMTP id w6mr5194169oer.38.1364874899782; Mon, 01 Apr 2013 20:54:59 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.33.7 with HTTP; Mon, 1 Apr 2013 20:54:59 -0700 (PDT) In-Reply-To: <20130401144605.GA3932@tinyCurrent> References: <20130401144605.GA3932@tinyCurrent> Date: Mon, 1 Apr 2013 20:54:59 -0700 X-Google-Sender-Auth: kwVy2DFNWx_QqRFC_cFpaEP0pY8 Message-ID: Subject: Re: updating ports to HEAD From: Kevin Oberman To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 03:55:00 -0000 On Mon, Apr 1, 2013 at 7:46 AM, Matthias Apitz wrote: > > Hello, > > I have a FreeBSD 10-CURRENT as of: > > $ uname -a > FreeBSD aurora.Sisis.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235646: Sat > May 19 15:52:36 CEST 2012 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERIC > i386 > > and I want to update /usr/ports with SVN to HEAD and compile the stuff I > need; > > Is there something in the base system of r235646 which would not allow > to do so, i.e. which is to old for HEAD of ports? > I'm not quite sure what you mean by "update /usr/ports with SVN to HEAD", since ports does not branch, so any time you "svn up /usr/potrts", it is updated to head. Any version of FreeBSD 8 or newer should work fine with ports/head. Note that some ports will need to be compiled with gcc as not all will work with clang. Are you having a problem updating (or checking out) head or with some of the ports after the update? -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 05:03:14 2013 Return-Path: Delivered-To: freebsd-current@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 91D05492 for ; Tue, 2 Apr 2013 05:03:14 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB45838 for ; Tue, 2 Apr 2013 05:03:14 +0000 (UTC) Received: from [188.174.32.135] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UMtNH-0000yD-Pb; Tue, 02 Apr 2013 07:03:12 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id r3253AVG002406; Tue, 2 Apr 2013 07:03:10 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id r32539vP002405; Tue, 2 Apr 2013 07:03:09 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 2 Apr 2013 07:03:09 +0200 From: Matthias Apitz To: Kevin Oberman Subject: Re: updating ports to HEAD Message-ID: <20130402050309.GA2357@tinyCurrent> References: <20130401144605.GA3932@tinyCurrent> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.32.135 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 05:03:14 -0000 El día Monday, April 01, 2013 a las 08:54:59PM -0700, Kevin Oberman escribió: > > Is there something in the base system of r235646 which would not allow > > to do so, i.e. which is to old for HEAD of ports? > > > > I'm not quite sure what you mean by "update /usr/ports with SVN to HEAD", > since ports does not branch, so any time you "svn up /usr/potrts", it is > updated to head. I used the term 'HEAD' because the SVN command I have used was: # svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports > Any version of FreeBSD 8 or newer should work fine with > ports/head. Note that some ports will need to be compiled with gcc as not > all will work with clang. thanks; > > Are you having a problem updating (or checking out) head or with some of > the ports after the update? the system in question hast around 1200 ports compiled based on the CVS checkout of ports on May 19 last year; I want to check if I could compile Ekiga out of its GIT, wich needs gtk+3.4.x and other recent stuff; I will just for a test rename /usr/local and /var/db/pkg, update the ports to 'HEAD' and compile them again to see if this would solve the problem and make Ekiga happy. Thanks for your feedback matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 05:25:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2E006BC for ; Tue, 2 Apr 2013 05:25:52 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF8D8CB for ; Tue, 2 Apr 2013 05:25:52 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id o17so38974oag.20 for ; Mon, 01 Apr 2013 22:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ONqzwcVFseR3xmu9MZbZnqumQq8jIg8bvDjqgBipqV0=; b=s94sG/Rb5Rc7lDn4kinUHqCaSYqx/8rFkWwBHH72GrtYe7ZxtAAylEOJsJFjCIKvRM 4SjguR7LONcGGWnDTL17RaxXLsRP9CX/wwoeOEfQ4BLT21qtqx5BdecN6SCfiSscUhQi Q+yIL/YB47FleGuVb5vKod29EqvgW83mrRE6HfEU6Qsz2P17BybUR6QOTjqXkIyH0889 P1Bee+ZLIs5zA19PtnBHkdk5ZckoNO/5W4Y5JvcWc/uefNler8Y4Au7uDSfy+OGQfIzf YwhRRWUx9THrKRTE5HaO1yVFTcCGJKuVc703oKDjooU+KSfGsWlPRy7UQob6ulsFdl/D 5jjA== MIME-Version: 1.0 X-Received: by 10.60.62.70 with SMTP id w6mr5276145oer.38.1364880346442; Mon, 01 Apr 2013 22:25:46 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.33.7 with HTTP; Mon, 1 Apr 2013 22:25:46 -0700 (PDT) In-Reply-To: <20130402050309.GA2357@tinyCurrent> References: <20130401144605.GA3932@tinyCurrent> <20130402050309.GA2357@tinyCurrent> Date: Mon, 1 Apr 2013 22:25:46 -0700 X-Google-Sender-Auth: 09bSw0D8vDGD42VQUmHoaG5bTL4 Message-ID: Subject: Re: updating ports to HEAD From: Kevin Oberman To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 05:25:52 -0000 On Mon, Apr 1, 2013 at 10:03 PM, Matthias Apitz wrote: > El d=C3=ADa Monday, April 01, 2013 a las 08:54:59PM -0700, Kevin Oberman > escribi=C3=B3: > > > > Is there something in the base system of r235646 which would not allo= w > > > to do so, i.e. which is to old for HEAD of ports? > > > > > > > I'm not quite sure what you mean by "update /usr/ports with SVN to > HEAD", > > since ports does not branch, so any time you "svn up /usr/potrts", it i= s > > updated to head. > > I used the term 'HEAD' because the SVN command I have used was: > > # svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports > Assuming you previously deleted /usr/ports/*, that should so it > > Any version of FreeBSD 8 or newer should work fine with > > ports/head. Note that some ports will need to be compiled with gcc as > not > > all will work with clang. > > thanks; > > > > > Are you having a problem updating (or checking out) head or with some o= f > > the ports after the update? > > the system in question hast around 1200 ports compiled based on the CVS > checkout of ports on May 19 last year; I want to check if I could > compile Ekiga out of its GIT, wich needs gtk+3.4.x and other recent > stuff; I will just for a test rename /usr/local and /var/db/pkg, update > the ports to 'HEAD' and compile them again to see if this would solve > the problem and make Ekiga happy. > > Thanks for your feedback > Good luck. I suspect a successful update of ptlib will be the real tricky part. At least it gave me headaches back when I was using Ekiga. Also, gtk-3 has well over 400 dependencies. You will probably need to update some of these, so check UPDATING for those that need special attention. Good luck! --=20 R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 05:39:53 2013 Return-Path: Delivered-To: freebsd-current@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 CEA86D31 for ; Tue, 2 Apr 2013 05:39:53 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAB3946 for ; Tue, 2 Apr 2013 05:39:53 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id d7so35066wer.40 for ; Mon, 01 Apr 2013 22:39:52 -0700 (PDT) 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:content-transfer-encoding; bh=LLFWWVybqwX2nhzs1lFsdvjGcj5/MkOCey9Vv76htgY=; b=GmPEdJ5zPVPONZ2zS1UpglVIbgY3Yv2mAtYmTcFSSj76CNhDPti352wGNzmW4dyuuy 5HzyXNokfueFH3Gy4h4n7x/10f7bgx3q+65u6x3c3JsCikbZFlOBYWHNOIUGyzC/rmyI URFcOvJaKpai7schVNmZBGI9pFBJjuyQ0c5QzmHK5KSopr53G7Bh0NW+/QJG7IAY4irs 1rP01C4HHNzFogsEJu53wLvF/yAWuvdnfXPkfVeiFkILKj9H9cMs96xr1/1j+C+d9KX6 4aWvj46uUruj02pcM1lSRQfceN60mbHAVnl5qHrstCAHndD4GHF/6P0FPpcs6IpAWT3w ARUQ== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr19065560wjr.33.1364881192585; Mon, 01 Apr 2013 22:39:52 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 1 Apr 2013 22:39:52 -0700 (PDT) In-Reply-To: <20130402050309.GA2357@tinyCurrent> References: <20130401144605.GA3932@tinyCurrent> <20130402050309.GA2357@tinyCurrent> Date: Tue, 2 Apr 2013 08:39:52 +0300 Message-ID: Subject: Re: updating ports to HEAD From: Kimmo Paasiala To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 05:39:53 -0000 On Tue, Apr 2, 2013 at 8:03 AM, Matthias Apitz wrote: > El d=C3=ADa Monday, April 01, 2013 a las 08:54:59PM -0700, Kevin Oberman = escribi=C3=B3: > >> > Is there something in the base system of r235646 which would not allow >> > to do so, i.e. which is to old for HEAD of ports? >> > >> >> I'm not quite sure what you mean by "update /usr/ports with SVN to HEAD= ", >> since ports does not branch, so any time you "svn up /usr/potrts", it is >> updated to head. > > I used the term 'HEAD' because the SVN command I have used was: > > # svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports > >> Any version of FreeBSD 8 or newer should work fine with >> ports/head. Note that some ports will need to be compiled with gcc as n= ot >> all will work with clang. > > thanks; > >> >> Are you having a problem updating (or checking out) head or with some of >> the ports after the update? > > the system in question hast around 1200 ports compiled based on the CVS > checkout of ports on May 19 last year; I want to check if I could > compile Ekiga out of its GIT, wich needs gtk+3.4.x and other recent > stuff; I will just for a test rename /usr/local and /var/db/pkg, update > the ports to 'HEAD' and compile them again to see if this would solve > the problem and make Ekiga happy. > I hope for your sake that this machine is not open to the net with many services, using year old ports/packages is a death wish in such systems. In any case it's a good idea to update everything at least every two months about. -Kimmo From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 06:10:26 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C9BE195 for ; Tue, 2 Apr 2013 06:10:26 +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 83EC09FC for ; Tue, 2 Apr 2013 06:10:25 +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 JAA03479; Tue, 02 Apr 2013 09:10:23 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UMuQI-000ABA-Pe; Tue, 02 Apr 2013 09:10:22 +0300 Message-ID: <515A764C.6010401@FreeBSD.org> Date: Tue, 02 Apr 2013 09:10:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fabian Keil Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 References: <20130401161813.6e42e2a1@fabiankeil.de> <5159A517.5070802@FreeBSD.org> <20130401175126.1d28b0f4@fabiankeil.de> <5159B448.2080500@FreeBSD.org> In-Reply-To: <5159B448.2080500@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 06:10:26 -0000 on 01/04/2013 19:22 Andriy Gapon said the following: > on 01/04/2013 18:51 Fabian Keil said the following: >> vmcore.13: >> >> (kgdb) p *dn->dn_phys >> Cannot access memory at address 0xffffff8015eeb800 >> (kgdb) p *dn->dn_dbuf >> $1 = {db = {db_object = 0, db_offset = 28491776, db_size = 16384, db_data = 0xffffff8015eeb000}, db_objset = 0xfffffe00691a5000, db_dnode_handle = 0xfffffe00691a5020, db_parent = 0xfffffe004254ab60, >> db_hash_next = 0x0, db_blkid = 1739, db_blkptr = 0xffffff8015d65580, db_level = 0 '\0', db_mtx = {lock_object = {lo_name = 0xffffffff811d8696 "db->db_mtx", lo_flags = 40960000, lo_data = 0, >> lo_witness = 0x0}, sx_lock = 1}, db_state = DB_CACHED, db_holds = {rc_count = 2}, db_buf = 0xfffffe0042bedcf0, db_changed = {cv_description = 0xffffffff811d86a2 "db->db_changed", cv_waiters = 0}, >> db_data_pending = 0xfffffe00406d6500, db_last_dirty = 0xfffffe00406d6500, db_link = {list_next = 0xfffffe0042758c10, list_prev = 0xfffffe0069cab5f8}, db_user_ptr = 0xfffffe0069f70000, >> db_user_data_ptr_ptr = 0x0, db_evict_func = 0xffffffff81105770 , db_immediate_evict = 0 '\0', db_freed_in_flight = 0 '\0', db_dirtycnt = 1 '\001'} > > That's interesting. So db.db_data has a bogus address. > Not sure how that could happen and what to make of it yet. > In fact, this was a bogus comment :-) I forgot that dn_phys points inside a ZFS data buffer and those do not get dumped. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 08:52:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B755593 for ; Tue, 2 Apr 2013 08:52:25 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1A807C2 for ; Tue, 2 Apr 2013 08:52:24 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r328qNhI080347; Tue, 2 Apr 2013 12:52:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r328qNFZ080346; Tue, 2 Apr 2013 12:52:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 2 Apr 2013 12:52:22 +0400 From: Gleb Smirnoff To: Freddie Cash Subject: Re: Anyone have scripts for managing interfaces under new CARP setup? Message-ID: <20130402085222.GH76816@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:52:25 -0000 Freddie, On Wed, Mar 27, 2013 at 04:10:03PM -0700, Freddie Cash wrote: F> Just curious if anyone has any scripts for managing fail-over of multiple F> interfaces using the new CARP setup in 10-CURRENT. F> F> Fail-over of all CARP vhids associated with a single interface is working F> correctly. But, I have 2 separate, physical interfaces running with CARP, F> and want to fail-over everything if one of the links (or boxes) goes down. F> F> Figured I'd ask around to see if anyone has done something like this F> already. I've been playing with devd.conf settings and logging events, but F> don't have anything written up to do the actual switch yet. Same as for old CARP, you can achieve behavior when a box with lower advskew yields master status to a second one, setting: sysctl net.inet.carp.preempt=1 If an interface on the master has proper link state notification to the kernel, then once the interface goes down, the advskew on the box will be demoted and backup box will preempt it. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 09:02:39 2013 Return-Path: Delivered-To: current@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 D446C88D; Tue, 2 Apr 2013 09:02:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AB55512F; Tue, 2 Apr 2013 09:02:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3292Xa2059774; Tue, 2 Apr 2013 05:02:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3292XH2059761; Tue, 2 Apr 2013 09:02:33 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 2 Apr 2013 09:02:33 GMT Message-Id: <201304020902.r3292XH2059761@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:02:39 -0000 TB --- 2013-04-02 07:42:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-02 07:42:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-02 07:42:29 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-04-02 07:42:29 - cleaning the object tree TB --- 2013-04-02 07:42:29 - /usr/local/bin/svn stat /src TB --- 2013-04-02 07:42:32 - At svn revision 248992 TB --- 2013-04-02 07:42:33 - building world TB --- 2013-04-02 07:42:33 - CROSS_BUILD_TESTING=YES TB --- 2013-04-02 07:42:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-02 07:42:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-02 07:42:33 - SRCCONF=/dev/null TB --- 2013-04-02 07:42:33 - TARGET=powerpc TB --- 2013-04-02 07:42:33 - TARGET_ARCH=powerpc64 TB --- 2013-04-02 07:42:33 - TZ=UTC TB --- 2013-04-02 07:42:33 - __MAKE_CONF=/dev/null TB --- 2013-04-02 07:42:33 - cd /src TB --- 2013-04-02 07:42:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Apr 2 07:42:37 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 [...] c++ -O2 -pipe -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/DominanceFrontier.cpp -o DominanceFrontier.o c++ -O2 -pipe -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/IVUsers.cpp -o IVUsers.o c++ -O2 -pipe -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/InlineCost.cpp -o InlineCost.o /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/InlineCost.cpp: In member function 'llvm::InlineCost llvm::InlineCostAnalyzer::getInlineCost(llvm::CallSite, llvm::Function*, int)': /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/InlineCost.cpp:1042: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** [InlineCost.o] Error code 1 Stop in /src/lib/clang/libllvmanalysis. *** [all] Error code 1 Stop in /src/lib/clang. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-02 09:02:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-02 09:02:33 - ERROR: failed to build world TB --- 2013-04-02 09:02:33 - 4050.19 user 510.41 system 4803.97 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 11:17:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18B0713C for ; Tue, 2 Apr 2013 11:17:28 +0000 (UTC) (envelope-from isabell@issyl0.co.uk) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by mx1.freebsd.org (Postfix) with ESMTP id D328AA8F for ; Tue, 2 Apr 2013 11:17:27 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz10so312334veb.3 for ; Tue, 02 Apr 2013 04:17:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=j4q6f/hzzi8RjgPo3d1NXqs3Jf8mhk/26YGiWcXjcOQ=; b=AJ10wRDTbZi17bJNBClPjRDKIIFYRW6RQze5zOuyI9193+xFFU5LOjjAtTI+p/szBN 0rCBTkAUbzkS6cQkcizPYsZRyNIuEsXUKB4UV29EVrIXmEDUk5Leqh6gpUkv1zwQSPPo ZR5CMj8Ej+3W3X9zD7jUUJz2QBpaE3Ph9qfBD/gZWHAO+b+yme9BUcowtG3m64JWoTIF xY6L5ugxhmzraol5IStufjVd5JG96XRcZ0Aq7AXYIbEhHeDDwh28/4VX3dXdVDw+w5f+ cReDjS2S96taM8xCqMYDSvaoc1jWIG2XPcU6YlTp51XkCZLCit6/X6DG1GN8BB+1dRy7 0j6Q== MIME-Version: 1.0 X-Received: by 10.220.155.8 with SMTP id q8mr12065231vcw.42.1364901441254; Tue, 02 Apr 2013 04:17:21 -0700 (PDT) Sender: isabell@issyl0.co.uk Received: by 10.220.84.71 with HTTP; Tue, 2 Apr 2013 04:17:21 -0700 (PDT) X-Originating-IP: [87.246.88.161] Date: Tue, 2 Apr 2013 12:17:21 +0100 X-Google-Sender-Auth: BvPd5I1XgjbcT5mSJnXrYcYBacQ Message-ID: Subject: Call for FreeBSD 2013-Q1 status reports! From: Isabell Long To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlp3FRw+zJZ+nLRk1QFMZDaGamZ3lLZQ/JviCedOT68dp6HsC3A6143qo4s+mzaZpHnoaU5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 11:17:28 -0000 Hi all, On behalf of monthly@, I would like to inform you that the next submission date for the January to March quarterly status reports is April 21st, 2013 - less than a month away. They don't have to be very long - anything that lets people know what is going on inside FreeBSD is useful. Note that submission of reports is not restricted to committers - anyone who is doing anything interesting and FreeBSD-related can write one! The preferred and easiest submission method is to use the XML generator linked to from http://www.freebsd.org/news/status/status.html, with the result emailed as an attachment to monthly@FreeBSD.org. On that page, there is also a link to an XML template which can be filled out manually and attached if preferred. To enable compilation and publication of the Q1 report as soon as possible after the April 21st deadline, please be prompt with any report submissions you may have. I look forward to compiling the report for 2013 Q1. Many thanks, Isabell. (Hat: monthly@) From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 16:25:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B53BEE6B for ; Tue, 2 Apr 2013 16:25:14 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 74FCCE54 for ; Tue, 2 Apr 2013 16:25:14 +0000 (UTC) Received: from [188.174.220.239] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UN41C-0006y9-MN; Tue, 02 Apr 2013 18:25:07 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id r32GP5AL002179; Tue, 2 Apr 2013 18:25:05 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id r32GP5RG002178; Tue, 2 Apr 2013 18:25:05 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 2 Apr 2013 18:25:04 +0200 From: Matthias Apitz To: Kevin Oberman Subject: Re: updating ports to HEAD Message-ID: <20130402162504.GA2167@tinyCurrent> References: <20130401144605.GA3932@tinyCurrent> <20130402050309.GA2357@tinyCurrent> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.220.239 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:25:14 -0000 El día Monday, April 01, 2013 a las 10:25:46PM -0700, Kevin Oberman escribió: > Good luck. I suspect a successful update of ptlib will be the real tricky > part. At least it gave me headaches back when I was using Ekiga. PTlib and opal are compiling fine directly from their SVN repositories; > Also, gtk-3 has well over 400 dependencies. You will probably need to > update some of these, so check UPDATING for those that need special > attention. Good luck! Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 17:21:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B80DE51D for ; Tue, 2 Apr 2013 17:21:51 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mx1.freebsd.org (Postfix) with ESMTP id 887CE20B for ; Tue, 2 Apr 2013 17:21:51 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id g12so633949oah.10 for ; Tue, 02 Apr 2013 10:21:50 -0700 (PDT) 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=cW0kRG02xH+MqlkdvbrTGDVoZK6+3NAgJjFIRcFpXIE=; b=AoVIKhqXxCLNV924V7Mg/v8U3aC4okBmYgJETKdc3stb8PGBP+oXc2dj8dJpSXQIBt nd7jTWWrUcfYeHZBK3hEMWFIHCi4QWOr/tbI3nkcUUrHjifscUViTneTkASwDn8z8Jkf IbrQgS4LlMzDnZ0R7mfA37u/jVXonMc7IGzJ+R8z0F+LBtUOpiZP43w7Q8qX89Wf02Jk 3mvScB6UaRKK4A7vUzpau+ctUHM4yCQ2TdTt68RmJ2zSr8hKyXqm2CFYYnvq9WSm6zkv g1N0mIzbh0mWFvLOd4zu8qmjqMKXnhvN0YRoZenUncWatWdcWhalhjsrE272DOfouRZz ssHg== MIME-Version: 1.0 X-Received: by 10.182.56.198 with SMTP id c6mr5943081obq.73.1364923310617; Tue, 02 Apr 2013 10:21:50 -0700 (PDT) Received: by 10.76.108.7 with HTTP; Tue, 2 Apr 2013 10:21:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Apr 2013 10:21:50 -0700 Message-ID: Subject: Re: Patch ath3kfw to accept other device ids; blacklist ath bluetooth devices From: Maksim Yevmenkin To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:21:51 -0000 Hi Adrian, Please find a patch which does two things: > > patch was lost, apparently :) thanks max From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 18:23:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CFCF2E9A for ; Tue, 2 Apr 2013 18:23:31 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from popeye.kernel32.de (popeye.kernel32.de [46.4.9.204]) by mx1.freebsd.org (Postfix) with ESMTP id 86DCFE0E for ; Tue, 2 Apr 2013 18:23:31 +0000 (UTC) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTP id 6326448B75 for ; Tue, 2 Apr 2013 20:23:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at popeye.kernel32.de Received: from popeye.kernel32.de ([127.0.0.1]) by popeye.kernel32.de (popeye.kernel32.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMfRtSz-EIxq for ; Tue, 2 Apr 2013 20:23:20 +0200 (CEST) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTPA id C1B2448B6A for ; Tue, 2 Apr 2013 20:23:20 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2013 20:23:20 +0200 From: mh@kernel32.de To: Subject: Re: panic at serial boot In-Reply-To: <24096f01453ab9d0fe898522874cd928@kernel32.de> References: <515289AC.3050204@FreeBSD.org> <936608f069b988fcd58707edb9b4dde0@kernel32.de> <20130327133220.GZ3794@kib.kiev.ua> <24096f01453ab9d0fe898522874cd928@kernel32.de> Message-ID: <941a3c1e7cb49087c8bf941399b1e5ae@kernel32.de> X-Sender: mh@kernel32.de User-Agent: RoundCube WebMail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:23:31 -0000 Hi Konstantin, Am 2013-03-27 15:33, schrieb mh@kernel32.de: > Am 2013-03-27 14:32, schrieb Konstantin Belousov: >> >> Do you use preload md(4) ? If yes, try the following patch: >> > > > Not sure whether time permits that today, but I'm starting right > away. > Had no time before easter, but I tried it now. This time, no panic, but also it doesn't continue to boot ;) This is the last output I can see: ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 4 vector 48 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 5 vector 48 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 6 vector 48 msi: Assigning MSI-X IRQ 264 to local APIC 7 vector 48 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1300027430 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus2 usbus1 usbus0 uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus0 ugen0.2: at usbus0 uhub3: on usbus0 ugen2.2: at usbus2 uhub4: on usbus2 Root mount waiting for: usbus2 usbus0 uhub3: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered ugen2.3: at usbus2 uhub5: on usbus2 Root mount waiting for: usbus2 uhub5: 2 ports with 1 removable, self powered Trying to mount root from ufs:/dev/md0 []... start_init: trying /sbin/init And it stayed there for the last 10 minutes. What can I do now? thanks and best regards, Marian PS.: FWIW, the image I build via mfsbsd is here: http://mon.kernel32.de/mfsbsd-se-CURRENT-mdpatch.iso And the hd image used for pxe booting is this one: http://mon.kernel32.de/FreeBSD-10.0-CURRENT-amd64.hd From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 18:39:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id DBAD63B3; Tue, 2 Apr 2013 18:39:26 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id E7BB123CED6; Tue, 2 Apr 2013 20:39:25 +0200 (CEST) Message-ID: <515B25D8.7050902@FreeBSD.org> Date: Tue, 02 Apr 2013 20:39:20 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4607F44AD83573971B4E25C3" Cc: Alexander Motin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:39:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4607F44AD83573971B4E25C3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 31.03.2013 23:02, schrieb Scott Long: > So what I hear you and Matthias saying, I believe, is that it should be= easier to > force disks to fall back to non-NCQ mode, and/or have a more responsive= > black-list for problematic controllers. Would this help the situation?= It's hard to > justify holding back overall forward progress because of some bad contr= ollers; > we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD = 9.x, > enough to make up a sizable percentage of the internet's traffic, and w= e see no > problems. How can we move forward but also take care of you guys with > problematic hardware? Well, I am running the driver fine off of my WD Caviar RE3 disk, and the problematic drive also works just fine with Windows and Linux, so it must be something between the problematic drive and the FreeBSD driver. I would like to see any of this, in decreasing order of precedence: - debugged driver - assistance/instructions on helping how to debug the driver/trace NCQ stuff/... (as in Jeremy Chadwick's followup in this same thread - this helps, I will attempt to procure the required information; "back then", reducing the number of tags to 31 was ineffective, including an error message and getting a value of 32 when reading the setting back) - "user-space" contingency features, such as letting camcontrol limit the number of open NCQ tags, or disable NCQ, either on a per-drive basis I am capable of debugging C - mostly with gdb command-line, and graphical Windows IDEs - but am unfamiliar with FreeBSD kernel debugging. If necessary, I can pull up a second console, but the PC that is affected is legacy-free, so serial port only works through a serial/USB converter. --------------enig4607F44AD83573971B4E25C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFbJd0ACgkQvmGDOQUufZXgTQCdHbEU7eARpq9xywE6doCJKcs1 5HEAoJibxdGKMztwTmtPi5GaVGnuTW4q =sEXh -----END PGP SIGNATURE----- --------------enig4607F44AD83573971B4E25C3-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 19:52:31 2013 Return-Path: Delivered-To: freebsd-current@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 DC02B9FB for ; Tue, 2 Apr 2013 19:52:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 38F57615 for ; Tue, 2 Apr 2013 19:52:31 +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 r32JqN60049983; Tue, 2 Apr 2013 22:52:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r32JqN60049983 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r32JqN7x049982; Tue, 2 Apr 2013 22:52:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Apr 2013 22:52:23 +0300 From: Konstantin Belousov To: mh@kernel32.de Subject: Re: panic at serial boot Message-ID: <20130402195223.GU3794@kib.kiev.ua> References: <515289AC.3050204@FreeBSD.org> <936608f069b988fcd58707edb9b4dde0@kernel32.de> <20130327133220.GZ3794@kib.kiev.ua> <24096f01453ab9d0fe898522874cd928@kernel32.de> <941a3c1e7cb49087c8bf941399b1e5ae@kernel32.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OkP4R/eAVrLNUAwh" Content-Disposition: inline In-Reply-To: <941a3c1e7cb49087c8bf941399b1e5ae@kernel32.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:52:31 -0000 --OkP4R/eAVrLNUAwh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 02, 2013 at 08:23:20PM +0200, mh@kernel32.de wrote: > Hi Konstantin, >=20 > Am 2013-03-27 15:33, schrieb mh@kernel32.de: > > Am 2013-03-27 14:32, schrieb Konstantin Belousov: > >> > >> Do you use preload md(4) ? If yes, try the following patch: > >> > > > > > > Not sure whether time permits that today, but I'm starting right=20 > > away. > > > Had no time before easter, but I tried it now. > This time, no panic, but also it doesn't continue to boot ;) >=20 > This is the last output I can see: > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 > ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 2 vector 48 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 4 vector 48 > ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 5 vector 48 > ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 6 vector 48 > msi: Assigning MSI-X IRQ 264 to local APIC 7 vector 48 > SMP: passed TSC synchronization test > TSC timecounter discards lower 1 bit(s) > Timecounter "TSC-low" frequency 1300027430 Hz quality 1000 > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus2 usbus1 usbus0 > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub0: 2 ports with 2 removable, self powered > Root mount waiting for: usbus2 usbus0 > ugen0.2: at usbus0 > uhub3: = =20 > on usbus0 > ugen2.2: at usbus2 > uhub4: = =20 > on usbus2 > Root mount waiting for: usbus2 usbus0 > uhub3: 6 ports with 6 removable, self powered > uhub4: 8 ports with 8 removable, self powered > ugen2.3: at usbus2 > uhub5: = =20 > on usbus2 > Root mount waiting for: usbus2 > uhub5: 2 ports with 1 removable, self powered > Trying to mount root from ufs:/dev/md0 []... > start_init: trying /sbin/init Good, thank you for testing. >=20 > And it stayed there for the last 10 minutes. >=20 > What can I do now? I booted the image in qemu, initially there were no output on the screen. In fact, the system is very much alive, I broke into the debugger several times, and saw the tar/xz/sh working. More, after some time, I got a login: prompt. I have no idea what to expect from this thing, should it output anything after the kernel finished initializing, and why it sit there for 10 minutes. Try breaking into the debugger and see where it progresses. To do this, you would need to boot with the 'boot -d' command from the loader prompt, then do 'w kbd_break_to_debugger 1', then ctrl-alt-esc when you want to activate the debugger. In the debugger, start with the 'ps' command. >=20 > thanks and best regards, > Marian >=20 > PS.: FWIW, the image I build via mfsbsd is here:=20 > http://mon.kernel32.de/mfsbsd-se-CURRENT-mdpatch.iso > And the hd image used for pxe booting is this one:=20 > http://mon.kernel32.de/FreeBSD-10.0-CURRENT-amd64.hd >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --OkP4R/eAVrLNUAwh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRWzb2AAoJEJDCuSvBvK1Ba8cQAIeKMeMBFtv2xbiX7E3f7hes 053Ip3dMxG7pN0EUdgvasakehD5T/1iBSuDWGXZQFalS/TvT1mG7miMfn46aqAC9 cvomxi995JwB+CHC9XKAyv38GcthYGMvEqWKQns2RudACN0c+MWnT5SsQ3FceqKz XtQhuztaqCA5MH1xZS2v4uEdYy+5sac+AV8LiuFsLXh1hUcVSMtP8x6Rlw6FHtxj S8T9lh+jEMEkZzbIn4Gku+dj3xr0eUjDE+uapQSku1WAMLCU/1teJ8BvT6DqqX6N 7M/YTb5AUBZ1v5T4vdhAtlNoZKKRSE6uttTmTOckQvtlXnBbiMjz0BJZg87/MN16 QqDI9JXiKQQ9jaM+969DVqI+Ea9ukwrmuuhu+1KANBhadUu57w245HOQyDbn6lQE I3i5orarsWuyi9TxSs2PhVmU9B+3h1ef663/9uNvI9pnz124WTtE9MSmrN75BUvU 1OazcoAazBjQynQgPRZjPae1L2EazgVFARdwdW9oVf+XGwo7ZweNW0FGbEUTGBH6 zdpXXg0Ire5ES/LzJPfB6rhcSEsmQfJSWnc12gZ2q4Pbj3dKtyWupTFD593NCUpl FJ9Q8w+tfjFdwreF5XKhVlJGzWI7ELSkhZqTKM0HiWaw4KRTQ2Ff1i54DujiP6/h prYbSdAJOxfQCqug1cqs =qZIV -----END PGP SIGNATURE----- --OkP4R/eAVrLNUAwh-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 20:11:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8568BF9B for ; Tue, 2 Apr 2013 20:11:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 22215727 for ; Tue, 2 Apr 2013 20:11:09 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so3613730wib.1 for ; Tue, 02 Apr 2013 13:11:07 -0700 (PDT) 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=MIm38N+uc9QwL7zdWhcZ0HD6hbWOV/af0Fa+6snnIiw=; b=qq5qk3ehCeazucJRQa8dQivo4zGmiye9OjKEFRx8eLrjaGL59m6jC06OToBf9gPATT QQleBUQrO293mx12R/gRrC+wGkzBWMOxelDPN5Tg40hJ7dnzEOVmKcByC8xOOIbHTSNx ELxU5GDMkNvekjuShmhgmz7Szn3j1QuItOZIDhWlJAEM3kvVixRAZfsusrIrwzl6D20j mbWnrYb7K7uJ6ev4Sc71t0KmNRpOOf3MTuExFcReG0Wks4WaQM1P6p44sR0JXduT0g25 GLnt2EcwvU+izfioZB2p4g+kp+w4T7IdMDVHo85ygVzDDMQzY3LGp3HbM7U+Do/pQKlO bZqg== MIME-Version: 1.0 X-Received: by 10.194.22.5 with SMTP id z5mr24577721wje.5.1364933467263; Tue, 02 Apr 2013 13:11:07 -0700 (PDT) Received: by 10.216.108.130 with HTTP; Tue, 2 Apr 2013 13:11:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Apr 2013 13:11:07 -0700 Message-ID: Subject: Re: Patch ath3kfw to accept other device ids; blacklist ath bluetooth devices From: Adrian Chadd To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:11:10 -0000 On 2 April 2013 10:21, Maksim Yevmenkin wrote: > Hi Adrian, > >> Please find a patch which does two things: >> > > patch was lost, apparently :) Oh for gods sake. God damned mailing list setup. I'll upload the patch soon. adrian From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 20:51:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C7F009B5 for ; Tue, 2 Apr 2013 20:51:36 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from popeye.kernel32.de (popeye.kernel32.de [46.4.9.204]) by mx1.freebsd.org (Postfix) with ESMTP id 89ADE9C4 for ; Tue, 2 Apr 2013 20:51:36 +0000 (UTC) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTP id 47954428C4 for ; Tue, 2 Apr 2013 22:51:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at popeye.kernel32.de Received: from popeye.kernel32.de ([127.0.0.1]) by popeye.kernel32.de (popeye.kernel32.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1Jp2c9KMjo6 for ; Tue, 2 Apr 2013 22:51:30 +0200 (CEST) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTPA id 68339428B9 for ; Tue, 2 Apr 2013 22:51:30 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2013 22:51:30 +0200 From: mh@kernel32.de To: Subject: Re: panic at serial boot In-Reply-To: <20130402195223.GU3794@kib.kiev.ua> References: <515289AC.3050204@FreeBSD.org> <936608f069b988fcd58707edb9b4dde0@kernel32.de> <20130327133220.GZ3794@kib.kiev.ua> <24096f01453ab9d0fe898522874cd928@kernel32.de> <941a3c1e7cb49087c8bf941399b1e5ae@kernel32.de> <20130402195223.GU3794@kib.kiev.ua> Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube WebMail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:51:36 -0000 Am 2013-04-02 21:52, schrieb Konstantin Belousov: > On Tue, Apr 02, 2013 at 08:23:20PM +0200, mh@kernel32.de wrote: >> Root mount waiting for: usbus2 >> uhub5: 2 ports with 1 removable, self powered >> Trying to mount root from ufs:/dev/md0 []... >> start_init: trying /sbin/init > Good, thank you for testing. > thank you for helping out! :) Although I might have to start another thread on freebsd-stable@, because my actual task here is to get 9.1-RELEASE up and running on this hardware (HP G8 Blade, and/or Dell M620 blade). 9.1-RELEASE weirdly enough gives me no serial output whatsoever. With identical loader settings. Well... I just thought I'd give -CURRENT a try and realized this problem and then thought I might as well continue here, since -CURRENT will be 10.0-REL someday... >> >> And it stayed there for the last 10 minutes. >> >> What can I do now? > I booted the image in qemu, initially there were no output on the > screen. In fact, the system is very much alive, I broke into the > debugger several times, and saw the tar/xz/sh working. More, after > some > time, I got a login: prompt. > Interesting... > I have no idea what to expect from this thing, should it output > anything > after the kernel finished initializing, and why it sit there for 10 > minutes. > > Try breaking into the debugger and see where it progresses. To do > this, > you would need to boot with the 'boot -d' command from the loader > prompt, > then do 'w kbd_break_to_debugger 1', then ctrl-alt-esc when you want > to > activate the debugger. In the debugger, start with the 'ps' command. > I'm going to give it a try, although it'll be quite hard. I'm at a serial console via ssh on a HP blade with 9600 baud. I do wonder whether I can see anything while trying to get to the boot prompt. Let alone how to send a ctrl alt esc sequence via this line. hm. I broke too early into the loader, did I? FreeBSD/x86 boot Default: 0:ad(0,a)boot boot: boot -dNo boot I'm going to continue trying to boot with -d and then break to the debugger. Let's see how long it'll take me on this serial line. Yuk. And I don't dare trying the Java applet for VGA. This one's even more difficult with regards to input/output. Later, ./Marian From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 21:06:10 2013 Return-Path: Delivered-To: freebsd-current@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 8B1AAD1A for ; Tue, 2 Apr 2013 21:06:10 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from popeye.kernel32.de (popeye.kernel32.de [46.4.9.204]) by mx1.freebsd.org (Postfix) with ESMTP id 4C42BA7C for ; Tue, 2 Apr 2013 21:06:09 +0000 (UTC) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTP id 1680D482D8 for ; Tue, 2 Apr 2013 23:06:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at popeye.kernel32.de Received: from popeye.kernel32.de ([127.0.0.1]) by popeye.kernel32.de (popeye.kernel32.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgNJG_ECs-rK for ; Tue, 2 Apr 2013 23:06:07 +0200 (CEST) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTPA id 46C4D482CA; Tue, 2 Apr 2013 23:06:06 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2013 23:06:06 +0200 From: mh@kernel32.de To: Konstantin Belousov Subject: Re: panic at serial boot In-Reply-To: <20130402195223.GU3794@kib.kiev.ua> References: <515289AC.3050204@FreeBSD.org> <936608f069b988fcd58707edb9b4dde0@kernel32.de> <20130327133220.GZ3794@kib.kiev.ua> <24096f01453ab9d0fe898522874cd928@kernel32.de> <941a3c1e7cb49087c8bf941399b1e5ae@kernel32.de> <20130402195223.GU3794@kib.kiev.ua> Message-ID: <80b2deb3359ca04fb784334d60719860@kernel32.de> X-Sender: mh@kernel32.de User-Agent: RoundCube WebMail Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:06:10 -0000 Hi again, Am 2013-04-02 21:52, schrieb Konstantin Belousov: > On Tue, Apr 02, 2013 at 08:23:20PM +0200, mh@kernel32.de wrote: > > Try breaking into the debugger and see where it progresses. To do > this, > you would need to boot with the 'boot -d' command from the loader > prompt, > then do 'w kbd_break_to_debugger 1', then ctrl-alt-esc when you want > to > activate the debugger. In the debugger, start with the 'ps' command. > After the beastie menu I went to the loader prompt and did "boot -d". I was sent to the debugger and did "w kbd_break_to_debugger 1". This is the output I get. INT 13 08: Success, count = 1, BPT = 0000:0000 GDB: no debug ports present KDB: debugger backends: ddbhift limit: 0x82 KDB: current backend: ddbt15 = f000f859 int1e = f000ef6d KDB: enter: Boot flags requested debuggerint1e = f000ef6d [ thread pid 0 tid 0 ] booting... Stopped at kdb_enter+0x3e: movq $0,kdb_why db> w kbd_break_to_debugger 1 Symbol not found Where to go from now? A good pointer to documentation is okay too ;) Sorry if asking too many questions, but although being a FreeBSD user since 4.0, I never had to debug or been to where I am now. So in advance another sorry if the question sounds stupid. A quick google for 'FreeBSD "w kbd_break_to_debugger 1" "Symbol not found"' didn't return anything. a little helpless regards, ./Marian From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 21:26:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DA622411; Tue, 2 Apr 2013 21:26:30 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id 9FF40C1A; Tue, 2 Apr 2013 21:26:30 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 8EAD4397A; Tue, 2 Apr 2013 23:26:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id 1UNUI-FwLiur; Tue, 2 Apr 2013 23:26:21 +0200 (CEST) Received: from [127.0.0.1] (chello085216226145.chello.sk [85.216.226.145]) by mail.vx.sk (Postfix) with ESMTPSA id EBFB93973; Tue, 2 Apr 2013 23:26:20 +0200 (CEST) Message-ID: <515B4CFA.9080706@FreeBSD.org> Date: Tue, 02 Apr 2013 23:26:18 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Larry Rosenman Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT References: <5159EF29.6000503@FreeBSD.org> In-Reply-To: <5159EF29.6000503@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130402-0, 02/04/2013), Outbound message X-Antivirus-Status: Clean Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:26:30 -0000 On 1. 4. 2013 22:33, Martin Matuska wrote: > This error seems to be limited to sending deduplicated streams. Does > sending without "-D" work ok? This might be a vendor error as well. > > On 1.4.2013 20:05, Larry Rosenman wrote: >> Re-Sending. Any ideas, guys/gals? >> >> This really gets in my way. >> This may be also related to: http://www.freebsd.org/cgi/query-pr.cgi?pr=176978 -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 22:15:05 2013 Return-Path: Delivered-To: freebsd-current@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 45F883A7; Tue, 2 Apr 2013 22:15:05 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id AD836E7D; Tue, 2 Apr 2013 22:15:04 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id q14so435122eaj.8 for ; Tue, 02 Apr 2013 15:15:02 -0700 (PDT) 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=jJEXHXaxR5sTHIxfi4fyosJkzCYrbW15lcPGAm2a/Q4=; b=xhAxwqmbOEqwqQJShs+hkfEzAQ8+Q55SmXEWs6Wx4ETA/9+U2687qptmCpBH19t04V fBt7LpiEtnA8hC2xBlNYA0aSvJp+tQBsUVFPYjW6eodPxjMvR2G+/VZYFyz1H+L4nMEp lo4D2Ekm7urlU84Bg5bkuoXbTRADNlAtKCkmi0plPI7+VDoh5svwfEDf5Vn46AAShBa8 Lo3Y7MTVwad77U14KGEHhGdVVQAAL1T2gkOlDvGaF9GiDC6dczSX0Qz6hhXMlyYPqkjj vED32ri6MFfPBE10B2XGFyHELbwaNdQrCoCUbJIfcO3CGX0gW7vAqI9T1F0+sEfQEjKc s0bg== X-Received: by 10.15.35.193 with SMTP id g41mr53545570eev.45.1364940902681; Tue, 02 Apr 2013 15:15:02 -0700 (PDT) Received: from [192.168.1.80] (1F2E5864.dsl.pool.telekom.hu. [31.46.88.100]) by mx.google.com with ESMTPS id 44sm5282881eek.5.2013.04.02.15.15.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 15:15:01 -0700 (PDT) Message-ID: <515B6677.2080402@gmail.com> Date: Wed, 03 Apr 2013 01:15:03 +0200 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: poweroff (shutdown -p) is broken Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:15:05 -0000 As of r248872, my system, when ordered to power off, stalls at the "Uptime: [...]" message. Before that revision, the "Uptime" message would be followed by several additional messages -- something related to "usb controllers" -- before powering off. From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 22:20:40 2013 Return-Path: Delivered-To: freebsd-current@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 083A0576 for ; Tue, 2 Apr 2013 22:20:40 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 92216ED8 for ; Tue, 2 Apr 2013 22:20:39 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id c1so447770eek.14 for ; Tue, 02 Apr 2013 15:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=o4AZru+M7UieZPo+4G7c5+8ppyOY5WRt+uD6fn6EGOQ=; b=E2RmFwToqk0/n8A9NnXVt9/FS0BK6ZNY3NSZVlFv1cTFCAf25+nitXwZrRlTaQwfRz i8zLjNBSjFrog9EztPLc/4IhR46+jrq+nXaoi6KIwmHBDAzHpsahZReev4vrK+WzjH0d 8W0QCVCpQbwCFycyrizgKTGh7m+vL6lOHQu6+bA5NjEcXbfQ4aMa8YrLL6uVbaReJUO0 Ceah63cd8F+mTocjOCVRxRSDYb2W4eLef7TLKKTEQthhA909GqUiWEnbDr2Bamx5HW4A Rl0SJGZqpDNsQW6bHrEEUK9Dh/Nb2cAuRWZWEzTcPkUj6LG5ZaNSamAgs0QwNo7lIVpX p1wQ== X-Received: by 10.15.81.136 with SMTP id x8mr53941065eey.9.1364941238253; Tue, 02 Apr 2013 15:20:38 -0700 (PDT) Received: from [192.168.1.80] (1F2E5864.dsl.pool.telekom.hu. [31.46.88.100]) by mx.google.com with ESMTPS id ca4sm5248328eeb.15.2013.04.02.15.20.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 15:20:37 -0700 (PDT) Message-ID: <515B67C7.602@gmail.com> Date: Wed, 03 Apr 2013 01:20:39 +0200 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: poweroff (shutdown -p) is broken References: <515B6677.2080402@gmail.com> In-Reply-To: <515B6677.2080402@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:20:40 -0000 My kernel configuration file: cpu I686_CPU options SCHED_ULE options PREEMPTION options INET options FFS options SOFTUPDATES options UFS_DIRHASH options MD_ROOT options MSDOSFS options CD9660 options GEOM_PART_GPT options GEOM_LABEL options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 options COMPAT_FREEBSD7 options SCSI_DELAY=1000 options SYSVSHM options SYSVMSG options SYSVSEM options _KPOSIX_PRIORITY_SCHEDULING options PRINTF_BUFR_SIZE=128 options KBD_INSTALL_CDEV options INCLUDE_CONFIG_FILE options SMP device apic device acpi device pci device ahci device ata options ATA_CAM options ATA_STATIC_ID device scbus device ch device da device cd device pass device ses device atkbdc device atkbd device psm device vga device sc device agp device pmtimer device miibus device rl device loop device random device ether device md device firmware device uhci device ohci device ehci device usb device uhid device umass device ums device sound device snd_ich device drm device radeondrm From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 22:21:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0ED2F683 for ; Tue, 2 Apr 2013 22:21:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id E432EEE8 for ; Tue, 2 Apr 2013 22:21:00 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r32MKxfA024680; Tue, 2 Apr 2013 15:20:59 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r32MKx82024679; Tue, 2 Apr 2013 15:20:59 -0700 (PDT) (envelope-from david) Date: Tue, 2 Apr 2013 15:20:59 -0700 From: David Wolfskill To: deeptech71 Subject: Re: poweroff (shutdown -p) is broken Message-ID: <20130402222059.GW1332@albert.catwhisker.org> References: <515B6677.2080402@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/T7Ys/vy2qfZwzBO" Content-Disposition: inline In-Reply-To: <515B6677.2080402@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:21:01 -0000 --/T7Ys/vy2qfZwzBO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 03, 2013 at 01:15:03AM +0200, deeptech71 wrote: > As of r248872, my system, when ordered to power off, stalls at the "Uptim= e: [...]" message. Before that revision, the "Uptime" message would be foll= owed by several additional messages -- something related to "usb controller= s" -- before powering off. > .... I suspect that a few more details may be helpful: I track stable/9 & head daily on a couple of machines, one of which gets a "shutdown -p" while it's running head (after I'm finished with the building & smoke-testing). And I have not seen the problem you are reporting. Yesterday, I built & tested FreeBSD/i386 10.0-CURRENT r248969M/248969:1000030; today, it was r249012M/249014:1000030. That system runs a GENERIC kernel. (The "modification" denoted by the "M" suffix up there is merely to src/sys/conf/newvers.sh.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --/T7Ys/vy2qfZwzBO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFbWcoACgkQmprOCmdXAD0ffACggZVWuv0BSSSTtVJXccs9kK9n lGMAn2SEqJyKBkYeozeVZ5RKYojDpx/J =xkqS -----END PGP SIGNATURE----- --/T7Ys/vy2qfZwzBO-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 22:25:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC6FD7ED for ; Tue, 2 Apr 2013 22:25:34 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7D063F2A for ; Tue, 2 Apr 2013 22:25:34 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id k1so892769oag.19 for ; Tue, 02 Apr 2013 15:25:28 -0700 (PDT) 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=rbGHZdU/xsHmB4lZGwmVgr9oNv/Ph55mgbvs9Y5kkew=; b=eXgY10KQVOruleQqAC3wHWVIiZmSvMoDNcSGaZnrtmDgSK3+tMeBt7g6/fmfzGZkIK +OKH3cj66W8+rlgGx4DFysO5mwrUVUkLTNeNh92Ir1YXDAhbE+roscPnmkaFLeMtGyRQ UKOTRYxaNDFReP+gqvY3athaDfPqJucC4nWEeErho78vAAuPUuFJl55KBOixo9l0l1pf 3jT7PROkdn008J8yhm7hxje+7Zgyn/rZgegDuk23AYVAeLYTk89H46j94qzBpuEtNibQ pMVeZ7U7Qc4PsQSzOPlggHkrspA8BCLAuLNjwuor3aKbocZLOyvv8ngoi4GABw6JT2kk z9dg== MIME-Version: 1.0 X-Received: by 10.182.131.4 with SMTP id oi4mr6433120obb.64.1364941528280; Tue, 02 Apr 2013 15:25:28 -0700 (PDT) Received: by 10.182.161.100 with HTTP; Tue, 2 Apr 2013 15:25:28 -0700 (PDT) In-Reply-To: <80b2deb3359ca04fb784334d60719860@kernel32.de> References: <515289AC.3050204@FreeBSD.org> <936608f069b988fcd58707edb9b4dde0@kernel32.de> <20130327133220.GZ3794@kib.kiev.ua> <24096f01453ab9d0fe898522874cd928@kernel32.de> <941a3c1e7cb49087c8bf941399b1e5ae@kernel32.de> <20130402195223.GU3794@kib.kiev.ua> <80b2deb3359ca04fb784334d60719860@kernel32.de> Date: Wed, 3 Apr 2013 00:25:28 +0200 Message-ID: Subject: Re: panic at serial boot From: Oliver Pinter To: mh@kernel32.de Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:25:34 -0000 On 4/2/13, mh@kernel32.de wrote: > Hi again, > > Am 2013-04-02 21:52, schrieb Konstantin Belousov: >> On Tue, Apr 02, 2013 at 08:23:20PM +0200, mh@kernel32.de wrote: >> >> Try breaking into the debugger and see where it progresses. To do >> this, >> you would need to boot with the 'boot -d' command from the loader >> prompt, >> then do 'w kbd_break_to_debugger 1', then ctrl-alt-esc when you want >> to >> activate the debugger. In the debugger, start with the 'ps' command. >> > > After the beastie menu I went to the loader prompt and did "boot -d". > I was sent to the debugger and did "w kbd_break_to_debugger 1". > > This is the output I get. > > INT 13 08: Success, count = 1, BPT = 0000:0000 > GDB: no debug ports present > KDB: debugger backends: ddbhift limit: 0x82 > KDB: current backend: ddbt15 = f000f859 int1e = f000ef6d > KDB: enter: Boot flags requested debuggerint1e = f000ef6d > [ thread pid 0 tid 0 ] booting... > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> w kbd_break_to_debugger 1 > Symbol not found > > > Where to go from now? A good pointer to documentation is okay too ;) > Sorry if asking too many questions, but although being a FreeBSD user > since 4.0, I never had to debug or been to where I am now. > So in advance another sorry if the question sounds stupid. > > A quick google for 'FreeBSD "w kbd_break_to_debugger 1" "Symbol not > found"' didn't return anything. change the order from console="comconsole,vidconsole" to console="comconsole,vidconsole" in /boot/loader.conf, i think that fixed the problem > > a little helpless regards, > ./Marian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Apr 2 22:37:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 03891A52; Tue, 2 Apr 2013 22:37:07 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id AD35EFC5; Tue, 2 Apr 2013 22:37:06 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id a22so422123qcs.40 for ; Tue, 02 Apr 2013 15:37:05 -0700 (PDT) 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=vV36/0FlHpInnR0xUBcGDtaI1DV3SntgUp9SrlrXjOg=; b=ZGMqzsMVpy8LWEI0ZmsxqJg8KdtCtloZW070DFVZVdbYKYqNO7Ynd8oTlBRAFVTEuJ SMWu9iF6d9qvs9M1MsoQvHKiBeXk3gDfxPKUEwFGtbVNnbKLPqJxD4SL2d4PD90pyK0t 5guYLeRtcOxAiz16oaHJePw8cfGHLohhtoyKtpRGDed8IN9x3ZYZrDvbs2huHMEO/8ps vOruv6P8/1a9Np2wt6aCO39uiRAmbdIThI1vn76gEty2tW6ReOyQf1n4tvCiyz4TY1aG tgXkQl5Tzx19T8KlBjZzwSPBiqU1kottDg/ikZBfVYrxVdtwxlHCieJHuO65xF5pUTi4 jzVQ== MIME-Version: 1.0 X-Received: by 10.229.166.140 with SMTP id m12mr6899600qcy.81.1364942225657; Tue, 02 Apr 2013 15:37:05 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Tue, 2 Apr 2013 15:37:05 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Tue, 2 Apr 2013 15:37:05 -0700 (PDT) In-Reply-To: <20130402085222.GH76816@FreeBSD.org> References: <20130402085222.GH76816@FreeBSD.org> Date: Tue, 2 Apr 2013 15:37:05 -0700 Message-ID: Subject: Re: Anyone have scripts for managing interfaces under new CARP setup? From: Freddie Cash To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:37:07 -0000 On 2013-04-02 1:52 AM, "Gleb Smirnoff" wrote: > > Freddie, > > On Wed, Mar 27, 2013 at 04:10:03PM -0700, Freddie Cash wrote: > F> Just curious if anyone has any scripts for managing fail-over of multiple > F> interfaces using the new CARP setup in 10-CURRENT. > F> > F> Fail-over of all CARP vhids associated with a single interface is working > F> correctly. But, I have 2 separate, physical interfaces running with CARP, > F> and want to fail-over everything if one of the links (or boxes) goes down. > F> > F> Figured I'd ask around to see if anyone has done something like this > F> already. I've been playing with devd.conf settings and logging events, but > F> don't have anything written up to do the actual switch yet. > > Same as for old CARP, you can achieve behavior when a box with lower > advskew yields master status to a second one, setting: > > sysctl net.inet.carp.preempt=1 > > If an interface on the master has proper link state notification to the > kernel, then once the interface goes down, the advskew on the box will be > demoted and backup box will preempt it. That's how I have things set and it wasn't switching the 2nd interface. However, I think that may be due to the IPFW rules on one interface blocking CARP multicast packets on that interface, while they were going through correctly on the 2nd interface. I'll see if I can schedule a manual test later this week now that IPFW is configured correctly. Thanks for the confirmation of things are supposed to work. From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 01:28:01 2013 Return-Path: Delivered-To: freebsd-current@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 895AAAF0 for ; Wed, 3 Apr 2013 01:28:01 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3BAA26 for ; Wed, 3 Apr 2013 01:28:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=72RxW7sTr5XZpfRaDQk5a80xtNMGT6l/9OqodwtYMsw=; b=TCte3/4ALbGM2J00lK+Kg0Dp+82lnxoi8Oj1vxIyKU00YVFk9sBCNj+jU04Q8OmHPGwE7//cD76JBqzE6e8fLfJSy5mBYJnCy8IjDw6GG72++5vHVDn98FndX7XjmiCdo1sYO/j7Ow0AD+iRlCT+WpnsPI434I/XivA7bTzu/Og=; Received: from localhost.lerctr.org ([127.0.0.1]:18607 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UNCUa-000OSv-2H for freebsd-current@freebsd.org; Tue, 02 Apr 2013 20:28:00 -0500 Received: from cpe-72-182-19-162.austin.res.rr.com ([72.182.19.162]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 02 Apr 2013 20:27:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Apr 2013 20:27:52 -0500 From: Larry Rosenman To: Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT In-Reply-To: <515B4CFA.9080706@FreeBSD.org> References: <5159EF29.6000503@FreeBSD.org> <515B4CFA.9080706@FreeBSD.org> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.5 X-Spam-Score: -5.2 (-----) X-LERCTR-Spam-Score: -5.2 (-----) X-Spam-Report: SpamScore (-5.2/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.328 X-LERCTR-Spam-Report: SpamScore (-5.2/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.328 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 01:28:01 -0000 On 2013-04-02 16:26, Martin Matuska wrote: > On 1. 4. 2013 22:33, Martin Matuska wrote: >> This error seems to be limited to sending deduplicated streams. Does >> sending without "-D" work ok? This might be a vendor error as well. >> >> On 1.4.2013 20:05, Larry Rosenman wrote: >>> Re-Sending. Any ideas, guys/gals? >>> >>> This really gets in my way. >>> > This may be also related to: > http://www.freebsd.org/cgi/query-pr.cgi?pr=176978 Looks close. I'll try without -D in the next few days. (I'm in the process of packing our house, so round tuit's have been scarce). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 05:12:11 2013 Return-Path: Delivered-To: freebsd-current@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 B04E2728 for ; Wed, 3 Apr 2013 05:12:11 +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 DE3A2345 for ; Wed, 3 Apr 2013 05:12:10 +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 IAA17893; Wed, 03 Apr 2013 08:12:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UNFzS-000FAU-VC; Wed, 03 Apr 2013 08:12:06 +0300 Message-ID: <515BBA28.1020408@FreeBSD.org> Date: Wed, 03 Apr 2013 08:12:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: deeptech71 Subject: Re: poweroff (shutdown -p) is broken References: <515B6677.2080402@gmail.com> In-Reply-To: <515B6677.2080402@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 05:12:11 -0000 on 03/04/2013 02:15 deeptech71 said the following: > As of r248872, my system, when ordered to power off, stalls at the "Uptime: > [...]" message. Before that revision, the "Uptime" message would be followed by > several additional messages -- something related to "usb controllers" -- before > powering off. You need to break into the ddb and examine where exactly the shutdown thread is stuck. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 07:06:33 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65626FE; Wed, 3 Apr 2013 07:06:33 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 26CC88F1; Wed, 3 Apr 2013 07:06:32 +0000 (UTC) Received: from jh (a91-153-115-208.elisa-laajakaista.fi [91.153.115.208]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 720192167EF; Wed, 3 Apr 2013 10:06:23 +0300 (EEST) Date: Wed, 3 Apr 2013 10:06:23 +0300 From: Jaakko Heinonen To: Andriy Gapon Subject: Re: poweroff (shutdown -p) is broken Message-ID: <20130403070622.GB47068@jh> References: <515B6677.2080402@gmail.com> <515BBA28.1020408@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515BBA28.1020408@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: deeptech71 , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 07:06:33 -0000 On 2013-04-03, Andriy Gapon wrote: > on 03/04/2013 02:15 deeptech71 said the following: > > As of r248872, my system, when ordered to power off, stalls at the "Uptime: > > [...]" message. Before that revision, the "Uptime" message would be followed by > > several additional messages -- something related to "usb controllers" -- before > > powering off. > > You need to break into the ddb and examine where exactly the shutdown thread is > stuck. I can confirm the problem. It hangs while trying to spin down an ada(4) disk. Tracing pid 1 tid 100002 td 0xc72bbc00 sched_switch(c72bbc00,0,104,1b5,c6946188,...) at sched_switch+0x456/frame 0xc6ec4a98 mi_switch(104,0,c0f36d00,1f5,5c,...) at mi_switch+0x20b/frame 0xc6ec4ac8 sleepq_switch(c72bbc00,0,c0f36d00,26b,0,...) at sleepq_switch+0x1a5/frame 0xc6ec4af0 sleepq_wait(c72b573c,5c,c0d92504,0,0,...) at sleepq_wait+0x6b/frame 0xc6ec4b0c _sleep(c72b573c,c732c974,5c,c0d92504,0,...) at _sleep+0x3f0/frame 0xc6ec4b64 cam_periph_getccb(c72b5700,480,c0d94762,c0,ea,...) at cam_periph_getccb+0xd7/frame 0xc6ec4b9c adaspindown(c6ec4c2c,c0a130b6,0,4008,c0f306e7,...) at adaspindown+0xf1/frame 0xc6ec4bcc adashutdown(0,4008,c0f306e7,1bc,c09e261a,...) at adashutdown+0x29/frame 0xc6ec4bd4 kern_reboot(4008,0,c0f306e7,be,bfbfd9a0,...) at kern_reboot+0x706/frame 0xc6ec4c2c sys_reboot(c72bbc00,c6ec4ccc,c72bbcb4,c12164a0,202,...) at sys_reboot+0x6c/frame 0xc6ec4c4c syscall(c6ec4d08) at syscall+0x2ab/frame 0xc6ec4cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc6ec4cfc --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805c0a7, esp = 0xbfbfd86c, ebp = 0xbfbfd948 --- -- Jaakko From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 09:26:13 2013 Return-Path: Delivered-To: freebsd-current@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 75C95ACE; Wed, 3 Apr 2013 09:26:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id A83F3F3D; Wed, 3 Apr 2013 09:26:12 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id ik5so674623bkc.34 for ; Wed, 03 Apr 2013 02:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jaEBGAJH3UakwCfUj8P0wDHH/j7krKpd3n7CgCXtK3M=; b=uZD8Yj0cZ9rmGppdRz0SMkJxiFY6xu5M8xpJw9fY7RQvQLYcGla+sF2VeQKGO0/J6x zCpvSUYIDnbJx0/5LtY4TcxJlPRzoQVurOYmc0WzhxXJ3VN8sSSSPosNhQiJ5QVxIo7s delOpq19Gbf28JxOkMuUvTxLWwf24gOTqQ/ohZj5fq9cthZQqo/zyJI0GzgCm8OCdimw ShTmpgpXDBw3lF7AwnLw8lUs0Ec39fjAJG2f6J1N0+k9StotyPWdQHm3paG2TmsSSWT1 9FEikEZWF7S+jEr/FUYKb65vfoCuhiKcCYCMRgh1row0khULh9qIOuqXmxKwgZorI0aR mdoQ== X-Received: by 10.205.103.67 with SMTP id dh3mr670862bkc.19.1364981171605; Wed, 03 Apr 2013 02:26:11 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id o2sm2196418bkv.3.2013.04.03.02.26.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 02:26:10 -0700 (PDT) Sender: Alexander Motin Message-ID: <515BF5AE.4050804@FreeBSD.org> Date: Wed, 03 Apr 2013 12:26:06 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> In-Reply-To: <515B25D8.7050902@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 09:26:13 -0000 On 02.04.2013 21:39, Matthias Andree wrote: > Am 31.03.2013 23:02, schrieb Scott Long: > >> So what I hear you and Matthias saying, I believe, is that it should be easier to >> force disks to fall back to non-NCQ mode, and/or have a more responsive >> black-list for problematic controllers. Would this help the situation? It's hard to >> justify holding back overall forward progress because of some bad controllers; >> we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, >> enough to make up a sizable percentage of the internet's traffic, and we see no >> problems. How can we move forward but also take care of you guys with >> problematic hardware? > > Well, I am running the driver fine off of my WD Caviar RE3 disk, and the > problematic drive also works just fine with Windows and Linux, so it > must be something between the problematic drive and the FreeBSD driver. > > I would like to see any of this, in decreasing order of precedence: > > - debugged driver > > - assistance/instructions on helping how to debug the driver/trace NCQ > stuff/... (as in Jeremy Chadwick's followup in this same thread - this > helps, I will attempt to procure the required information; "back then", > reducing the number of tags to 31 was ineffective, including an error > message and getting a value of 32 when reading the setting back) Unfortunately, I don't know how to debug that. Command timeouts reported on the lists before are the kind of errors that are most difficult to diagnose since the controller gives no information to do that. We just see that sent commands are no longer completing. May be it is some incompatibility of specific drive and HBA firmwares, triggered by some innocent specifics of our ATA stack, GEOM or filesystems implementation. All I can propose is to try to identify such cases and add some quirks to workaround it, like disabling NCQ or limiting number of tags. I am not sure what else can we do about it without some controlled lab environment with affected hardware and SATA analyzer. > - "user-space" contingency features, such as letting camcontrol limit > the number of open NCQ tags, or disable NCQ, either on a per-drive basis I've merged support for that to 8/9-STABLE about 9 months ago: `camcontrol tags ada0 -v -N X` should change number of simultaneously used tags, `camcontrol negotiate ada0 -T (en|dis)able` should enable/disable use of NCQ. I just did some tests on HEAD and these commands seems like working. If you can reproduce the problem, it would be nice to collect information how these changes affect it. > I am capable of debugging C - mostly with gdb command-line, and > graphical Windows IDEs - but am unfamiliar with FreeBSD kernel > debugging. If necessary, I can pull up a second console, but the PC that > is affected is legacy-free, so serial port only works through a > serial/USB converter. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 09:32:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D92AF0E for ; Wed, 3 Apr 2013 09:32:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id E5E51FBB for ; Wed, 3 Apr 2013 09:32:11 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id q16so683679bkw.41 for ; Wed, 03 Apr 2013 02:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VS/471TWFfNJDKp5fpjAo5B+lM2alqjCgfjHZEExWBY=; b=vdaswqagyEp5kRSXCeD+SiHZAO17Te8xFna9lZH4lVe2T7LOxUSffMTdpW6NEjx6pR z0upSGaqYw6aTv26AZNE+RTuE3neCPrGDyptLfdJmYjvDIjdJIvyEwfE+9mRWrXMWVHT KvorJh1KNRWhf7bIDoTmxBMPHZYVSuFlgny1cJ4aufrhGuuAAFZkru/1yKUp5DoR4eMe t7YD0Ts0IW97YXdgy3u4ryT1qfJQ1lHZPCchxCA7zkYzrCRD96C2U7Orr1CaCYsS3AvM 0SSeG+TA6GvI9aO914rBlAMpnZdw2fpuc0j7U77914BB1CfprHUa3YLVNzpRPZ0XPipH /Tgw== X-Received: by 10.204.227.143 with SMTP id ja15mr700099bkb.5.1364981530848; Wed, 03 Apr 2013 02:32:10 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id w6sm2201032bkz.17.2013.04.03.02.32.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 02:32:09 -0700 (PDT) Sender: Alexander Motin Message-ID: <515BF716.6000403@FreeBSD.org> Date: Wed, 03 Apr 2013 12:32:06 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: deeptech71 Subject: Re: poweroff (shutdown -p) is broken References: <515B6677.2080402@gmail.com> In-Reply-To: <515B6677.2080402@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 09:32:12 -0000 On 03.04.2013 02:15, deeptech71 wrote: > As of r248872, my system, when ordered to power off, stalls at the > "Uptime: [...]" message. Before that revision, the "Uptime" message > would be followed by several additional messages -- something related to > "usb controllers" -- before powering off. Could you give any more information about your system and the problem? What disks and controllers do you have and which drivers do you use? Full verbose kernel messages from boot up to the hang (if you can set up serial console) could be interesting. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 09:37:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E805F9 for ; Wed, 3 Apr 2013 09:37:50 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from nm3-vm4.bt.bullet.mail.ir2.yahoo.com (nm3-vm4.bt.bullet.mail.ir2.yahoo.com [212.82.99.202]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB7228 for ; Wed, 3 Apr 2013 09:37:48 +0000 (UTC) Received: from [212.82.98.44] by nm3.bt.bullet.mail.ir2.yahoo.com with NNFMP; 03 Apr 2013 09:35:47 -0000 Received: from [46.228.39.173] by tm5.bt.bullet.mail.ir2.yahoo.com with NNFMP; 03 Apr 2013 09:35:47 -0000 Received: from [127.0.0.1] by smtp114.bt.mail.ir2.yahoo.com with NNFMP; 03 Apr 2013 09:35:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=s1024; t=1364981747; bh=ubt9/to01HmU1DzPmQxTABeO2RuKpfLRtb5lc+v6wPs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=xTWUK+iVPiDduN/7rqAxyIyI8rblEeEAfRDjpGvFfY95fFx/Z9odzDgZNeaQ8HCodJ5Uns9bOV3Rc/7a8rhyDATk5fTatE/nRnGsz+vJ2IKb9E49cZC3nnCTD5PViQS75xKtyONXM6ZZ7DHlG62VWSECRlQFkYh/8G1+A2Veo1Y= X-Yahoo-Newman-Id: 325593.76231.bm@smtp114.bt.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0gy_50QVM1nIMeRlYFkjv5IcOm.wu5pt7daVFdp.lMb45Di 88A9nfmJ1.7OTZ1dxPLS7lkhoWD0yNflKTcpduvMwX6wZwDFPwWA0DcQ.3c5 ts3zpSyKiLylNMQwXsYiNbXBN_0pTdq0hb7C6OdfhX4BbMNe591ow46cksDh bduKFfvqbyvk_KfaTqLHyBB38mHaNLVsm.wNpejLYrI4jNTYIWk0n0_k1FRB GTs8dAgloe4d5C9tPhkAmR4sIJnlLrMqaj_3kne6mmzzCtga6Xwg2D6GoR7r 7wrvdnelH1DXX8xqxCDy.fncAfVqSK6KAgbvASr_LcvZH4AdLE9.gwMCcdHe auQbMMdwS_mQr6A_FuNBZA4CvtWr9iCN8hcOeCV31ZkEVZeRi1K16nNB54KA THx__Tp8BueywiME.sIcejorNqfNqWZjg5G0qXJEJWpdAq6VgrOm6He3YgNO PEWfBdaL5DSkdFFttuAwP0KROUfNj2AuURTVm.971J3Fuk8fjUzgqI_kyf.7 ij60gK4pYdg-- X-Yahoo-SMTP: IZRlAYqswBDptUXTX.cYc1l2h3YNYE0xlrpi4wWl.OMHg4FYv7uDnfZx6kQf X-Rocket-Received: from ThomasPC (Thomas.Sparrevohn@86.133.48.124 with login) by smtp114.bt.mail.ir2.yahoo.com with SMTP; 03 Apr 2013 09:35:47 +0000 UTC From: "Thomas Sparrevohn" To: "'Waitman Gobble'" , References: <1364714701.20926@da3m0n8t3r.com> In-Reply-To: <1364714701.20926@da3m0n8t3r.com> Subject: RE: rebooting nvidia + keyboard issues Date: Wed, 3 Apr 2013 10:35:47 +0100 Message-ID: <00b501ce304e$9f9a1260$dece3720$@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDI/zQsIOkRhwEiHHDhdabw7ZYLphaVGoA Content-Language: en-gb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 09:37:50 -0000 I have had the same problem - it seems like a "sysctl" call provokes a overrun in a strlen call. It is not reproducible with a GENERIC kernel with debugging in my case. However a simple workaround is to compile nvidia-driver with gcc. -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Waitman Gobble Sent: 31 March 2013 08:25 To: current@freebsd.org Subject: rebooting nvidia + keyboard issues Hi, After updating my machine tonight with > uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248937: Sat Mar 30 21:53:14 PDT 2013 root@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 I noticed the machine rebooting randomly every 20 seconds to 5 minutes. Disabling the nvidia driver seems to fix the problem, and I was able to update after applying ports/177459 patch. The updated nvidia driver seems to have solved the rebooting issue. (it could (also?) be related to linux.ko?) If people are using the nvidia driver and are experiencing a constant reboot issue, it might be good to pop in that patch ASAP. The problem I am noticing now is keyboard related. Booting to single user mode, I cannot type anything at the login prompt with an attached USB keyboard. However in single user mode a PS2 keyboard will allow me to login. I would not say it's not working.. the keyboard functions fine until hitting the login prompt. There are no errors and everything appears to be working fine, however I cannot login. Numlock key lights on and off when pressed. Also, if I boot into multi user mode, I cannot type anything at the login prompt when a PS2 keyboard is attached. But the USB keyboard will work in mutli user mode. Thank you, -- Waitman Gobble San Jose California USA From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 11:21:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D73CC6F for ; Wed, 3 Apr 2013 11:21:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id C6075751 for ; Wed, 3 Apr 2013 11:21:56 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id jm2so750006bkc.2 for ; Wed, 03 Apr 2013 04:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TDLNBKxWUhrbeEoVrT/OjsRJdIPcXqNSajLTpEx61Pw=; b=x4fjyj1Beqj0dP1tGsM2bZ4aXMde+Q4ybbzbMPbD29L2txQ/wo8wZbW2nW2KCF67j9 1quS11WQff79m223qBNLgQ6WRhLoIwcCKNIIM4srdUyjNrLPMsfKQei4/IomJgIylx3c ummuqFQ/WhR6wM7GazOmII4u2jwHBmc1O1XEZTJIpbkHkR9UHTDO4UuashHw+r8mKb4K 8HyODlGBFtZpr6i2gbkk9jBzTihViHW5is0D0slN8LnYJz2IPYeWbVV6UAqMyPETq6i0 wiqrJ7+oVFf/zRRHxuT0Oeml7Bdf8VNZF9Q89PTvo6mxI1T5+EW52LvWDy6+JLWwuBgB TwPQ== X-Received: by 10.204.173.142 with SMTP id p14mr937729bkz.115.1364988115832; Wed, 03 Apr 2013 04:21:55 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id cr6sm2519575bkb.2.2013.04.03.04.21.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 04:21:54 -0700 (PDT) Sender: Alexander Motin Message-ID: <515C10CF.6030201@FreeBSD.org> Date: Wed, 03 Apr 2013 14:21:51 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: deeptech71 Subject: Re: poweroff (shutdown -p) is broken References: <515B6677.2080402@gmail.com> <515BF716.6000403@FreeBSD.org> In-Reply-To: <515BF716.6000403@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 11:21:57 -0000 On 03.04.2013 12:32, Alexander Motin wrote: > On 03.04.2013 02:15, deeptech71 wrote: >> As of r248872, my system, when ordered to power off, stalls at the >> "Uptime: [...]" message. Before that revision, the "Uptime" message >> would be followed by several additional messages -- something related to >> "usb controllers" -- before powering off. > > Could you give any more information about your system and the problem? > What disks and controllers do you have and which drivers do you use? > Full verbose kernel messages from boot up to the hang (if you can set up > serial console) could be interesting. I was able to reproduce the problem on legacy mode SATA channel, shared by two disks. I think recent commit just triggered some existing bug. I will start further debugging immediately to fix it ASAP. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 11:33:56 2013 Return-Path: Delivered-To: freebsd-current@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 907DE66A for ; Wed, 3 Apr 2013 11:33:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 245FE815 for ; Wed, 3 Apr 2013 11:33:55 +0000 (UTC) Received: by mail-bk0-f49.google.com with SMTP id w12so757011bku.8 for ; Wed, 03 Apr 2013 04:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lyoePWaH5/Evv8pqB61HWylLPnkPrOiYoKNStf2ryVw=; b=IB/q0AuJrUPVXRFNUoIpVgMjqGXqgxLoDjRz1FRKcStACJlSyO+S+4Ih9sdrqmm1CI JI+WY4ABfZaq16hueTEWwy/i+WnZKFBCRu/36Z+XalW+g+Pkd5J6Bey9E//IR6btcQLx GU/4uepnU7lfwAwXdSfI10U+w78B4iCmcMn7XhqbB0UmRz54mjk+rzIFYNhrpWFDwc7Z wxlQLYFwckokzAzj1swh3MzITBktRXmzSJnk2rIS0NC3fF6To10d1hPAKJRgqAl9E7Qb wXILv40m0ycTeo6h/w8wntH5d1wPwkvoePjkHvTnuaQlpSNeZUTo6Sum4m5wJJL0SZML uY2g== X-Received: by 10.205.68.129 with SMTP id xy1mr979041bkb.136.1364988835133; Wed, 03 Apr 2013 04:33:55 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id x18sm2551881bkw.4.2013.04.03.04.33.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 04:33:54 -0700 (PDT) Sender: Alexander Motin Message-ID: <515C139E.9040403@FreeBSD.org> Date: Wed, 03 Apr 2013 14:33:50 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: deeptech71 Subject: Re: poweroff (shutdown -p) is broken References: <515B6677.2080402@gmail.com> <515BF716.6000403@FreeBSD.org> <515C10CF.6030201@FreeBSD.org> In-Reply-To: <515C10CF.6030201@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 11:33:56 -0000 On 03.04.2013 14:21, Alexander Motin wrote: > On 03.04.2013 12:32, Alexander Motin wrote: >> On 03.04.2013 02:15, deeptech71 wrote: >>> As of r248872, my system, when ordered to power off, stalls at the >>> "Uptime: [...]" message. Before that revision, the "Uptime" message >>> would be followed by several additional messages -- something related to >>> "usb controllers" -- before powering off. >> >> Could you give any more information about your system and the problem? >> What disks and controllers do you have and which drivers do you use? >> Full verbose kernel messages from boot up to the hang (if you can set up >> serial console) could be interesting. > > I was able to reproduce the problem on legacy mode SATA channel, shared > by two disks. I think recent commit just triggered some existing bug. I > will start further debugging immediately to fix it ASAP. I'm sorry, it was my fault. Legacy channels appeared more sensitive to the cause of the issue, while more modern SATA and SAS controllers I've tested hidden it. r249048 should fix the problem. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 17:03:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 53D94767 for ; Wed, 3 Apr 2013 17:03:17 +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 D705B90 for ; Wed, 3 Apr 2013 17:03:16 +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 r33H3CMi073525; Wed, 3 Apr 2013 20:03:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r33H3CMi073525 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r33H3C33073524; Wed, 3 Apr 2013 20:03:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Apr 2013 20:03:12 +0300 From: Konstantin Belousov To: mh@kernel32.de Subject: Re: panic at serial boot Message-ID: <20130403170312.GB3794@kib.kiev.ua> References: <515289AC.3050204@FreeBSD.org> <936608f069b988fcd58707edb9b4dde0@kernel32.de> <20130327133220.GZ3794@kib.kiev.ua> <24096f01453ab9d0fe898522874cd928@kernel32.de> <941a3c1e7cb49087c8bf941399b1e5ae@kernel32.de> <20130402195223.GU3794@kib.kiev.ua> <80b2deb3359ca04fb784334d60719860@kernel32.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZuTDfskvPTkvx6xU" Content-Disposition: inline In-Reply-To: <80b2deb3359ca04fb784334d60719860@kernel32.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:03:17 -0000 --ZuTDfskvPTkvx6xU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 02, 2013 at 11:06:06PM +0200, mh@kernel32.de wrote: > Hi again, >=20 > Am 2013-04-02 21:52, schrieb Konstantin Belousov: > > On Tue, Apr 02, 2013 at 08:23:20PM +0200, mh@kernel32.de wrote: > > > > Try breaking into the debugger and see where it progresses. To do=20 > > this, > > you would need to boot with the 'boot -d' command from the loader=20 > > prompt, > > then do 'w kbd_break_to_debugger 1', then ctrl-alt-esc when you want=20 > > to > > activate the debugger. In the debugger, start with the 'ps' command. > > >=20 > After the beastie menu I went to the loader prompt and did "boot -d". > I was sent to the debugger and did "w kbd_break_to_debugger 1". >=20 > This is the output I get. >=20 > INT 13 08: Success, count =3D 1, BPT =3D 0000:0000 = =20 > GDB: no debug ports present > KDB: debugger backends: ddbhift limit: 0x82 > KDB: current backend: ddbt15 =3D f000f859 int1e =3D f000ef6d > KDB: enter: Boot flags requested debuggerint1e =3D f000ef6d > [ thread pid 0 tid 0 ] booting... > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> w kbd_break_to_debugger 1 > Symbol not found It is kdb_break_to debugger. Sorry. --ZuTDfskvPTkvx6xU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRXGDPAAoJEJDCuSvBvK1BvpUQAJ53wAoPzF8CWYK3OID0U8ux rXY7wWwHGo9aJD3F6nC06Qc8ZbXKtFxJF5av7vdHXsXHF3nPIhXZYXFvIc3nHuuL +qn58hkWst/ewBGt3c2X9ZoL6bbDPdcK2g4csLuUlA/L8Dsjdf+3IYZhSx/t3NAV YKE7fHxmyeA9s23ZyosdHdf+gQ+GBWmsqt6v47WSb5HgkvJbsAm4fk4gqLePWEdX BKN6nmSj4UvD1V7li+dF4oaZm214doXIqgs8JpiG2hwvNOafB1nXUlLR98Fh8TjN CggKT8FR0duOP18ogqdtSqX28SRZHm9lLJ6vj125+ApyqGldPPGgtvq8WnK/kuhM w7GUi3NzcyhifApD7YfjKb0ctTAs+gSv+Yf+zL2VIYmn9GcsAz9g0EPJIjJ2dm6T duOmEyDyOMzKGEpHmt2IZBVJQB5pfjhKmqFIDDnSgr7ut1fRqVuWkhT1n2Y7LLc1 a4RxlhduqU5FENkFkhF3j+qUAu1rE6RbuYUnsl1BywvvROBroo92XXZdEeuEXih2 c8FXVqWX42+upkTHh+aLuJtnM0HncuTqjYJ+zznrr5bQ+PdNg24fN9zoHBanEgJE DGUKZuYhAYNCksYAzknVJkb5j4GQbrBv361p7D5Udkc3YPM9qkR04zDNE5r8yPD9 C5dNsJPW/t/qVIgUY1Eq =GlEe -----END PGP SIGNATURE----- --ZuTDfskvPTkvx6xU-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 17:50:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 77CC12C4 for ; Wed, 3 Apr 2013 17:50:49 +0000 (UTC) (envelope-from daemon@dx.burplex.com) Received: from dx.burplex.com (dx.burplex.com [50.197.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6759E2B1 for ; Wed, 3 Apr 2013 17:50:49 +0000 (UTC) Received: by dx.burplex.com (Postfix, from userid 1) id 7303C36F4856; Wed, 3 Apr 2013 10:50:43 -0700 (PDT) To: Subject: Re: RE: rebooting nvidia + keyboard issues From: Waitman Gobble X-UUID-HOR: 5c2f9e47-9c43-11e2-a35d-902b34a86bc3 Message-Id: <20130403175043.7303C36F4856@dx.burplex.com> Date: Wed, 3 Apr 2013 10:50:43 -0700 (PDT) Cc: Thomas Sparrevohn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:50:49 -0000 On Wed, 3 Apr 2013 10:35:47 +0100, "Thomas Sparrevohn" wrote: > >I have had the same problem - it seems like a "sysctl" call provokes a >overrun in a strlen call. It is not reproducible with a GENERIC kernel with >debugging in my case. However a simple workaround is to compile >nvidia-driver with gcc. > >-----Original Message----- >From: owner-freebsd-current@freebsd.org >[mailto:owner-freebsd-current@freebsd.org] On Behalf Of Waitman Gobble >Sent: 31 March 2013 08:25 >To: current@freebsd.org >Subject: rebooting nvidia + keyboard issues > >Hi, > >After updating my machine tonight with >> uname -a >FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248937: Sat Mar >30 21:53:14 PDT 2013 root@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA >amd64 > >I noticed the machine rebooting randomly every 20 seconds to 5 minutes. >Disabling the nvidia driver seems to fix the problem, and I was able to >update after applying ports/177459 patch. The updated nvidia driver seems to >have solved the rebooting issue. (it could (also?) be related to linux.ko?) >If people are using the nvidia driver and are experiencing a constant reboot >issue, it might be good to pop in that patch ASAP. > >The problem I am noticing now is keyboard related. Booting to single user >mode, I cannot type anything at the login prompt with an attached USB >keyboard. However in single user mode a PS2 keyboard will allow me to login. >I would not say it's not working.. the keyboard functions fine until hitting >the login prompt. There are no errors and everything appears to be working >fine, however I cannot login. Numlock key lights on and off when pressed. > >Also, if I boot into multi user mode, I cannot type anything at the login >prompt when a PS2 keyboard is attached. But the USB keyboard will work in >mutli user mode. > >Thank you, > >-- >Waitman Gobble >San Jose California USA > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Thank you for the information, I'll give it a try and see what happens. I noticed two other ports that don't even seem to build with clang, but generally everything else seems to be working. I noticed a previous message from a day or two ago regarding gcc and nvidia, but I lost the message. I'm in the middle of moving my mail system to a 'more' horizontally based system, so it's kind of like building a boat around you while floating down a river. Anyhow, I read an article this morning about AMD opening up drivers, that sounds cool, going to check it out. -- Waitman Gobble San Jose California USA +1.5108307875 From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 17:52:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 42466406 for ; Wed, 3 Apr 2013 17:52:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id D11A92D6 for ; Wed, 3 Apr 2013 17:52:47 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hj8so1808706wib.8 for ; Wed, 03 Apr 2013 10:52:47 -0700 (PDT) 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=yKgir8Z+n9iI46H+WFolAgJvPGOZu5PRx8CcWDo9fKM=; b=OQXrRFzAlIVDn1+2XKw5sLcMfBQAbk5+59w9m9jCGmhS7p+4B1AvveX8HXLmQ7HaE2 +KGrEPUW0IglBJqxRKA+vgSFUr1C1oxeb6MqyXGeXyqii1tAC0q70KJlhOGTzwPuggJp CnKbSRFP6/SqybV7xYwpFLzGOc7MlWUQkUUMBoE6eUxRshrmV0m31mJJ4mm/HyWfSmJU 0HGpkBRw8cK6XMg8xV3hIkprou5ABBwtzwaDslHxn8Dxr9w+uhDHT+M3ZUkp1BdofthX d4KMFMhLvvXhYgowveHY0F3C0/U51o5czoDt7uXdiK0fhBQHDo/CmRt9/cFDy9DfZLF/ 6cDw== MIME-Version: 1.0 X-Received: by 10.180.188.3 with SMTP id fw3mr4175921wic.33.1365011566877; Wed, 03 Apr 2013 10:52:46 -0700 (PDT) Received: by 10.216.243.7 with HTTP; Wed, 3 Apr 2013 10:52:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 10:52:46 -0700 Message-ID: Subject: Re: Patch ath3kfw to accept other device ids; blacklist ath bluetooth devices From: Adrian Chadd To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:52:48 -0000 Hi, Here you go: http://people.freebsd.org/~adrian/ath/20130401-ath-bluetooth.diff The ath3k driver in linux does a fair bit more than ath3kfw: * if it's a subset of chips that needs firmware, it squirts ath3k-1.fw onto it * there's a subset of chips that get ROM/RAM patches; so if it's one of those, squeeze the patch on; * it also will configure the AR3012 NIC between "config" and "normal" mode when it's loading in those patches. So it's likely that for full support, we're going to have to port over this functionality and throw those firmware / patch / config files somewhere to be uploaded when the relevant device is attached. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 18:07:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E671FB3 for ; Wed, 3 Apr 2013 18:07:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id AE1C93D7 for ; Wed, 3 Apr 2013 18:07:56 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id d7so1373738wer.26 for ; Wed, 03 Apr 2013 11:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jsGjyryWhmQpRdsbx0YdfvoEQvETJfPYMeoPcQdiq1E=; b=rb0cwVwXxTfG/K9VJP0kdmdaIiB6upFcK0Zseop28zZvo2SPE03zdOuM5xEedcEqlD TTuS4RWXz8FggRMw+ikQRBOsDaPjtdcdYng1Wikc5CLmXkqNR1pTMXdi9ybiFokB+HXU fFBgNHKXqgOspYJbrlvKjAgKHNuH2jNDc3QArj1LPnzx1RlkV/8/O+y6TVtvXKrp6QnN hCcDpOtqV27Gav2vXs+k9xrfHlHRK5XMQegjYL2prkZnSMii/K5seUvjVr4nxZ8P+JrC jGwQNZBwv61ilLARRY17meXrVZkMArwW44gFfSEFNe1IkrnM4FJIXONkxvafh+JSckcP VaRw== MIME-Version: 1.0 X-Received: by 10.194.119.33 with SMTP id kr1mr4417887wjb.36.1365012475776; Wed, 03 Apr 2013 11:07:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.243.7 with HTTP; Wed, 3 Apr 2013 11:07:55 -0700 (PDT) In-Reply-To: <20130403175043.7303C36F4856@dx.burplex.com> References: <20130403175043.7303C36F4856@dx.burplex.com> Date: Wed, 3 Apr 2013 11:07:55 -0700 X-Google-Sender-Auth: 9hYV2Q43B4q0eQ8esb5QHrwcV_w Message-ID: Subject: Re: RE: rebooting nvidia + keyboard issues From: Adrian Chadd To: Waitman Gobble Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Sparrevohn , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:07:57 -0000 Hi, can you guys please ensure a PR is filed with all the information you've just included? the clang team would likely love to have this much information in a bug rep= ort. Thanks! adrian On 3 April 2013 10:50, Waitman Gobble wrote: > On Wed, 3 Apr 2013 10:35:47 +0100, "Thomas Sparrevohn" wrote: >> >>I have had the same problem - it seems like a "sysctl" call provokes a >>overrun in a strlen call. It is not reproducible with a GENERIC kernel wi= th >>debugging in my case. However a simple workaround is to compile >>nvidia-driver with gcc. >> >>-----Original Message----- >>From: owner-freebsd-current@freebsd.org >>[mailto:owner-freebsd-current@freebsd.org] On Behalf Of Waitman Gobble >>Sent: 31 March 2013 08:25 >>To: current@freebsd.org >>Subject: rebooting nvidia + keyboard issues >> >>Hi, >> >>After updating my machine tonight with >>> uname -a >>FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248937: Sat = Mar >>30 21:53:14 PDT 2013 root@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA >>amd64 >> >>I noticed the machine rebooting randomly every 20 seconds to 5 minutes. >>Disabling the nvidia driver seems to fix the problem, and I was able to >>update after applying ports/177459 patch. The updated nvidia driver seems= to >>have solved the rebooting issue. (it could (also?) be related to linux.ko= ?) >>If people are using the nvidia driver and are experiencing a constant reb= oot >>issue, it might be good to pop in that patch ASAP. >> >>The problem I am noticing now is keyboard related. Booting to single user >>mode, I cannot type anything at the login prompt with an attached USB >>keyboard. However in single user mode a PS2 keyboard will allow me to log= in. >>I would not say it's not working.. the keyboard functions fine until hitt= ing >>the login prompt. There are no errors and everything appears to be workin= g >>fine, however I cannot login. Numlock key lights on and off when pressed. >> >>Also, if I boot into multi user mode, I cannot type anything at the login >>prompt when a PS2 keyboard is attached. But the USB keyboard will work in >>mutli user mode. >> >>Thank you, >> >>-- >>Waitman Gobble >>San Jose California USA >> >>_______________________________________________ >>freebsd-current@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >> > > Thank you for the information, I'll give it a try and see what happens. I= noticed two other ports that don't even seem to build with clang, but gene= rally everything else seems to be working. > > I noticed a previous message from a day or two ago regarding gcc and nvid= ia, but I lost the message. I'm in the middle of moving my mail system to a= 'more' horizontally based system, so it's kind of like building a boat aro= und you while floating down a river. > > Anyhow, I read an article this morning about AMD opening up drivers, that= sounds cool, going to check it out. > > -- > Waitman Gobble > San Jose California USA > +1.5108307875 > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 18:16:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E58F3472 for ; Wed, 3 Apr 2013 18:16:54 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-da0-x22c.google.com (mail-da0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id C092F617 for ; Wed, 3 Apr 2013 18:16:54 +0000 (UTC) Received: by mail-da0-f44.google.com with SMTP id z20so773241dae.31 for ; Wed, 03 Apr 2013 11:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=ziNa8QwiAUfbdwSN9zZxswgkfHq0N8rSxSYosPbRg+k=; b=iKV2K6kxNMsw+gCgBvIb/0P/OIFolXXSi9N/cBECQiMuic4QQFulA4U8swn6ENoBLq 67ARz9vQPBCFk+VO5Wkvj8svrq2KOIVUKZLMXqDGy5BAkd8RymZ8r2VIlDPqVOctqswM O+jWu212/mr7B+YRqsbOH+tkMp+A8k2CdR5sREqYwg75y5s8XltJbVhQAMDwZI4ONrIT 25AjETn/w8hxUS5Bi14SVkqWtJ6aErZi6mznrbg//cJl9qgyBKe93A20l+e5JR4tw6x/ TnaD3hLM5+y1Gd/S+tyAIs89kHGBke5AyBSNAKUni5eg8RgcL0PCMpPn0PVaQPO3SJt3 f/oA== X-Received: by 10.66.164.198 with SMTP id ys6mr4773674pab.77.1365013014611; Wed, 03 Apr 2013 11:16:54 -0700 (PDT) Received: from [10.52.223.122] (mobile-166-137-177-095.mycingular.net. [166.137.177.95]) by mx.google.com with ESMTPS id pa2sm6971057pac.9.2013.04.03.11.16.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 11:16:53 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: maksim yevmenkin Subject: Re: Patch ath3kfw to accept other device ids; blacklist ath bluetooth devices Date: Wed, 3 Apr 2013 11:16:47 -0700 To: Adrian Chadd Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:16:55 -0000 Hi Adrian ! Thank you for your work. I briefly looked at it and it seems fine to me. I'= m not able to give it a proper review as I'm traveling internationally curre= ntly. Having said all that, I think it would be reasonable to commit it as i= s into head.=20 Thanks, Max On Apr 3, 2013, at 10:52 AM, Adrian Chadd wrote: > Hi, >=20 > Here you go: >=20 > http://people.freebsd.org/~adrian/ath/20130401-ath-bluetooth.diff >=20 > The ath3k driver in linux does a fair bit more than ath3kfw: >=20 > * if it's a subset of chips that needs firmware, it squirts ath3k-1.fw ont= o it > * there's a subset of chips that get ROM/RAM patches; so if it's one > of those, squeeze the patch on; > * it also will configure the AR3012 NIC between "config" and "normal" > mode when it's loading in those patches. >=20 > So it's likely that for full support, we're going to have to port over > this functionality and throw those firmware / patch / config files > somewhere to be uploaded when the relevant device is attached. >=20 > Thanks, >=20 >=20 >=20 > Adrian From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 20:46:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B833B91 for ; Wed, 3 Apr 2013 20:46:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 164AFE0D for ; Wed, 3 Apr 2013 20:46:13 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hj8so4056318wib.13 for ; Wed, 03 Apr 2013 13:46:12 -0700 (PDT) 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=g4rrn4nK72ZtDJyn7Xw3ofs+oOdxwPasMm3c5ak+tI4=; b=p00AVpRztM+hMilVyv0jGzwYXbTfS34xhdFM86y5cy4zv7/qf6OtSe3G0yZiCSE5sx iKPc2JILAqIUsM6e27QvR7aevbFtoRxFmoEBOZMuyXK+lfFFbqEnw1TXLiy96MWr4zvT mlzSKUTd+oQoOI0M22AyG7nRaoqmjIAJqmt5/+8tpt4DSPj1gTSOM4CHYyu+8LpdQz3d wbhkxldphD992fUQD6InHQT5EZRnYQLRgY7AqrYAnmKQYeLm5JloulqJnHDQN2+hmro0 +egZKAX89M8jQfQVcHKFedBwz3k5b4QIpqlGGRHlDUXwAkFw4GmN6Ha2rtzMMSNs+nNP iPWQ== MIME-Version: 1.0 X-Received: by 10.180.188.3 with SMTP id fw3mr4921923wic.33.1365021972895; Wed, 03 Apr 2013 13:46:12 -0700 (PDT) Received: by 10.216.243.7 with HTTP; Wed, 3 Apr 2013 13:46:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 13:46:12 -0700 Message-ID: Subject: Re: Patch ath3kfw to accept other device ids; blacklist ath bluetooth devices From: Adrian Chadd To: maksim yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 20:46:14 -0000 On 3 April 2013 11:16, maksim yevmenkin wrote: > Hi Adrian ! > > Thank you for your work. I briefly looked at it and it seems fine to me. I'm not able to give it a proper review as I'm traveling internationally currently. Having said all that, I think it would be reasonable to commit it as is into head. > > Thanks! Adrian From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 22:15:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 20858319; Wed, 3 Apr 2013 22:15:36 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 4448623CED6; Thu, 4 Apr 2013 00:15:35 +0200 (CEST) Message-ID: <515CAA04.1050108@FreeBSD.org> Date: Thu, 04 Apr 2013 00:15:32 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> In-Reply-To: <515BF5AE.4050804@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8376BEA5B9FB187BC8515317" Cc: Jeremy Chadwick , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 22:15:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8376BEA5B9FB187BC8515317 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have just sent more information to the PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=3D157397 The short summary (more info in the PR) is: - limiting tags to 31 does not help - disabling NCQ appears to help in initial testing, but warrants more testing - error happens during WRITE_FPDMA_QUEUED, - File system in question is SU+J UFS2 mounted on /usr, and I can for instance "rm -rf /usr/obj" or just log into GNOME and try to open a gnome-terminal to trigger stalls; - Linux uses 31 tags (for different reason) and has no drive quirks, but a controller quirk; for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag - it gets set by Linux on the SB700 that my computer is using, see ahci_error_intr() in libahci.h - I am not going to interpret that for lack of expertise, but it does affect error handling and appears to ignore a certain condition. Why only my Samsung HDD drive triggers this but not the WD drive, I do not know yet. Hope that helps a bit. --------------enig8376BEA5B9FB187BC8515317 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFcqgcACgkQvmGDOQUufZWWaQCeMAxtWxO2tGDhIYihltp7k5vt tG4AoOJs+E3ZKj5bYzdPuOJZASipS4CZ =7HNI -----END PGP SIGNATURE----- --------------enig8376BEA5B9FB187BC8515317-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 00:19:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 33536C16; Thu, 4 Apr 2013 00:19:20 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 5791423CED6; Thu, 4 Apr 2013 02:19:19 +0200 (CEST) Message-ID: <515CC704.90302@FreeBSD.org> Date: Thu, 04 Apr 2013 02:19:16 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> In-Reply-To: <20130403233815.GA65719@icarus.home.lan> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7D83C6BF10896513FA0E81E0" Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 00:19:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7D83C6BF10896513FA0E81E0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04.04.2013 01:38, schrieb Jeremy Chadwick: =2E.. > While skimming Linux libata code and commits in the past, the only > glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the > hardware revision apparently matters) and port multiplier (PMP) support= > and soft resets. >=20 > Are you using a port multiplier? I doubt it, but I have to ask. I am not using a PMP as far as I know (unless one is buried on my Asus M4A78T-E main board). It would seem the drives are directly attached to the south bridge's SATA ports. >> Why only my Samsung HDD drive triggers this but not the WD drive, I do= >> not know yet. >=20 > Please provide "gpart show -p ada1" output, both here and in the PR, > if you could. =3D> 63 1953525105 ada1 MBR (931G) 63 209714337 ada1s1 freebsd [active] (100G) 209714400 800 - free - (400k) 209715200 71680000 ada1s2 ntfs (34G) 281395200 15405 - free - (7.5M) 281410605 488263545 ada1s3 linux-data (232G) 769674150 1183851018 - free - (564G) HTH Best regards Matthias --------------enig7D83C6BF10896513FA0E81E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFcxwcACgkQvmGDOQUufZVwqgCg4D2AxN7XOv4agaXe1bDiIT9G aXoAoLj3C/ZWIYRT2SzZCd6PEv5bm/U0 =6bx7 -----END PGP SIGNATURE----- --------------enig7D83C6BF10896513FA0E81E0-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 3 23:38:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 56B2A28D for ; Wed, 3 Apr 2013 23:38:17 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by mx1.freebsd.org (Postfix) with ESMTP id 3873684F for ; Wed, 3 Apr 2013 23:38:17 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta06.emeryville.ca.mail.comcast.net with comcast id Kasz1l0061zF43QA6beGX6; Wed, 03 Apr 2013 23:38:16 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta24.emeryville.ca.mail.comcast.net with comcast id KbeF1l00S1t3BNj8kbeGyr; Wed, 03 Apr 2013 23:38:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BBB4A73A1C; Wed, 3 Apr 2013 16:38:15 -0700 (PDT) Date: Wed, 3 Apr 2013 16:38:15 -0700 From: Jeremy Chadwick To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130403233815.GA65719@icarus.home.lan> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515CAA04.1050108@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365032296; bh=0vyC6baetUvnRbBry/tm2+XU83XvplLjZi9RWo9evOU=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=ltpehHQqxJkXB72KbWqSxa8JcUFm02iVaNVCkDKvxcCIMX6jlTGkTKolprPp6pK9x i+jl8aXt/I9Zgkv1J1XnmPEPfdlKnPwaGmsf6X2eLN/KTlRQwpmq796KuwoDpmIiKE GPX2ktXb37hHQLdx9GOKhCrLEhHvFiocbNAtJJWgkelEnd6UzOS/uTy4E3D0dZV7tQ r87gPFky5ZuOKpFdxYnjdDC6QyGZPYo2RRwu9UZHczF0AjgzbD6g5IRFid2LlOgDtR rCd5vfwfMewF07apl448aIXa8rpB+J5Nq98xO3TYISnjncR9i3GCjCL2jKMJXqKU2Z ZWkHxBZhDHGFw== X-Mailman-Approved-At: Thu, 04 Apr 2013 04:42:10 +0000 Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 23:38:17 -0000 On Thu, Apr 04, 2013 at 12:15:32AM +0200, Matthias Andree wrote: > I have just sent more information to the PR at > http://www.freebsd.org/cgi/query-pr.cgi?pr=157397 > > The short summary (more info in the PR) is: > > - limiting tags to 31 does not help > > - disabling NCQ appears to help in initial testing, but warrants more > testing > > - error happens during WRITE_FPDMA_QUEUED, This is an NCQ-based write LBA request. There are many non-NCQ equivalents of this, ATA-protocol-wise (too many to list here), but the most likely non-NCQ ATA command you'd see is WRITE_DMA48. > - File system in question is SU+J UFS2 mounted on /usr, and I can for > instance "rm -rf /usr/obj" or just log into GNOME and try to open a > gnome-terminal to trigger stalls; > > - Linux uses 31 tags (for different reason) and has no drive quirks, but > a controller quirk; > > for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it > might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag > - it gets set by Linux on the SB700 that my computer is using, see > ahci_error_intr() in libahci.h - I am not going to interpret that for > lack of expertise, but it does affect error handling and appears to > ignore a certain condition. Alexander could expand on this, but the name of the flag implies that there are certain conditions where the SATA-level SERR condition gets ignored ("IGN"). While skimming Linux libata code and commits in the past, the only glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the hardware revision apparently matters) and port multiplier (PMP) support and soft resets. Are you using a port multiplier? I doubt it, but I have to ask. > Why only my Samsung HDD drive triggers this but not the WD drive, I do > not know yet. Please provide "gpart show -p ada1" output, both here and in the PR, if you could. I have a gut feeling I know what the issue is (and if it is what I think it is, it's actually happening all the time, just that NCQ exacerbates it given how command queueing works), but I won't know for sure until I see the output. Thanks. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 01:05:27 2013 Return-Path: Delivered-To: freebsd-current@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 C54BF4AD for ; Thu, 4 Apr 2013 01:05:27 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id A63A6D75 for ; Thu, 4 Apr 2013 01:05:27 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta12.emeryville.ca.mail.comcast.net with comcast id KRlE1l00H1u4NiLACd5TsC; Thu, 04 Apr 2013 01:05:27 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta21.emeryville.ca.mail.comcast.net with comcast id Kd5S1l00T1t3BNj8hd5SEK; Thu, 04 Apr 2013 01:05:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 832C173A1C; Wed, 3 Apr 2013 18:05:26 -0700 (PDT) Date: Wed, 3 Apr 2013 18:05:26 -0700 From: Jeremy Chadwick To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130404010526.GA66858@icarus.home.lan> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515CC704.90302@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365037527; bh=6KMV9MX9XtyQcKBuLMhAYtElbw73yRPlpG0rTWp8tOo=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=cAv9ar7PtM6+wyVEv69g2a5uRcu7zd1rRpOch8tYlk5p2+TQT1vKPLEm8YyLcZASI N+wf2fw0mrXMmVYD1ggLzgOH6EjZ2EewDPe7YSfLex2FHfLpaq8/lOn4dUtCCzIXZO 1rcPJ73TmJuYfuaal7oCpEqWF0QQzjZfSDgUu5YAsi734Qifcv0P9zO8eVFbiqHIOV pPSdBu0eZ9TQqtwqR0H657ZHlsE1uNPFU9JvxTF+WjaAKcQyT4Bm/A757heM9wx8Fe jmLLI2wikUj5zg71yz54M5BeVJLMWFyiEpO0WMYlz2s9l82MsKC68NPnZBUZcvzcWQ 4MQAsxkAw7Org== X-Mailman-Approved-At: Thu, 04 Apr 2013 04:42:28 +0000 Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 01:05:27 -0000 On Thu, Apr 04, 2013 at 02:19:16AM +0200, Matthias Andree wrote: > Am 04.04.2013 01:38, schrieb Jeremy Chadwick: > > ... > > > While skimming Linux libata code and commits in the past, the only > > glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the > > hardware revision apparently matters) and port multiplier (PMP) support > > and soft resets. > > > > Are you using a port multiplier? I doubt it, but I have to ask. > > I am not using a PMP as far as I know (unless one is buried on my Asus > M4A78T-E main board). It would seem the drives are directly attached to > the south bridge's SATA ports. Then the answer is nope, you're not using a PM. Details: http://www.serialata.org/technology/port_multipliers.asp http://en.wikipedia.org/wiki/Port_multiplier > >> Why only my Samsung HDD drive triggers this but not the WD drive, I do > >> not know yet. > > > > Please provide "gpart show -p ada1" output, both here and in the PR, > > if you could. > > => 63 1953525105 ada1 MBR (931G) > 63 209714337 ada1s1 freebsd [active] (100G) > 209714400 800 - free - (400k) > 209715200 71680000 ada1s2 ntfs (34G) > 281395200 15405 - free - (7.5M) > 281410605 488263545 ada1s3 linux-data (232G) > 769674150 1183851018 - free - (564G) This is what I was worried about. Referring to your "camcontrol identify" output: > device model SAMSUNG HD103SI > sector size logical 512, physical 512, offset 0 Hear me out entirely on this one. My theory is that your hard disk actually uses 4096-byte sectors but is too old to provide ATA IDENTIFY semantics to delineate between logical vs. physical sector size. In other words, only logical is provided, thus logical=physical in the eyes of all software; smartctl will show you the exact same thing too. There are drives like this in the wild, both SSDs as well as MHDDs. For example, the Intel 320-series SSD behaves this way too (providing only logical size). Do not let the capacity/size of the drive be the deciding factor; your drive is 1TB, but I also have many 1TB MHDDs that use 4096-byte sectors. Seagate/Samsung's specification** for the HD103SI states, and I quote: "Byte per Sensor: 512 bytes". Yes, it says "Sensor". Whether or not this documentation is correct/accurate is unknown, and when vendors have typos in their own specification docs, I cannot help but to honour the possibility of the information being wrong. So I'm unsure if this drive uses 512-byte sectors or 4096-byte sectors. That said: in your "gpart show ada1" output, none of your partitions (FreeBSD, NTFS, nor Linux) appear to be aligned to 4096-byte boundaries. Ideally you'd want to have these aligned to 1MB or 2MByte boundaries in the case you ever move to an SSD. You're also using the MBR scheme, which does not tend to play well with alignment. Comparatively, your WD5002ABYS drive **does** use 512-byte sectors (I know this for a fact). The problem here is that I cannot guarantee you that alignment is the problem. The performance impact of writes to partitions which are non-aligned is quite high, and NCQ just exacerbates this problem. I would love to tell you "switch to GPT and follow Warren Block's document***" but if your NTFS partition is Windows and is a Windows version older than Windows 7 GPT is not supported. One piece of evidence that refutes my theory is that if Windows and/or Linux partition are something you boot into and use often, I would imagine NCQ would be used in both of those environments and would suffer from the same issue. Although Windows tends to hide all sorts of transient errors from the user (sigh), Linux tends to be like FreeBSD with regards to such issues (on the console anyway; you wouldn't see such messages normally inside of X). If you have the time and want to put forth the effort, I would recommend backing up all your data on ada1, zero the first and last 1MByte of the drive, and then try following Warren Block's guide. I'd just recommend doing this: gpart create -s gpt ada1 gpart add -t freebsd-ufs -b 2m ada1 newfs -U -j /dev/ada1p1 (or remove -j if you don't want to use SUJ) I picked an alignment value of 2MBytes since it's both 4K-aligned and is generally safe for things like newer SSDs that have larger NAND erase block size (I am not going to get into a discussion about that here, so please stay focused. :-) ) If the problem is gone after that (it should be easy to induce by writing tons and tons of data to the drive), then we can safely say that the drive uses 4096-byte sectors and need to add it to the quirks list in ata_da.c. If the problem remains after that, then further investigation is needed, and we can safely rule out alignment. Welcome to all the pain/effort one has to go through when troubleshooting things like this. :-) Another thing: in your PR you state: > - I am running with kern.cam.ada.default_timeout=5 which makes the > computer recover faster I can definitely imagine cases where a drive using NCQ but doing writes to a non-aligned partition could take longer than 5 seconds to respond to an ATA CDB (this is different than a SATA or AHCI layer timeout). I am not telling you "change this back to 30", but it might not be helping your situation at all given my above theory. Finally: could you please provide output from "smartctl -x /dev/ada1"? I would like to rule out any possibility of your drive having some other kind of issue that might cause it to go catatonic. Thanks. ** -- http://www.seagate.com/files/www-content/support-content/documentation/samsung/tech-specs/eco_greenf2.pdf *** -- http://www.wonkity.com/~wblock/docs/html/ssd.html -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 07:07:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 26635F0B; Thu, 4 Apr 2013 07:07:48 +0000 (UTC) (envelope-from daemon@dx.burplex.com) Received: from dx.burplex.com (dx.burplex.com [50.197.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 13F4F9B6; Thu, 4 Apr 2013 07:07:47 +0000 (UTC) Received: by dx.burplex.com (Postfix, from userid 1) id 2964036F49CB; Thu, 4 Apr 2013 00:07:47 -0700 (PDT) To: Adrian Chadd Subject: Re: RE: rebooting nvidia + keyboard issues From: Waitman Gobble X-UUID-HOR: 6bc86ed6-9c89-11e2-a35d-902b34a86bc3 Message-Id: <20130404070747.2964036F49CB@dx.burplex.com> Date: Thu, 4 Apr 2013 00:07:47 -0700 (PDT) Cc: Thomas Sparrevohn , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 07:07:48 -0000 On Wed, 3 Apr 2013 11:07:55 -0700, Adrian Chadd wrote: > >Hi, > >can you guys please ensure a PR is filed with all the information >you've just included? > >the clang team would likely love to have this much information in a bug report. > >Thanks! > > > >adrian > OK is it good to know the two ports that i noticed didn't build with clang? Unfortunately I did not keep track of the ports, however I can make a script to iterate through all installed ports and do 'make' and see where it stops. OR Maybe there's an easier way. I'll try the nvidia port in a bit, but I think Thomas already has a good idea of what's going on. -- Waitman Gobble San Jose California USA +1.5108307875 From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 08:00:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id B6C97CAE; Thu, 4 Apr 2013 08:00:23 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id E64AA23CED6; Thu, 4 Apr 2013 10:00:22 +0200 (CEST) Message-ID: <515D3312.3010109@FreeBSD.org> Date: Thu, 04 Apr 2013 10:00:18 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> <20130404010526.GA66858@icarus.home.lan> In-Reply-To: <20130404010526.GA66858@icarus.home.lan> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig05900F9F959D20FB9CBDA030" Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 08:00:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05900F9F959D20FB9CBDA030 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04.04.2013 03:05, schrieb Jeremy Chadwick: >>> Please provide "gpart show -p ada1" output, both here and in the PR, >>> if you could. >> >> =3D> 63 1953525105 ada1 MBR (931G) >> 63 209714337 ada1s1 freebsd [active] (100G) >> 209714400 800 - free - (400k) >> 209715200 71680000 ada1s2 ntfs (34G) >> 281395200 15405 - free - (7.5M) >> 281410605 488263545 ada1s3 linux-data (232G) >> 769674150 1183851018 - free - (564G) Thanks for all the useful information provided so far (including further down). I know some of that already, but am not going to complain because it is very useful in the logs. > The problem here is that I cannot guarantee you that alignment is > the problem. The performance impact of writes to partitions which are > non-aligned is quite high, and NCQ just exacerbates this problem. I > would love to tell you "switch to GPT and follow Warren Block's > document***" but if your NTFS partition is Windows and is a Windows ver= sion > older than Windows 7 GPT is not supported. I am happy to make that realign-and-use-GPT experiment. My Windows is "7 Professional 64-bit". It will take me a few days because this is spare-time stuff. > One piece of evidence that refutes my theory is that if Windows and/or > Linux partition are something you boot into and use often, I would > imagine NCQ would be used in both of those environments and would suffe= r > from the same issue. Although Windows tends to hide all sorts of > transient errors from the user (sigh), Linux tends to be like FreeBSD > with regards to such issues (on the console anyway; you wouldn't see > such messages normally inside of X). Now, the FreeBSD slice is the only partition on that disk that would likely see concurrent write accesses (think "make -j8" on a quadcore computer) which is more prone to ferret out such alignment contention. The NTFS partition is aligned on a multi-MB boundary, so wouldn't hit the problem anyways. The Linux partition is in ext4 format for mostly sequential access to files usually in excess of 10 MB each. Linux's ext4 jumps through several hoops to end up with bulk writes, like extents, delayed allocations (to avoid fragmentation), reordering of data and metadata writes, serialized log writes and all that stuff, and it would appear I am permitting it to cache writes -- Linux uses write barriers to enforce proper ordering of journal/meta-data writes. It would be rather hard to hit ATA taskfile timeouts, the expected rate with which the drive needs to do a partial write is orders of magnitude lower. Any good "concurrent write" exercise tools for Unix that I could run on the Linux ext4 partition that you would propose? > If you have the time and want to put forth the effort, I would recommen= d > backing up all your data on ada1, zero the first and last 1MByte of the= > drive, and then try following Warren Block's guide. I'd just recommend= > doing this: >=20 > gpart create -s gpt ada1 > gpart add -t freebsd-ufs -b 2m ada1 > newfs -U -j /dev/ada1p1 (or remove -j if you don't want to use SUJ) Will do. >> - I am running with kern.cam.ada.default_timeout=3D5 which makes the >> computer recover faster >=20 > I can definitely imagine cases where a drive using NCQ but doing writes= > to a non-aligned partition could take longer than 5 seconds to respond > to an ATA CDB (this is different than a SATA or AHCI layer timeout). I= am > not telling you "change this back to 30", but it might not be helping > your situation at all given my above theory. My feeling is that the stalls are mostly from the error handler and the overall time the drive is "frozen" gets shorter. If it had not _felt_ faster, I'd not have left that in sysctl.conf in the first place. > Finally: could you please provide output from "smartctl -x /dev/ada1"? > I would like to rule out any possibility of your drive having some othe= r > kind of issue that might cause it to go catatonic. Thanks. I have fetched the data with Linux this time (should not make a difference as it's all drive internal data, not host OS stuff). Looks sane to me, . I'll be happy to refetch this data with a more current smartctl version under FreeBSD if required. >=20 >=20 > ** -- http://www.seagate.com/files/www-content/support-content/document= ation/samsung/tech-specs/eco_greenf2.pdf >=20 > *** -- http://www.wonkity.com/~wblock/docs/html/ssd.html >=20 --------------enig05900F9F959D20FB9CBDA030 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFdMxIACgkQvmGDOQUufZXemgCgk4AJnaRlr17BDpOzvCS7sHej QNIAoMLTA4PsdYY6fCxJ5w8KxwIJQTUX =/vE0 -----END PGP SIGNATURE----- --------------enig05900F9F959D20FB9CBDA030-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 15:23:49 2013 Return-Path: Delivered-To: freebsd-current@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 0569DF55 for ; Thu, 4 Apr 2013 15:23:49 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from relay.andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with ESMTP id 429059F6 for ; Thu, 4 Apr 2013 15:23:48 +0000 (UTC) Received: (qmail 964 invoked from network); 4 Apr 2013 15:17:05 -0000 Received: from alex.andxor.it (a.premoli@andxor.it@192.168.2.30) by relay.andxor.it with ESMTPSA; 4 Apr 2013 15:17:05 -0000 Message-ID: <515D9971.40203@FreeBSD.org> Date: Thu, 04 Apr 2013 17:17:05 +0200 From: Alex Dupre User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Olli Hauer , "O. Hartmann" Subject: Re: www/apache24: ports like lang/php5 or devel/subversion are disturbed by the apache24 port! References: <1364750502.1715.34.camel@thor.walstatt.dyndns.org> <515875C8.1080201@FreeBSD.org> In-Reply-To: <515875C8.1080201@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , FreeBSD ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 15:23:49 -0000 Olli Hauer ha scritto: > It will take a while until php is really apache24 ready. > > Work is in progress on php upstream. > > One of the issues is that APXS does not provide the > MPM model which is needed for php and others to build. Can you try the following patch, please? Index: bsd.php.mk =================================================================== --- bsd.php.mk (revision 315696) +++ bsd.php.mk (working copy) @@ -60,9 +60,8 @@ HTTPD?= ${LOCALBASE}/sbin/httpd .if exists(${HTTPD}) -APXS?= ${LOCALBASE}/sbin/apxs -APACHE_MPM!= ${APXS} -q MPM_NAME -. if ${APACHE_MPM} == "worker" || ${APACHE_MPM} == "event" +APACHE_THR!= ${HTTPD} -V | ${GREP} threaded +. if ${APACHE_THR:Myes} PHP_EXT_DIR:= ${PHP_EXT_DIR}-zts . endif .elif defined(APACHE_PORT) && (${APACHE_PORT:M*worker*} != "" || ${APACHE_PORT:M*event*} != "") -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 16:16:42 2013 Return-Path: Delivered-To: freebsd-current@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 2A80A5D0; Thu, 4 Apr 2013 16:16:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 403D9E24; Thu, 4 Apr 2013 16:16:40 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA10827; Thu, 04 Apr 2013 19:16:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515DA760.8000101@FreeBSD.org> Date: Thu, 04 Apr 2013 19:16:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Baldwin Subject: Re: gptzfsboot problem on HP P410i Smart Array References: <51483621.2060503@FreeBSD.org> <201303191220.34088.jhb@freebsd.org> In-Reply-To: <201303191220.34088.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bjorn Larsson , freebsd-current@FreeBSD.org, Sergey Dyatko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:16:42 -0000 on 19/03/2013 18:20 John Baldwin said the following: > Yes, we likely could start using that, we would just need to ensure it has some > sort of minimum size. However, maybe it would always have that minimum size as you > are only going to have additional ranges if you have more than 4GB of RAM anyway. > I think though that there were some odd BIOSes that would place a hole at 15-16MB, > and for those the memory region at 1MB is too small. A minimum size of 16MB might > handle that case correctly while using the first extended region in the common > case. How about something like this? Author: Andriy Gapon Date: Wed Apr 3 11:48:34 2013 +0300 [test] zfsboot: bios_getmem prefer extmem over another random chunk of high memory If the extended memory region is sufficiently large. diff --git a/sys/boot/i386/zfsboot/zfsboot.c b/sys/boot/i386/zfsboot/zfsboot.c index 82402b6..12ceeb0 100644 --- a/sys/boot/i386/zfsboot/zfsboot.c +++ b/sys/boot/i386/zfsboot/zfsboot.c @@ -374,6 +374,16 @@ bios_getmem(void) } /* + * If extended memory is at least twice as large as the largest + * region of higher memory, then carve the high heap out of + * extended memory. + */ + if (bios_extmem > 2 * high_heap_size) { + high_heap_base = 0x100000 + bios_extmem / 2; + high_heap_size = bios_extmem / 2; + } + + /* * If we have extended memory and did not find a suitable heap * region in the SMAP, use the last 3MB of 'extended' memory as a * high heap candidate. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 17:22:18 2013 Return-Path: Delivered-To: freebsd-current@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 A3EFF882; Thu, 4 Apr 2013 17:22:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 80660235; Thu, 4 Apr 2013 17:22:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CC07CB980; Thu, 4 Apr 2013 13:22:16 -0400 (EDT) From: John Baldwin To: Andriy Gapon Subject: Re: gptzfsboot problem on HP P410i Smart Array Date: Thu, 4 Apr 2013 13:16:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201303191220.34088.jhb@freebsd.org> <515DA760.8000101@FreeBSD.org> In-Reply-To: <515DA760.8000101@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304041316.12617.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Apr 2013 13:22:16 -0400 (EDT) Cc: Bjorn Larsson , freebsd-current@freebsd.org, Sergey Dyatko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:22:18 -0000 On Thursday, April 04, 2013 12:16:32 pm Andriy Gapon wrote: > on 19/03/2013 18:20 John Baldwin said the following: > > Yes, we likely could start using that, we would just need to ensure it has some > > sort of minimum size. However, maybe it would always have that minimum size as you > > are only going to have additional ranges if you have more than 4GB of RAM anyway. > > I think though that there were some odd BIOSes that would place a hole at 15-16MB, > > and for those the memory region at 1MB is too small. A minimum size of 16MB might > > handle that case correctly while using the first extended region in the common > > case. > > How about something like this? > > Author: Andriy Gapon > Date: Wed Apr 3 11:48:34 2013 +0300 > > [test] zfsboot: bios_getmem prefer extmem over another random chunk of high memory > > If the extended memory region is sufficiently large. > > diff --git a/sys/boot/i386/zfsboot/zfsboot.c b/sys/boot/i386/zfsboot/zfsboot.c > index 82402b6..12ceeb0 100644 > --- a/sys/boot/i386/zfsboot/zfsboot.c > +++ b/sys/boot/i386/zfsboot/zfsboot.c > @@ -374,6 +374,16 @@ bios_getmem(void) > } > > /* > + * If extended memory is at least twice as large as the largest > + * region of higher memory, then carve the high heap out of > + * extended memory. > + */ > + if (bios_extmem > 2 * high_heap_size) { > + high_heap_base = 0x100000 + bios_extmem / 2; > + high_heap_size = bios_extmem / 2; > + } > + > + /* > * If we have extended memory and did not find a suitable heap > * region in the SMAP, use the last 3MB of 'extended' memory as a > * high heap candidate. > We should really use the same algorithm in boot2 and gptboot as well. I think though that in this case you can just use the last 3MB of heap rather than half of the extended memory as heap. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 17:34:03 2013 Return-Path: Delivered-To: freebsd-current@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 3B8E0A63; Thu, 4 Apr 2013 17:34:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C70332B8; Thu, 4 Apr 2013 17:34:01 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA11680; Thu, 04 Apr 2013 20:34:00 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515DB988.1080100@FreeBSD.org> Date: Thu, 04 Apr 2013 20:34:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Baldwin Subject: Re: call suspend_cpus() under smp_ipi_mtx References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org> <201304011052.18370.jhb@freebsd.org> In-Reply-To: <201304011052.18370.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 17:34:03 -0000 on 01/04/2013 17:52 John Baldwin said the following: > Hmm, I think intr_table_lock used to be a spin lock at some point. I don't remember > why we changed it to a regular mutex. It may be that there was a lock order reason > for that. :( I came up with the following patch: http://people.freebsd.org/~avg/intr_table_lock.diff Please note the witness change. Part of it is to prepare for smp_ipi_mtx -> intr_table_lock order, but I also had to move "entropy harvest mutex" because it is used with msleep_spin. Also intr_table_lock interacts with "sched lock". This seems to work without problems or any warnings with WITNESS && !WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the relevant code paths. P.S. Looking through history it seems that in r169391 intr_table_lock was changed from a spinlock to a sx lock (later it was changed to the current mutex). The commit message explains why spinlock was not needed, but it doesn't seem to say why it was unacceptable: > Minor fixes and tweaks to the x86 interrupt code: - Split the intr_table_lock into an sx lock used for most things, and a spin lock to protect intrcnt_index. Originally I had this as a spin lock so interrupt code could use it to lookup sources. However, we don't actually do that because it would add a lot of overhead to interrupts, and if we ever do support removing interrupt sources, we can use other means to safely do so w/o locking in the interrupt handling code. - Replace is_enabled (boolean) with is_handlers (a count of handlers) to determine if a source is enabled or not. This allows us to notice when a source is no longer in use. When that happens, we now invoke a new PIC method (pic_disable_intr()) to inform the PIC driver that the source is no longer in use. The I/O APIC driver frees the APIC IDT vector when this happens. The MSI driver no longer needs to have a hack to clear is_enabled during msi_alloc() and msix_alloc() as a result of this change as well. - Add an apic_disable_vector() to reset an IDT vector back to Xrsvd to complement apic_enable_vector() and use it in the I/O APIC and MSI code when freeing an IDT vector. - Add a new nexus hook: nexus_add_irq() to ask the nexus driver to add an IRQ to its irq_rman. The MSI code uses this when it creates new interrupt sources to let the nexus know about newly valid IRQs. Previously the msi_alloc() and msix_alloc() passed some extra stuff back to the nexus methods which then added the IRQs. This approach is a bit cleaner. - Change the MSI sx lock to a mutex. If we need to create new sources, drop the lock, create the required number of sources, then get the lock and try the allocation again. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Apr 4 18:01:47 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 86E59243; Thu, 4 Apr 2013 18:01:47 +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 9E9205F7; Thu, 4 Apr 2013 18:01:46 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA12167; Thu, 04 Apr 2013 21:01:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515DC008.9060108@FreeBSD.org> Date: Thu, 04 Apr 2013 21:01:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Baldwin Subject: Re: gptzfsboot problem on HP P410i Smart Array References: <201303191220.34088.jhb@freebsd.org> <515DA760.8000101@FreeBSD.org> <201304041316.12617.jhb@freebsd.org> In-Reply-To: <201304041316.12617.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:01:47 -0000 on 04/04/2013 20:16 John Baldwin said the following: > On Thursday, April 04, 2013 12:16:32 pm Andriy Gapon wrote: >> diff --git a/sys/boot/i386/zfsboot/zfsboot.c > b/sys/boot/i386/zfsboot/zfsboot.c >> index 82402b6..12ceeb0 100644 >> --- a/sys/boot/i386/zfsboot/zfsboot.c >> +++ b/sys/boot/i386/zfsboot/zfsboot.c >> @@ -374,6 +374,16 @@ bios_getmem(void) >> } >> >> /* >> + * If extended memory is at least twice as large as the largest >> + * region of higher memory, then carve the high heap out of >> + * extended memory. >> + */ >> + if (bios_extmem > 2 * high_heap_size) { >> + high_heap_base = 0x100000 + bios_extmem / 2; >> + high_heap_size = bios_extmem / 2; >> + } >> + >> + /* >> * If we have extended memory and did not find a suitable heap >> * region in the SMAP, use the last 3MB of 'extended' memory as a >> * high heap candidate. >> > > We should really use the same algorithm in boot2 and gptboot as well. Yes, this is just something to start with. BTW, all other components use bios_getmem from sys/boot/i386/libi386/biosmem.c ? > I think though that in this case you can just use the last 3MB of heap > rather than half of the extended memory as heap. I thought the more the better? :-) I've kept the block of code that tries to make high_heap_size at least 3MB. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 5 14:49:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73E2FAC9; Fri, 5 Apr 2013 14:49:18 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 473A3AD7; Fri, 5 Apr 2013 14:49:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=iiKsWe6Jzdq0S/1BI7w/ICasfJkuVF8QqyD+Y8DPfKA=; b=io3Tm6ROfPdAPJpWdonH6NjyObnaL0jlzXxyrdsocoxWMzRqBgutjCn1rFLjrYUPflwti38cwFFLNvXC7C7RSkPrn9xPnMgdOdXPoCLAhbkfg8C8ZSkWQ8pip1D2PXcfKSgLlwW9vlrCP4m7DKrtce6DyhbiN8oIpdKXrCH+VcA=; Received: from localhost.lerctr.org ([127.0.0.1]:55262 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UO7x7-0001NS-8k; Fri, 05 Apr 2013 09:49:17 -0500 Received: from [32.97.110.60] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 05 Apr 2013 09:49:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Apr 2013 09:49:17 -0500 From: Larry Rosenman To: Martin Matuska Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT In-Reply-To: <515B4CFA.9080706@FreeBSD.org> References: <5159EF29.6000503@FreeBSD.org> <515B4CFA.9080706@FreeBSD.org> Message-ID: <9bc083a21a73839a0932514ea4f48d0d@webmail.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.5 X-Spam-Score: -5.3 (-----) X-LERCTR-Spam-Score: -5.3 (-----) X-Spam-Report: SpamScore (-5.3/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.373 X-LERCTR-Spam-Report: SpamScore (-5.3/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.373 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 14:49:18 -0000 On 2013-04-02 16:26, Martin Matuska wrote: > On 1. 4. 2013 22:33, Martin Matuska wrote: >> This error seems to be limited to sending deduplicated streams. Does >> sending without "-D" work ok? This might be a vendor error as well. >> >> On 1.4.2013 20:05, Larry Rosenman wrote: >>> Re-Sending. Any ideas, guys/gals? >>> >>> This really gets in my way. >>> > This may be also related to: > http://www.freebsd.org/cgi/query-pr.cgi?pr=176978 Taking off -D does get around the panic. What information can I provide to help fix it? I *CAN* provide access to both sides via SSH. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Apr 5 16:29:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E76F937D; Fri, 5 Apr 2013 16:29:18 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id A991E197; Fri, 5 Apr 2013 16:29:18 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 37F3D36296; Fri, 5 Apr 2013 18:29:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id R7eDwxJXQqov; Fri, 5 Apr 2013 18:29:13 +0200 (CEST) Received: from [10.9.8.1] (chello085216226145.chello.sk [85.216.226.145]) by mail.vx.sk (Postfix) with ESMTPSA id 3FA9B36284; Fri, 5 Apr 2013 18:29:11 +0200 (CEST) Message-ID: <515EFBD8.50900@FreeBSD.org> Date: Fri, 05 Apr 2013 18:29:12 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Larry Rosenman Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT References: <5159EF29.6000503@FreeBSD.org> <515B4CFA.9080706@FreeBSD.org> <9bc083a21a73839a0932514ea4f48d0d@webmail.lerctr.org> In-Reply-To: <9bc083a21a73839a0932514ea4f48d0d@webmail.lerctr.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/mixed; boundary="------------030409060808020909030202" Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:29:19 -0000 This is a multi-part message in MIME format. --------------030409060808020909030202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You can use the attached patch, it should fix the problem. We are still waiting for code review and a final solution by illumos, maybe I will commit this preliminary (or final) fix to head. mm On 5.4.2013 16:49, Larry Rosenman wrote: > On 2013-04-02 16:26, Martin Matuska wrote: >> On 1. 4. 2013 22:33, Martin Matuska wrote: >>> This error seems to be limited to sending deduplicated streams. Does >>> sending without "-D" work ok? This might be a vendor error as well. >>> >>> On 1.4.2013 20:05, Larry Rosenman wrote: >>>> Re-Sending. Any ideas, guys/gals? >>>> >>>> This really gets in my way. >>>> >> This may be also related to: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=176978 > Taking off -D does get around the panic. > > What information can I provide to help fix it? > > I *CAN* provide access to both sides via SSH. > > -- Martin Matuska FreeBSD committer http://blog.vx.sk --------------030409060808020909030202 Content-Type: text/plain; charset=windows-1250; name="dmu_send.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmu_send.c.patch" Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c (revision 249165) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c (working copy) @@ -990,6 +990,7 @@ free_guid_map_onexit(void *arg) while ((gmep = avl_destroy_nodes(ca, &cookie)) != NULL) { dsl_dataset_long_rele(gmep->gme_ds, gmep); + dsl_dataset_rele(gmep->gme_ds, FTAG); kmem_free(gmep, sizeof (guid_map_entry_t)); } avl_destroy(ca); @@ -1698,7 +1699,6 @@ add_ds_to_guidmap(const char *name, avl_tree_t *gu gmep->gme_ds = snapds; avl_add(guid_map, gmep); dsl_dataset_long_hold(snapds, gmep); - dsl_dataset_rele(snapds, FTAG); } dsl_pool_rele(dp, FTAG); --------------030409060808020909030202-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 5 16:31:20 2013 Return-Path: Delivered-To: freebsd-current@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 62955595; Fri, 5 Apr 2013 16:31:20 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3539D1CD; Fri, 5 Apr 2013 16:31:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=fh96BkWZySJA6s26iCZjXoEy0Ket6ofqyiY8OA+SNGo=; b=uye712TN/sJXaDPk5t/hxuLx/lX00hrhZeazk92AVeqwxPQ+S1UitfgKL8FBYsgWwss2FV8V0k7uxTnwXu+72zRxa4mUexDWTTjr36rIgpP8urEa0kwB+OFE/rw7tVg6YGoAU885na+ZsiYfKG4lyV/OTADzSjZpca09Wi3Dey8=; Received: from localhost.lerctr.org ([127.0.0.1]:56915 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UO9Xq-0002S2-Il; Fri, 05 Apr 2013 11:31:19 -0500 Received: from [32.97.110.60] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 05 Apr 2013 11:31:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Apr 2013 11:31:18 -0500 From: Larry Rosenman To: Martin Matuska Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT In-Reply-To: <515EFBD8.50900@FreeBSD.org> References: <5159EF29.6000503@FreeBSD.org> <515B4CFA.9080706@FreeBSD.org> <9bc083a21a73839a0932514ea4f48d0d@webmail.lerctr.org> <515EFBD8.50900@FreeBSD.org> Message-ID: <62827019d058b2a905a0d476565b56c0@webmail.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.5 X-Spam-Score: -5.3 (-----) X-LERCTR-Spam-Score: -5.3 (-----) X-Spam-Report: SpamScore (-5.3/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.373 X-LERCTR-Spam-Report: SpamScore (-5.3/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.373 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:31:20 -0000 On 2013-04-05 11:29, Martin Matuska wrote: > You can use the attached patch, it should fix the problem. > We are still waiting for code review and a final solution by illumos, > maybe I will commit this preliminary (or final) fix to head. Which side does this need to be on? (sending? (since it's dmu_send)? (which in my case is 8-STABLE) > > mm > > On 5.4.2013 16:49, Larry Rosenman wrote: >> On 2013-04-02 16:26, Martin Matuska wrote: >>> On 1. 4. 2013 22:33, Martin Matuska wrote: >>>> This error seems to be limited to sending deduplicated streams. >>>> Does >>>> sending without "-D" work ok? This might be a vendor error as well. >>>> >>>> On 1.4.2013 20:05, Larry Rosenman wrote: >>>>> Re-Sending. Any ideas, guys/gals? >>>>> >>>>> This really gets in my way. >>>>> >>> This may be also related to: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=176978 >> Taking off -D does get around the panic. >> >> What information can I provide to help fix it? >> >> I *CAN* provide access to both sides via SSH. >> >> -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Apr 5 16:33:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 70E2872E; Fri, 5 Apr 2013 16:33:01 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id 339341FB; Fri, 5 Apr 2013 16:33:01 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 32C9D3643A; Fri, 5 Apr 2013 18:32:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id 7EzwkIVhWlDX; Fri, 5 Apr 2013 18:32:52 +0200 (CEST) Received: from [10.9.8.1] (chello085216226145.chello.sk [85.216.226.145]) by mail.vx.sk (Postfix) with ESMTPSA id 026ED36431; Fri, 5 Apr 2013 18:32:51 +0200 (CEST) Message-ID: <515EFCB5.1060703@FreeBSD.org> Date: Fri, 05 Apr 2013 18:32:53 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Larry Rosenman Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT References: <5159EF29.6000503@FreeBSD.org> <515B4CFA.9080706@FreeBSD.org> <9bc083a21a73839a0932514ea4f48d0d@webmail.lerctr.org> <515EFBD8.50900@FreeBSD.org> <62827019d058b2a905a0d476565b56c0@webmail.lerctr.org> In-Reply-To: <62827019d058b2a905a0d476565b56c0@webmail.lerctr.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:33:01 -0000 This is a patch against -CURRENT, so the receiving side in your case. On 5.4.2013 18:31, Larry Rosenman wrote: > On 2013-04-05 11:29, Martin Matuska wrote: >> You can use the attached patch, it should fix the problem. >> We are still waiting for code review and a final solution by illumos, >> maybe I will commit this preliminary (or final) fix to head. > > Which side does this need to be on? > > (sending? (since it's dmu_send)? > > (which in my case is 8-STABLE) -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-current@FreeBSD.ORG Fri Apr 5 19:14:08 2013 Return-Path: Delivered-To: freebsd-current@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 40E37ACF; Fri, 5 Apr 2013 19:14:08 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD1890E; Fri, 5 Apr 2013 19:14:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=G/oXQpDNSosTluy7lZPshhLmzL3VrbMN6JBnqbkmN2I=; b=C1weHzuKzc7Pm/F6vibmyDJlV++xyBxBkYKUXY+oi4cMJto0lnMT2YzryDdc3mAOas4dwt8fLYKnafULwIzg4i6nKgl1V/kKnxYTdRLuRmaU62PTo+SOtmgtjxfsuVRLj0935yrgFAmMfYxdDs9qC2WRl9qxSGNfXMqdJ/9LyMY=; Received: from localhost.lerctr.org ([127.0.0.1]:57968 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UOC5P-00040v-2U; Fri, 05 Apr 2013 14:14:07 -0500 Received: from [32.97.110.60] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 05 Apr 2013 14:14:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 05 Apr 2013 14:14:07 -0500 From: Larry Rosenman To: Matthew Ahrens Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT In-Reply-To: References: <5159EF29.6000503@FreeBSD.org> <515B4CFA.9080706@FreeBSD.org> <9bc083a21a73839a0932514ea4f48d0d@webmail.lerctr.org> <515EFBD8.50900@FreeBSD.org> Message-ID: <54dd43a8fbd0fbed24c84152f2502471@webmail.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.5 X-Spam-Score: -5.3 (-----) X-LERCTR-Spam-Score: -5.3 (-----) X-Spam-Report: SpamScore (-5.3/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.373 X-LERCTR-Spam-Report: SpamScore (-5.3/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.373 Cc: freebsd-fs , freebsd-current@freebsd.org, Martin Matuska X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 19:14:08 -0000 On 2013-04-05 14:07, Matthew Ahrens wrote: > I am working on integrating a fix into illumos.  FYI, the patch you > attached will not quite work, because you are using different tags to > hold and release the dataset (FTAG is a macro which has a > calling-function-specific value). > > --matt > Might this also be part of the invalid datastream issue I was seeing? Is there anything I can provide to help Illumos with this issue? Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Apr 5 19:07:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3F4E89C7 for ; Fri, 5 Apr 2013 19:07:11 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by mx1.freebsd.org (Postfix) with ESMTP id B6DE58D9 for ; Fri, 5 Apr 2013 19:07:10 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id s10so4086703lbi.19 for ; Fri, 05 Apr 2013 12:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DrXZ67FhYBxCDstvsRgV4GImZWFlTEoJZ1/ZeaaEeRA=; b=BLs75w8atsBALAsGUkEhXtAHBQFoFm2DCcFpQAVEei3X9SoouTF3qny13tAUNlYRUT RndPdzZWVxxWqEoF3BLHYllMuZAPKG5dB2q3PC43CwmD/CdcByLETXxyz/K+PdZKeTOR wWv4ts/mAQuT/xh/ICxqaiLc5+8igactsag5U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=DrXZ67FhYBxCDstvsRgV4GImZWFlTEoJZ1/ZeaaEeRA=; b=JTv56G5Oprh49akBewOGb7MrZj0yMm7EmS+ZEA5bp2n+cRNy6C/WAIL0jkmmMRYxBc BVCjh3Iez9PfA/LZqgMwQK1OrG6diFwjKwaG3jr1PGgyGUsYLKng95h21nFz6Dh0krI8 iF3mClFtpOedWy/u+pILEbg2RHKqQ0uUeLx/+j7pQwpOXpioKZLYzMBN+aVKhgQpudyd X6BiSf1Kh06+NgBECPDRaOBSYtMbSkHtcLAqNwqIazN5Ofz2UJJ75Ts/DtK3hiQ2PH28 g434dGS+BybjGgzW0CMqSEOhZUKBF4tI1wuTyaUrS3m8aqSTc0zCZJCrEomS6VtRG1DD yBWA== MIME-Version: 1.0 X-Received: by 10.112.160.66 with SMTP id xi2mr6796996lbb.97.1365188829215; Fri, 05 Apr 2013 12:07:09 -0700 (PDT) Received: by 10.114.26.202 with HTTP; Fri, 5 Apr 2013 12:07:09 -0700 (PDT) In-Reply-To: <515EFBD8.50900@FreeBSD.org> References: <5159EF29.6000503@FreeBSD.org> <515B4CFA.9080706@FreeBSD.org> <9bc083a21a73839a0932514ea4f48d0d@webmail.lerctr.org> <515EFBD8.50900@FreeBSD.org> Date: Fri, 5 Apr 2013 12:07:09 -0700 Message-ID: Subject: Re: [CRASH] ZFS recv (fwd)/CURRENT From: Matthew Ahrens To: Martin Matuska X-Gm-Message-State: ALoCoQmlXcJyOSFehzVV9/ltrvdhveI9H61sfG6hRGSS1r/hLikpwvsZTqTGgS/ctf4JRUEpAUHT X-Mailman-Approved-At: Fri, 05 Apr 2013 19:28:31 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs , freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 19:07:11 -0000 I am working on integrating a fix into illumos. FYI, the patch you attached will not quite work, because you are using different tags to hold and release the dataset (FTAG is a macro which has a calling-function-specific value). --matt On Fri, Apr 5, 2013 at 9:29 AM, Martin Matuska wrote: > You can use the attached patch, it should fix the problem. > We are still waiting for code review and a final solution by illumos, > maybe I will commit this preliminary (or final) fix to head. > > mm > > On 5.4.2013 16:49, Larry Rosenman wrote: > > On 2013-04-02 16:26, Martin Matuska wrote: > >> On 1. 4. 2013 22:33, Martin Matuska wrote: > >>> This error seems to be limited to sending deduplicated streams. Does > >>> sending without "-D" work ok? This might be a vendor error as well. > >>> > >>> On 1.4.2013 20:05, Larry Rosenman wrote: > >>>> Re-Sending. Any ideas, guys/gals? > >>>> > >>>> This really gets in my way. > >>>> > >> This may be also related to: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=176978 > > Taking off -D does get around the panic. > > > > What information can I provide to help fix it? > > > > I *CAN* provide access to both sides via SSH. > > > > > > > -- > Martin Matuska > FreeBSD committer > http://blog.vx.sk > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Apr 5 20:33:21 2013 Return-Path: Delivered-To: freebsd-current@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 AAAFAB87 for ; Fri, 5 Apr 2013 20:33:21 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5B5C34 for ; Fri, 5 Apr 2013 20:33:21 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id 11so2437074vbf.22 for ; Fri, 05 Apr 2013 13:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=92lzhUmZeLrky5o41HzJymKbM5GLMJh7iXXUdWOI7c8=; b=HCm60qRoGuHYFCZWfj7P5uaZO71n+XROWi7yBq8Q7R9EVzAv+g1NcX/YoFWsdTx23O QQ6zOLH0xNj1Cb6aaIaY2MhiDDis/8OH+bbuDq59B6QdNrvBL6siBYY6mEhw3DkW9i1Q o9FKx4+15wZwGzaRV+OhPzkYFnKjFNcacRIfA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=92lzhUmZeLrky5o41HzJymKbM5GLMJh7iXXUdWOI7c8=; b=SD5oABIgeExS/Drn7jWBLC6ccUiTbXuS+c6QadR9LCwjkhQ1Xw/nosAoZFOY7qmLr7 AtSXFI1/LipyPdKBz5vK5Gx1ex5L4P7GVgk3oM2WQ65sORRChOsjD9LIb2ipXvOLa5l5 DbFxn9MiiKdSu8RC24nYdItrkIhiCFsxucWC0ZA4wS2iGexG7el9b6wZV3XISt5FHFle zOPRf2JEZoMJZFhGESYoqd4YZhIu191W6LytnAGDLvtjWojwxtAxv4qSxr+lQVy0TcNZ 3w0H4OT3TSMm6bI3lL4qNq2q3UjHrjNflgrQlwBD61S8C5lrKOFbF1EcHepHM6Dte4jZ lpDg== MIME-Version: 1.0 X-Received: by 10.52.16.105 with SMTP id f9mr7853333vdd.117.1365194000810; Fri, 05 Apr 2013 13:33:20 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Fri, 5 Apr 2013 13:33:20 -0700 (PDT) In-Reply-To: References: <20130402085222.GH76816@FreeBSD.org> Date: Fri, 5 Apr 2013 13:33:20 -0700 Message-ID: Subject: Re: Anyone have scripts for managing interfaces under new CARP setup? From: Peter Wemm To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn//ZypJELsZG4BwJlYKrqHCDV0BS3eMW7EinPVQCAJXWycdtj+HU2ZZseUYeDB2hX9o7ox Cc: Gleb Smirnoff , FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 20:33:21 -0000 On Tue, Apr 2, 2013 at 3:37 PM, Freddie Cash wrote: > On 2013-04-02 1:52 AM, "Gleb Smirnoff" wrote: >> >> Freddie, >> >> On Wed, Mar 27, 2013 at 04:10:03PM -0700, Freddie Cash wrote: >> F> Just curious if anyone has any scripts for managing fail-over of > multiple >> F> interfaces using the new CARP setup in 10-CURRENT. >> F> >> F> Fail-over of all CARP vhids associated with a single interface is > working >> F> correctly. But, I have 2 separate, physical interfaces running with > CARP, >> F> and want to fail-over everything if one of the links (or boxes) goes > down. >> F> >> F> Figured I'd ask around to see if anyone has done something like this >> F> already. I've been playing with devd.conf settings and logging > events, but >> F> don't have anything written up to do the actual switch yet. >> >> Same as for old CARP, you can achieve behavior when a box with lower >> advskew yields master status to a second one, setting: >> >> sysctl net.inet.carp.preempt=1 >> >> If an interface on the master has proper link state notification to the >> kernel, then once the interface goes down, the advskew on the box will be >> demoted and backup box will preempt it. > > That's how I have things set and it wasn't switching the 2nd interface. > > However, I think that may be due to the IPFW rules on one interface > blocking CARP multicast packets on that interface, while they were going > through correctly on the 2nd interface. I'll see if I can schedule a manual > test later this week now that IPFW is configured correctly. > > Thanks for the confirmation of things are supposed to work. We use new-carp on 10.x on the freebsd.org cluster. There's machines with 10+ vlans with carp on each and pf. I find some of the replacement tools a little lacking but one thing I've done is use a dummy vlan to cause an entire machine to demote itself based on bgp default-route state. I wrote a script to do this before I became aware of ifstated(8). This is necessary for us more because of the unusual uplink arrangement we have at one of the cluster locations. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-current@FreeBSD.ORG Fri Apr 5 23:06:19 2013 Return-Path: Delivered-To: current@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 C0EAC806; Fri, 5 Apr 2013 23:06:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3AC1C2; Fri, 5 Apr 2013 23:06:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r35N6Bpk028535; Fri, 5 Apr 2013 19:06:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r35N6BT2028534; Fri, 5 Apr 2013 23:06:11 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 5 Apr 2013 23:06:11 GMT Message-Id: <201304052306.r35N6BT2028534@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , Subject: [head tinderbox] source tree update failure Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 23:06:19 -0000 TB --- 2013-04-05 23:00:00 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-05 23:00:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-05 23:00:00 - starting HEAD tinderbox run for none/none TB --- 2013-04-05 23:00:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2013-04-05 23:00:00 - cd /tinderbox/HEAD/none/none TB --- 2013-04-05 23:00:00 - /usr/local/bin/svn cleanup /src TB --- 2013-04-05 23:00:08 - /usr/local/bin/svn update /src TB --- 2013-04-05 23:00:20 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-04-05 23:00:20 - WARNING: sleeping 30 s and retrying... TB --- 2013-04-05 23:00:50 - /usr/local/bin/svn update /src TB --- 2013-04-05 23:01:03 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-04-05 23:01:03 - WARNING: sleeping 60 s and retrying... TB --- 2013-04-05 23:02:03 - /usr/local/bin/svn update /src TB --- 2013-04-05 23:02:16 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-04-05 23:02:16 - WARNING: sleeping 90 s and retrying... TB --- 2013-04-05 23:03:46 - /usr/local/bin/svn update /src TB --- 2013-04-05 23:03:58 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-04-05 23:03:58 - WARNING: sleeping 120 s and retrying... TB --- 2013-04-05 23:05:58 - /usr/local/bin/svn update /src TB --- 2013-04-05 23:06:11 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-04-05 23:06:11 - ERROR: unable to check out the source tree TB --- 2013-04-05 23:06:11 - 2.41 user 3.29 system 370.80 real http://tinderbox.freebsd.org/tinderbox-head-update-HEAD-none-none.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 6 17:14:48 2013 Return-Path: Delivered-To: freebsd-current@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 BD91BD22; Sat, 6 Apr 2013 17:14:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2C278D; Sat, 6 Apr 2013 17:14:46 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA04486; Sat, 06 Apr 2013 20:14:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UOWhR-0006CP-70; Sat, 06 Apr 2013 20:14:45 +0300 Message-ID: <51605804.8080906@FreeBSD.org> Date: Sat, 06 Apr 2013 20:14:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Baldwin Subject: Re: call suspend_cpus() under smp_ipi_mtx References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org> <201304011052.18370.jhb@freebsd.org> <515DB988.1080100@FreeBSD.org> In-Reply-To: <515DB988.1080100@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 17:14:48 -0000 on 04/04/2013 20:34 Andriy Gapon said the following: > This seems to work without problems or any warnings with WITNESS && > !WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the > relevant code paths. > > P.S. Looking through history it seems that in r169391 intr_table_lock > was changed from a spinlock to a sx lock (later it was changed to the current > mutex). The commit message explains why spinlock was not needed, but it doesn't > seem to say why it was unacceptable: Hmm, looks like I missed the elephant. apic_free_vector is called with intr_table_lock held and it calls sched_bind(). I need to re-think all of think from the scratch... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Apr 6 19:59:36 2013 Return-Path: Delivered-To: freebsd-current@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 DA8606AD for ; Sat, 6 Apr 2013 19:59:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id A4E0DE1B for ; Sat, 6 Apr 2013 19:59:36 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:434:c78e:2de8:4e1f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id E83224AC58 for ; Sat, 6 Apr 2013 23:59:35 +0400 (MSK) Date: Sat, 6 Apr 2013 23:59:31 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <119585652.20130406235931@serebryakov.spb.ru> To: freebsd-current@freebsd.org Subject: bsnmpd cannot start on fresh -CURRENT: snmpd[1597]: lm_load: open /usr/lib/snmp_hostres.so: Shared object has no run-time symbol table MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 19:59:36 -0000 Hello, Freebsd-current. I've built new nanobsd image for my new router, based on -CURRENT r249196, and bsnmpd cannot start with enabled host resources plugin: snmpd[1597]: lm_load: open /usr/lib/snmp_hostres.so: Shared object has no run-time symbol table But it can load /usr/lib/snmp_wlan.so without problems. What do I do wrong? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sat Apr 6 20:53:31 2013 Return-Path: Delivered-To: freebsd-current@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 2D96AE5B; Sat, 6 Apr 2013 20:53:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E83A4FE8; Sat, 6 Apr 2013 20:53:30 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:434:c78e:2de8:4e1f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 463FC4AC58; Sun, 7 Apr 2013 00:53:28 +0400 (MSK) Date: Sun, 7 Apr 2013 00:53:23 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1045318881.20130407005323@serebryakov.spb.ru> To: Lev Serebryakov Subject: SOLVED bsnmpd cannot start on fresh -CURRENT: snmpd[1597]: lm_load: open /usr/lib/snmp_hostres.so: Shared object has no run-time symbol table In-Reply-To: <119585652.20130406235931@serebryakov.spb.ru> References: <119585652.20130406235931@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 20:53:31 -0000 Hello, Lev. You wrote 6 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 23:59:31: LS> snmpd[1597]: lm_load: open /usr/lib/snmp_hostres.so: Shared LS> object has no run-time symbol table LS> But it can load /usr/lib/snmp_wlan.so without problems. Sorry for noise, it seems, USB flash is very bad storage: it fails on third rewrite and broke some files :( --=20 // Black Lion AKA Lev Serebryakov