From owner-freebsd-stable@FreeBSD.ORG Sun Oct 24 02:09:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DD85106564A for ; Sun, 24 Oct 2010 02:09:04 +0000 (UTC) (envelope-from sector214@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFFC18FC0C for ; Sun, 24 Oct 2010 02:09:03 +0000 (UTC) Received: by wyb42 with SMTP id 42so2209484wyb.13 for ; Sat, 23 Oct 2010 19:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/lffiPlmlp6+8p7XxTk3UJUWde+siWNvRLCZqlsZW8E=; b=mTvJs9SqvdYc54qSN/tM4X+dRKkmpwOoQCnT/1qtys7Z1nqkUQ53sXYoh/GLSf447S JSqxI2ANGYMQk1Px/QCa81l7UaYswzdTfP6Zwjx2UU3itYSSCrwtJDfqCOJS7O/5WkCf 6k3sS8yKmtrlw0Gpv716zYorzufMm/GvLDCz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QEb5wSq02meB9zIleerCnLd5DgyqibbJTLmDdqEVT4JUsRm+IUG5nWfnHjj7VsTLBL oYYJIFwWS/v5EVX2fD6+reVuVh25BWfqtPLoc0O17XHNzJ+O+gFNcekgoxlPani2o0XY ZCY8pu/kat/ZJaYOz0C4srRGILVDog2VLzY4s= MIME-Version: 1.0 Received: by 10.227.157.196 with SMTP id c4mr4751022wbx.174.1287886141708; Sat, 23 Oct 2010 19:09:01 -0700 (PDT) Received: by 10.227.42.36 with HTTP; Sat, 23 Oct 2010 19:09:01 -0700 (PDT) In-Reply-To: References: <4CC1A850.5060601@icyb.net.ua> <4CC1BDBE.2020008@icyb.net.ua> <4CC1F45E.3060803@icyb.net.ua> Date: Sat, 23 Oct 2010 22:09:01 -0400 Message-ID: From: Simon Chang To: Scot Hetzel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Correct procedure for cross-compilation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 02:09:04 -0000 On Sat, Oct 23, 2010 at 2:12 AM, Scot Hetzel wrote: > On Fri, Oct 22, 2010 at 9:35 PM, Simon Chang wrote: > > OK... except that this flies in the face of this part from the Handbook: > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-lan.html > > > That part in the handbook only works when both the build machine and > the target machines are running the same O/S arch (i.e. i386). > > > Also, if you are right, where should I run mergemaster??? > > > You can run mergemaster from either the build machine or the target > machine. The target machine would need to have the /usr/src NFS > mounted. > > To use mergemaster on the build machine use: > > mergemaster -A i386 -D /path/to/nfs/mnt/ > > Scot > Great, thank you Scot and Andriy for your suggestions. While I am very comfortable with the build procedure for single arch/cputype, I am relatively new to cross compiling. I will put your advice to use and let you know if I run into problems. Cheers! SC From owner-freebsd-stable@FreeBSD.ORG Sun Oct 24 09:04:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5862E1065675 for ; Sun, 24 Oct 2010 09:04:04 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D75A18FC13 for ; Sun, 24 Oct 2010 09:04:03 +0000 (UTC) Received: by fxm17 with SMTP id 17so1965649fxm.13 for ; Sun, 24 Oct 2010 02:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type; bh=EMWYFtJwHiqesW3NUmKtYjhMDtgYqVlE9pVcFj3onMY=; b=NicfWQ0anRIe2xBCPX0W+sHwRpk83Rb3v5/+m6QhEnKgEc5wd6ej1EM9YgyeBK1ep9 u3cbrdrASCP4CcUEWyB/iVwST5DE5PO9xqZaO4NehHBn5Yt0xaOByiSXdPPu8NlLcLo2 JodRUxoiuPpdJLTw6+zoE3XYGScV5vaC4QlG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=h3nwzU671G/pOxxJGOcN9RIEOIVykF4HoqzgNl2pvnyQsJy/G9Kc3NPgepDKsOArLN 4++Rx6Y28NSKcMzjJxYc23OPzI8KZOvBZepm6R0Mk6vBe40HSJNypBb7T2C2qZDHOoVV ddTBllUdIgheVQ6wA19Z330pMAwgYNX33Sm2I= MIME-Version: 1.0 Received: by 10.103.175.13 with SMTP id c13mr6391773mup.30.1287911042658; Sun, 24 Oct 2010 02:04:02 -0700 (PDT) Received: by 10.223.111.140 with HTTP; Sun, 24 Oct 2010 02:04:02 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Oct 2010 11:04:02 +0200 Message-ID: From: Spil Oss To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Name and JID support in /etc/rc.d/jail and jail(8) documentation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 09:04:04 -0000 Hi All, Created a small patch for 8.1 to add name support to /etc/rc.d/jail. This doesn't upgrade /etc/rc.d/jail to the overhauled invocation of 8.0 but merely adds the ability to set a jail's name on start which was added in FreeBSD 7.2 (May 2009). Could this patch be considered to be applied to stable? # diff -ruN /etc/rc.d/jail-8.1 /etc/rc.d/jail --- /etc/rc.d/jail-8.1 2010-07-21 07:19:46.000000000 +0200 +++ /etc/rc.d/jail 2010-10-24 10:55:14.000000000 +0200 @@ -38,6 +38,7 @@ _fdescdir="${_devdir}/fd" _procdir="${_rootdir}/proc" eval _hostname=\"\$jail_${_j}_hostname\" + eval _name=\"\$jail_${_j}_name\" eval _ip=\"\$jail_${_j}_ip\" eval _interface=\"\${jail_${_j}_interface:-${jail_interface}}\" eval _exec=\"\$jail_${_j}_exec\" @@ -122,6 +123,7 @@ debug "$_j procfs enable: $_procfs" debug "$_j mount enable: $_mount" debug "$_j hostname: $_hostname" + debug "$_j name: $_name" debug "$_j ip: $_ip" jail_show_addresses ${_j} debug "$_j interface: $_interface" @@ -635,6 +637,10 @@ i=$((i + 1)) done + if [ -n "${_name}" ] ; then + _flags="${_flags} -n ${_name}" + fi + eval ${_setfib} jail ${_flags} -i ${_rootdir} ${_hostname} \ \"${_addrl}\" ${_exec_start} > ${_tmp_jail} 2>&1 Kind regards, Spil. On Sun, Oct 24, 2010 at 10:52 AM, Spil Oss wrote: > Hi All, > > When starting a jail you can, as of 8.0 if I'm not mistaken, set the > JID and name for a jail. This change doesn't seem to have been > incorporated into the /etc/rc.d/jail script? Looking at > http://wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet it wouldn't > be a huge change to add name support. The other additions in that > script look a lot more intrusive. Are there any plans to merge this > patch into the jail rc-script or is this "v2" style of jail invocation > still considered to be experimental? As of 8.1 is seems to no longer > be considered experimental looking at the release notes. > > The jail(8) documentation (mine lists FreeBSD 8.1 January 17, 2010) > seems to be missing documentation on the vnet command (due to the > experimental status)? > > Kind regards, > > Spil. > From owner-freebsd-stable@FreeBSD.ORG Sun Oct 24 09:16:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB1A9106566C for ; Sun, 24 Oct 2010 09:16:18 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 809388FC08 for ; Sun, 24 Oct 2010 09:16:18 +0000 (UTC) Received: by fxm17 with SMTP id 17so1969774fxm.13 for ; Sun, 24 Oct 2010 02:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=orCCQklYwkDwkaeaMUrmzueg1dmIHwAdLfJBvOR1n50=; b=QMzxEKpBBxuGBqhDJyP0oLSqs0gcVTqXtu4lIFA2c5QYq/OXiU3f/2kschycmxYZAZ n4i8wLYkaZf7saI3Fpq5l20Zl+kS7OGEzHkqigDmaeSU8gvI/wu5irOCDnEJnfCD8qOw /7Y6pa1LJBfeGXfN5ny8yAVl641uDYX9CyWEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=GRFqhbmbevXqD62KGMWZ+CR5N42+pehCfS+pEIYYpcu7bWSl3gXH8D5TVCfwy5AQbc jOSz2Koo1zkOduUCKq+CUoOqAy9QhCehmPH9zJaP5x13aE438VHQW/vCyscwJdljgoEM dzA/3/4QBwWKcPr+J/zT2JxRU4LYRgrsvBe0E= MIME-Version: 1.0 Received: by 10.103.131.9 with SMTP id i9mr6305052mun.77.1287910360645; Sun, 24 Oct 2010 01:52:40 -0700 (PDT) Received: by 10.223.111.140 with HTTP; Sun, 24 Oct 2010 01:52:40 -0700 (PDT) Date: Sun, 24 Oct 2010 10:52:40 +0200 Message-ID: From: Spil Oss To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Name and JID support in /etc/rc.d/jail and jail(8) documentation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 09:16:19 -0000 Hi All, When starting a jail you can, as of 8.0 if I'm not mistaken, set the JID and name for a jail. This change doesn't seem to have been incorporated into the /etc/rc.d/jail script? Looking at http://wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet it wouldn't be a huge change to add name support. The other additions in that script look a lot more intrusive. Are there any plans to merge this patch into the jail rc-script or is this "v2" style of jail invocation still considered to be experimental? As of 8.1 is seems to no longer be considered experimental looking at the release notes. The jail(8) documentation (mine lists FreeBSD 8.1 January 17, 2010) seems to be missing documentation on the vnet command (due to the experimental status)? Kind regards, Spil. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 24 12:47:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0162106564A for ; Sun, 24 Oct 2010 12:47:22 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5FAF18FC16 for ; Sun, 24 Oct 2010 12:47:21 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 2A61819E02A; Sun, 24 Oct 2010 14:47:20 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 3768E19E023; Sun, 24 Oct 2010 14:47:18 +0200 (CEST) Message-ID: <4CC42ADB.9030309@quip.cz> Date: Sun, 24 Oct 2010 14:47:23 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.14) Gecko/20100930 SeaMonkey/2.0.9 MIME-Version: 1.0 To: spil.oss@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Name and JID support in /etc/rc.d/jail and jail(8) documentation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 12:47:22 -0000 Spil Oss wrote: > Hi All, > > Created a small patch for 8.1 to add name support to /etc/rc.d/jail. > This doesn't upgrade /etc/rc.d/jail to the overhauled invocation of > 8.0 but merely adds the ability to set a jail's name on start which > was added in FreeBSD 7.2 (May 2009). > > Could this patch be considered to be applied to stable? [...] I don't think it will be committed. I talked about it in March 2009 and bz said: "I think there is no need to add anything..." "For jail names just add -n name to jail__flags" http://lists.freebsd.org/pipermail/freebsd-jail/2009-March/000751.html Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sun Oct 24 12:50:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B37106566B for ; Sun, 24 Oct 2010 12:50:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 49BAD8FC14 for ; Sun, 24 Oct 2010 12:50:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B1AEB41C752; Sun, 24 Oct 2010 14:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id wfhjmXf4rMyg; Sun, 24 Oct 2010 14:50:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id D6C6941C750; Sun, 24 Oct 2010 14:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id DC0C244496D; Sun, 24 Oct 2010 12:45:12 +0000 (UTC) Date: Sun, 24 Oct 2010 12:45:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Spil Oss In-Reply-To: Message-ID: <20101024123928.Q66242@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Name and JID support in /etc/rc.d/jail and jail(8) documentation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-jail@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 12:50:08 -0000 On Sun, 24 Oct 2010, Spil Oss wrote: Hi, > Created a small patch for 8.1 to add name support to /etc/rc.d/jail. > This doesn't upgrade /etc/rc.d/jail to the overhauled invocation of > 8.0 but merely adds the ability to set a jail's name on start which > was added in FreeBSD 7.2 (May 2009). > > Could this patch be considered to be applied to stable? > > # diff -ruN /etc/rc.d/jail-8.1 /etc/rc.d/jail [snip] short answer: no 1) add -n to the defaults of jail__flags in rc.conf and be done just now. No need for a new variable. 2) you want to follow the new jail management on the freebsd-jail list. I would expect that there will just be no further changes to the rc script unless security related ones. > On Sun, Oct 24, 2010 at 10:52 AM, Spil Oss wrote: >> Hi All, >> >> When starting a jail you can, as of 8.0 if I'm not mistaken, set the >> JID and name for a jail. This change doesn't seem to have been >> incorporated into the /etc/rc.d/jail script? Looking at >> http://wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet it wouldn't >> be a huge change to add name support. The other additions in that >> script look a lot more intrusive. Are there any plans to merge this >> patch into the jail rc-script or is this "v2" style of jail invocation >> still considered to be experimental? As of 8.1 is seems to no longer >> be considered experimental looking at the release notes. The new style version was never considered "experimental". It wasn't just not advertised that much due to the lack of 2) above. >> The jail(8) documentation (mine lists FreeBSD 8.1 January 17, 2010) >> seems to be missing documentation on the vnet command (due to the >> experimental status)? Right, vnets are still considered experimental. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 08:22:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72366106566C for ; Mon, 25 Oct 2010 08:22:12 +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 A49808FC19 for ; Mon, 25 Oct 2010 08:22:11 +0000 (UTC) Received: from porto.topspin.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 LAA01184 for ; Mon, 25 Oct 2010 11:22:10 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PAIJl-000OsF-UE for freebsd-stable@FreeBSD.org; Mon, 25 Oct 2010 11:22:09 +0300 Message-ID: <4CC53E31.5090202@freebsd.org> Date: Mon, 25 Oct 2010 11:22:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Subject: [HEADSUP] KDB, KDB_TRACE are now in GENERIC kernels X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 08:22:12 -0000 KDB and KDB_TRACE are now included into GENERIC kernels on stable/8 branch. This should not break anything for you. But if you include GENERIC into your custom kernel config and you already have the above options there, then you will get warnings about duplicate options. You can simply remove the second copy. The purpose of the change is to get a stack trace from a panic or a trap in a default installation. We still don't configure any debugger backend by default. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 08:49:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9C8106566B; Mon, 25 Oct 2010 08:49:19 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 51D3D8FC15; Mon, 25 Oct 2010 08:49:19 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PAIk1-0002XF-Ks; Mon, 25 Oct 2010 09:49:17 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAIk1-000Bfy-Jb; Mon, 25 Oct 2010 09:49:17 +0100 Date: Mon, 25 Oct 2010 09:49:17 +0100 Message-Id: To: pjd@FreeBSD.org, to.my.trociny@gmail.com In-Reply-To: <20101022181301.GA2014@garage.freebsd.pl> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 08:49:19 -0000 > What speed do you expect? IIRC from my tests, I was able to saturate > 1Gbit link with initial synchronization. Also note, that hast > synchronize only differences, and not the entire thing after crash or > power failure. I should probably have put some numbers in the original email, sorry! I am looking here at an initial syc of the entire mirror, not just the differences. ggate+gmirror gives me about 89 meg/second hast gives me about 44 meg/second The boxes have gigabit connectin between them - not directly cross connected, but they are plugged into the same switch. I have lagg doing LACP on them. But, as the setup is identical network-wise for each box then I don't think it's that. I have this is sysctl.conf kern.ipc.maxsockbuf=1048576 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 I will give the recompile with changed contants a try (maybe later today) - do I need to do this at both ends though, as I want to avoid downtime if possible. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 09:22:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476591065695; Mon, 25 Oct 2010 09:22:12 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5338FC0A; Mon, 25 Oct 2010 09:22:12 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PAJFh-0002gh-1o; Mon, 25 Oct 2010 10:22:01 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAJFh-000Bkx-0o; Mon, 25 Oct 2010 10:22:01 +0100 Date: Mon, 25 Oct 2010 10:22:01 +0100 Message-Id: To: oberman@es.net, to.my.trociny@gmail.com In-Reply-To: <20101022184551.B587D1CC3E@ptavv.es.net> From: Pete French Cc: pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 09:22:12 -0000 > If you are 50ms RTT from the remote system, the default buffer size will > limit you to about 21 Mbps. Formula is Window-size(in bits/sec)/RTT(in > sec.) The result is the absolute maximum possible bandwidth in > bits/sec. Of course, you can replace window size with the bytes/sec and > the result will be in bytes. I've got a ping time of around 100us (ranges from 0.093ms to 0.109ms) So from your formula I should be able to saturate 1 gigabit ether. I was getting around 90 meg/sevond using ggate Am going to experiment now with the recompiled hastd using the buffesr sizes I was using with ggate and see what happens. thanks, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 09:27:16 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826BC106564A; Mon, 25 Oct 2010 09:27:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (unknown [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 3BDBA8FC14; Mon, 25 Oct 2010 09:27:16 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o9P9R6pU088235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Oct 2010 05:27:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.4/8.14.4) with ESMTP id o9P9R6Y2097570; Mon, 25 Oct 2010 05:27:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 668AF1B5060; Mon, 25 Oct 2010 05:27:06 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20101025092706.668AF1B5060@freebsd-stable.sentex.ca> Date: Mon, 25 Oct 2010 05:27:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 09:27:16 -0000 TB --- 2010-10-25 08:30:07 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-10-25 08:30:07 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2010-10-25 08:30:07 - cleaning the object tree TB --- 2010-10-25 08:30:31 - cvsupping the source tree TB --- 2010-10-25 08:30:31 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2010-10-25 08:30:43 - building world TB --- 2010-10-25 08:30:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-25 08:30:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-25 08:30:43 - TARGET=i386 TB --- 2010-10-25 08:30:43 - TARGET_ARCH=i386 TB --- 2010-10-25 08:30:43 - TZ=UTC TB --- 2010-10-25 08:30:43 - __MAKE_CONF=/dev/null TB --- 2010-10-25 08:30:43 - cd /src TB --- 2010-10-25 08:30:43 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 25 08:30:44 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/share/man/man9/vm_page_grab.9 > vm_page_grab.9.gz gzip -cn /src/share/man/man9/vm_page_hold.9 > vm_page_hold.9.gz gzip -cn /src/share/man/man9/vm_page_insert.9 > vm_page_insert.9.gz gzip -cn /src/share/man/man9/vm_page_io.9 > vm_page_io.9.gz gzip -cn /src/share/man/man9/vm_page_lookup.9 > vm_page_lookup.9.gz gzip -cn /src/share/man/man9/vm_page_protect.9 > vm_page_protect.9.gz gzip -cn /src/share/man/man9/vm_page_rename.9 > vm_page_rename.9.gz make: don't know how to make vm_page_sleep_if_busy.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-25 09:27:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-25 09:27:06 - ERROR: failed to build world TB --- 2010-10-25 09:27:06 - 2845.79 user 298.20 system 3418.77 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 10:55:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E67A01065693; Mon, 25 Oct 2010 10:55:35 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id ACD2D8FC18; Mon, 25 Oct 2010 10:55:35 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PAKiE-0004cd-Cx; Mon, 25 Oct 2010 11:55:34 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAKiE-000CdG-C2; Mon, 25 Oct 2010 11:55:34 +0100 Date: Mon, 25 Oct 2010 11:55:34 +0100 Message-Id: To: to.my.trociny@gmail.com In-Reply-To: <861v7ii8mg.fsf@kopusha.home.net> From: Pete French Cc: pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 10:55:36 -0000 > You could change the values and recompile hastd :-). It would be interesting > to know about the results of your experiment (if you do). I changed the buffer sizes to the same as I was using for ggate, but the speed is still the same - 44meg/second (about half of what the link can do) interesting... BTW, the speed appears to be fine for my current load so this isn't a probelm for me per-se, just surprised at the difference in re-sync performance. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 12:12:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEE391065675 for ; Mon, 25 Oct 2010 12:12:46 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 77D2D8FC1D for ; Mon, 25 Oct 2010 12:12:46 +0000 (UTC) Received: by bwz3 with SMTP id 3so2855396bwz.13 for ; Mon, 25 Oct 2010 05:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=E543NKExT6xI7uUlYvOYRd0mfZT2QEd0ZX/WEhpmqg8=; b=cea+F8vnb2EsL6BjQZXcIL3EJq0ZQTXvrEisILARQAVp6wz37CQ4OyLIWCCc/PsmPb s1OmyV6eh8L+/TbU9B6wjkNlxf5/zLrhJqykCHLXCrn27cfLkOJ0Vr+JvvIhXkBrPchE ljWTQUTGddjxbdF7AliTbDsHWn3RaPG2Rq9HQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=TJRyiROROXMX+Qoqd94Gkb12JD0d2f4h3kTcr0Yunxx6jVcBZ1M8e18IKIme6nKhSH 8mJAYKveKN/N/mWQQ6874PjGHKnmzjQ9JahX3PXyIMY8KQMI0SYCMx4bCo7FwL+2nHNO 2QSk47dLAzHiq2YvTtL7C7VY9F0vxYCK8cdm0= Received: by 10.204.73.13 with SMTP id o13mr4839879bkj.173.1288008765330; Mon, 25 Oct 2010 05:12:45 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id p34sm4759740bkf.15.2010.10.25.05.12.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 05:12:43 -0700 (PDT) From: Mikolaj Golub To: Pete French Organization: TOA Ukraine References: Date: Mon, 25 Oct 2010 15:12:42 +0300 In-Reply-To: (Pete French's message of "Mon, 25 Oct 2010 11:55:34 +0100") Message-ID: <86wrp6jwsl.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 12:12:47 -0000 On Mon, 25 Oct 2010 11:55:34 +0100 Pete French wrote: >> You could change the values and recompile hastd :-). It would be interesting >> to know about the results of your experiment (if you do). PF> I changed the buffer sizes to the same as I was using for ggate, but the speed PF> is still the same - 44meg/second (about half of what the link can do) You can check if the queue size is an issue monitoring with netstat Recv-Q and Send-Q for hastd connections during the test. Running something like below: while sleep 1; do netstat -na |grep '\.8457.*ESTAB'; done Also tcpdump may help :-) -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 14:18:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29E261065670 for ; Mon, 25 Oct 2010 14:18:27 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 049A28FC08 for ; Mon, 25 Oct 2010 14:18:26 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PANsX-0001lf-Hv for freebsd-stable@freebsd.org; Mon, 25 Oct 2010 07:18:25 -0700 Message-ID: <30048354.post@talk.nabble.com> Date: Mon, 25 Oct 2010 07:18:25 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <29978939.post@talk.nabble.com> Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 14:18:27 -0000 Warren Block wrote: > > I've had mixed success with cdrecord (sysutils/cdrtools-devel) over the > years. Although growisofs is reputed to be less correct, I can't recall > it ever having a problem. > Isn't cdrtools dependency of growisofs? regards, - Jakub Lach -- View this message in context: http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30048354.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 15:50:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B255B106564A for ; Mon, 25 Oct 2010 15:50:57 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 725108FC13 for ; Mon, 25 Oct 2010 15:50:57 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id o9PFouDm042801; Mon, 25 Oct 2010 09:50:56 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id o9PFouNe042798; Mon, 25 Oct 2010 09:50:56 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 25 Oct 2010 09:50:56 -0600 (MDT) From: Warren Block To: Jakub Lach In-Reply-To: <30048354.post@talk.nabble.com> Message-ID: References: <29978939.post@talk.nabble.com> <30048354.post@talk.nabble.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (wonkity.com [127.0.0.1]); Mon, 25 Oct 2010 09:50:56 -0600 (MDT) Cc: freebsd-stable@freebsd.org Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 15:50:57 -0000 On Mon, 25 Oct 2010, Jakub Lach wrote: > Warren Block wrote: >> >> I've had mixed success with cdrecord (sysutils/cdrtools-devel) over the >> years. Although growisofs is reputed to be less correct, I can't recall >> it ever having a problem. >> > > Isn't cdrtools dependency of growisofs? Yes, although maybe for mkisofs, not the DVD recording code. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 21:34:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C0FB106564A for ; Mon, 25 Oct 2010 21:34:26 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB868FC16 for ; Mon, 25 Oct 2010 21:34:25 +0000 (UTC) Received: from titan.flb.omnilan.net (titan.lo4.flb.omnilan.net [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o9PLK9O8017008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Oct 2010 23:20:09 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host titan.lo4.flb.omnilan.net [172.21.1.150] claimed to be titan.flb.omnilan.net Message-ID: <4CC5F489.50403@omnilan.de> Date: Mon, 25 Oct 2010 23:20:09 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCA339D8350768D81F6034DEE" Subject: POSIX file permission (understanding) problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:34:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCA339D8350768D81F6034DEE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, am I complete stupid or is there a serious problem with 8.1-RELEASE: I can write files which I have no write access to, if I have write access to the directory of the file. How to reproduce (tested with UFS2): mkdir /tmp/testdir touch /tmp/testdir/testfile chown -R nobody:intern /tmp/testdir chmod 751 /tmp/testdir chmod 640 /tmp/testdir/testfile ls -ld /tmp/testdir drwxr-x--x 2 nobody intern 512 25 Okt 23:03 /tmp/testdir ls -l /tmp/testdir total 0 -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile exit id uid=3D9001(harry) gid=3D9001(harry) groups=3D9001(harry),0(wheel),5(operator),68(dialer),919(vboxusers),5090(= intern).... -> Fine so far, editing testfile doesn't work chmod g+w testdir/ (as superuser, exit again) ls -ld testdir drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir ls -l testdir total 0 -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile -> Now editing with vi (as user harry) changes the ownership of the file and writing is successfull: ls -l testdir/ total 2 -rw-r----- 1 harry intern 5 25 Okt 23:10 testfile This means file permission mode is irrelevant if the user has write access to the directory of the file. I can hardly believe that this is intentional. Why does a write lead to owbership changes? How should I give users write access to directories but prohibit deliting particular files? Do I have to use uunlnk flag? Sorry for that basic question, but I must have been missing something in the last 10 years... Thanks in advance, -Harry --------------enigCA339D8350768D81F6034DEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzF9IkACgkQLDqVQ9VXb8gAzQCcDVmfFX0G50Dy8T+KwU4RDKsy KeUAn03wOT2AYa8Yf5oURoPtpbhUnRyk =1vAf -----END PGP SIGNATURE----- --------------enigCA339D8350768D81F6034DEE-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 21:38:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8413310656A7 for ; Mon, 25 Oct 2010 21:38:01 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1E98FC14 for ; Mon, 25 Oct 2010 21:38:00 +0000 (UTC) Received: from titan.flb.omnilan.net (titan.lo4.flb.omnilan.net [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o9PLbxsM017270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Oct 2010 23:37:59 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host titan.lo4.flb.omnilan.net [172.21.1.150] claimed to be titan.flb.omnilan.net Message-ID: <4CC5F8B7.5030706@omnilan.de> Date: Mon, 25 Oct 2010 23:37:59 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4CC5F489.50403@omnilan.de> In-Reply-To: <4CC5F489.50403@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig030BC0BA05B1723CF1CF8054" Subject: Re: POSIX file permission (understanding) problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:38:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig030BC0BA05B1723CF1CF8054 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 25.10.2010 23:20 (localtime): > Hello, >=20 > am I complete stupid or is there a serious problem with 8.1-RELEASE: > I can write files which I have no write access to, if I have write > access to the directory of the file. =2E.. > This means file permission mode is irrelevant if the user has write > access to the directory of the file. I can hardly believe that this is > intentional. Why does a write lead to owbership changes? > How should I give users write access to directories but prohibit > deliting particular files? Do I have to use uunlnk flag? > Sorry for that basic question, but I must have been missing something i= n > the last 10 years... Sorry for the noise, digging through lots of not-deep-enough information I finally found: http://content.hccfl.edu/pollock/aunix1/filepermissions.htm Now I can remember that I already was upset about this, one decade ago, and there was a reason not to use the POSIX permission model at all for so long. In that particular case I'll have to use the uchg flag. Sorry again for the noise! --------------enig030BC0BA05B1723CF1CF8054 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzF+LcACgkQLDqVQ9VXb8joMQCfUmAMzZiAqFbAvIwIiIrZFVy/ eZEAmQFNOS9QEqmjNJ47Jq9d/wn3qPlZ =RFgP -----END PGP SIGNATURE----- --------------enig030BC0BA05B1723CF1CF8054-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 25 22:28:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 166C91065696 for ; Mon, 25 Oct 2010 22:28:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id F16DA8FC08 for ; Mon, 25 Oct 2010 22:28:47 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LAV008W9AFFWC70@asmtp024.mac.com> for freebsd-stable@freebsd.org; Mon, 25 Oct 2010 15:28:28 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-25_11:2010-10-25, 2010-10-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010250150 From: Chuck Swiger In-reply-to: <4CC5F489.50403@omnilan.de> Date: Mon, 25 Oct 2010 15:28:27 -0700 Message-id: <88CBD70C-DA5A-4B3A-A703-7C0D6B189697@mac.com> References: <4CC5F489.50403@omnilan.de> To: Harald Schmalzbauer X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org Subject: Re: POSIX file permission (understanding) problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:28:48 -0000 On Oct 25, 2010, at 2:20 PM, Harald Schmalzbauer wrote: > chmod g+w testdir/ (as superuser, exit again) > ls -ld testdir > drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir > ls -l testdir > total 0 > -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile > > -> Now editing with vi (as user harry) changes the ownership of the > file and writing is successfull: > ls -l testdir/ > total 2 > -rw-r----- 1 harry intern 5 25 Okt 23:10 testfile [ ... ] > Why does a write lead to owbership changes? You can't actually write to the file when owned by nobody as harry. However, since you have write permissions to the directory, you can delete the file and write a new file which is also called testfile. $ echo "hi" >> testfile cannot create testfile: Permission denied ...and in vi, force write ("w!") gives "Error: testfile: Permission denied." Perhaps you're using some odd tweaks to vi...? > How should I give users write access to directories but prohibit deliting particular files? Do I have to use uunlnk flag? No, you can set the sticky bit on the directory, which is what /tmp uses: STICKY DIRECTORIES A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 00:09:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E37B5106564A for ; Tue, 26 Oct 2010 00:09:39 +0000 (UTC) (envelope-from sterling@camdensoftware.com) Received: from wh2.interactivevillages.com (wh2.interactivevillages.com [75.125.250.34]) by mx1.freebsd.org (Postfix) with ESMTP id ACB918FC23 for ; Tue, 26 Oct 2010 00:09:39 +0000 (UTC) Received: from 174-21-107-164.tukw.qwest.net ([174.21.107.164] helo=_HOSTNAME_) by wh2.interactivevillages.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PAVXh-0007bu-1b for freebsd-stable@freebsd.org; Mon, 25 Oct 2010 15:29:27 -0700 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Mon, 25 Oct 2010 15:37:44 -0700 Date: Mon, 25 Oct 2010 15:37:44 -0700 From: Chip Camden To: freebsd-stable@freebsd.org Message-ID: <20101025223744.GD2107@libertas.local.camdensoftware.com> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rz+pwK2yUstbofK6" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Company: Camden Software Consulting URL: http://camdensoftware.com X-PGP-Key: http://pgp.mit.edu:11371/pks/lookup?search=0xD6DBAF91 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh2.interactivevillages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - camdensoftware.com Subject: stable GENERIC kernel build fails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 00:09:40 -0000 --rz+pwK2yUstbofK6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After a csup, building the GENERIC kernel on amd64 fails with: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=3D"cc -E" CC=3D"cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector cc: /usr/src/sys/libkern/inet_ntop.c: No such file or directory cc: /usr/src/sys/libkern/inet_pton.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. libertas/usr/src# uname -a FreeBSD libertas.local.camdensoftware.com 8.1-STABLE FreeBSD 8.1-STABLE #81= : Sun Oct 24 11:46:14 PDT 2010 sterling@libertas.local.camdensoftware.c= om:/usr/obj/usr/src/sys/LIBERTAS amd64 --=20 Sterling (Chip) Camden | sterling@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com | http://chipsquips= .com --rz+pwK2yUstbofK6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJMxga4AAoJEIpckszW26+R46sH+weYwNQ4ep9TkH/0pMJKpmW5 UCnYtzZI6wcw/AIMMAnqB4/n5Xq20Hd5Cmi2wLjUeZfQENVVCYXNtuk5rITufgg9 E7yAkj78Xi9MK6YO75SWit+c7DhMNx99wkuIMjjlmYPJMLo5/I+1xPDTb3VBDM6a VEcsWyuw+AwvEGtdxwOVSQIyOjSbybNkFLal7uPK/GZ9OQ6vk7K1GF1L9sNWDjzg OEw3EvAulMS0HpRaDDAY3TjRYLd2r2PAYX4J1W97jvGzAgF+wuTRn2BWv/lrRnUb 5VlZUPeeKCP3Hh0K8iuM/CvnxFIZjIcbyM3jvERN4nOpzOOsQgRX7jfrtpRsSyg= =Kk5C -----END PGP SIGNATURE----- --rz+pwK2yUstbofK6-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 02:40:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10C92106564A for ; Tue, 26 Oct 2010 02:40:33 +0000 (UTC) (envelope-from darcsis@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B56098FC15 for ; Tue, 26 Oct 2010 02:40:32 +0000 (UTC) Received: by yxl31 with SMTP id 31so2671719yxl.13 for ; Mon, 25 Oct 2010 19:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:to:subject :in-reply-to:organization:references:user-agent:x-envelope-to :mail-followup-to:date:message-id:mime-version:content-type; bh=p38oK1lwlTmkKy2//jqw2IkSC9OeIAVit7mOvKOKsos=; b=dT/BVbK+z+ktZnKiiMzrDORXmLCd4+MhVDc7yS1fPpic9NhSIuo+J1qD78vBdJNgE3 HS/J+9FzDDSrrjnWYRgDna+8socDLbr72LE7on5IqO31f7UXaohgBjJyXvNSZ5012JCi rJ1FH2Wm6t76JjGiDpR3ZCrHOZZALHDGbeQa4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:in-reply-to:organization:references:user-agent :x-envelope-to:mail-followup-to:date:message-id:mime-version :content-type; b=fS+KBPrejl/db8+/4f1I8SEnktswKQQtErjdj4pq+CLG0t2IvCj2ppPvmqnoX0bY7U bFX5lVDXMs44CHHVFBZib0eJQv0x67bhP0+5p1zUueO9XrXJW8YsfGXzT/W9hqXGX2WB PFrA7H6x3TmzMcw9FdnFyFdsR6BwsgOY8kgsk= Received: by 10.150.140.18 with SMTP id n18mr14285935ybd.154.1288059255436; Mon, 25 Oct 2010 19:14:15 -0700 (PDT) Received: from smtp.xbsd.name ([123.117.61.173]) by mx.google.com with ESMTPS id v39sm3427721yba.19.2010.10.25.19.14.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Oct 2010 19:14:13 -0700 (PDT) Received: from pluton.xbsd.name (pluton.xbsd.name [172.16.1.10]) by smtp.xbsd.name (OpenSMTPD) with ESMTP id 1288059246.msuEEzbMrJk66Ljn (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128); Tue, 26 Oct 2010 10:14:06 +0800 (CST) From: darcsis@gmail.com (Denise H. G.) To: freebsd-stable@freebsd.org In-Reply-To: <20101025223744.GD2107@libertas.local.camdensoftware.com> (Chip Camden's message of "Mon, 25 Oct 2010 15:37:44 -0700") Organization: Pluto The Planet References: <20101025223744.GD2107@libertas.local.camdensoftware.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) X-Envelope-To: freebsd-stable@freebsd.org Mail-Followup-To: freebsd-stable@freebsd.org Date: Tue, 26 Oct 2010 10:14:04 +0800 Message-ID: <86bp6hhf9v.fsf@pluton.xbsd.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: stable GENERIC kernel build fails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 02:40:33 -0000 On 2010/10/26 at 06:37, Chip Camden wrote: > > After a csup, building the GENERIC kernel on amd64 fails with: Exactly the same here, but with a custom kernel on 8-STABLE amd64. > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" > CC="cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe > -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx > -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector > cc: /usr/src/sys/libkern/inet_ntop.c: No such file or directory > cc: /usr/src/sys/libkern/inet_pton.c: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > libertas/usr/src# uname -a > FreeBSD libertas.local.camdensoftware.com 8.1-STABLE FreeBSD 8.1-STABLE #81: Sun Oct 24 11:46:14 PDT 2010 sterling@libertas.local.camdensoftware.com:/usr/obj/usr/src/sys/LIBERTAS amd64 > > ................ -- You never know who's right, but you always know who's in charge. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 03:00:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A4FB1065674 for ; Tue, 26 Oct 2010 03:00:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9F28FC12 for ; Tue, 26 Oct 2010 03:00:43 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta04.emeryville.ca.mail.comcast.net with comcast id PDxz1f0030b6N64A4F0jGS; Tue, 26 Oct 2010 03:00:43 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta03.emeryville.ca.mail.comcast.net with comcast id PF0i1f00E3LrwQ28PF0iGT; Tue, 26 Oct 2010 03:00:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4ACDC9B422; Mon, 25 Oct 2010 20:00:42 -0700 (PDT) Date: Mon, 25 Oct 2010 20:00:42 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20101026030042.GA13775@icarus.home.lan> References: <20101025223744.GD2107@libertas.local.camdensoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101025223744.GD2107@libertas.local.camdensoftware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: attilio@freebsd.org Subject: Re: stable GENERIC kernel build fails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 03:00:44 -0000 On Mon, Oct 25, 2010 at 03:37:44PM -0700, Chip Camden wrote: > After a csup, building the GENERIC kernel on amd64 fails with: > > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" > CC="cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe > -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx > -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector > cc: /usr/src/sys/libkern/inet_ntop.c: No such file or directory > cc: /usr/src/sys/libkern/inet_pton.c: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > libertas/usr/src# uname -a > FreeBSD libertas.local.camdensoftware.com 8.1-STABLE FreeBSD 8.1-STABLE #81: Sun Oct 24 11:46:14 PDT 2010 sterling@libertas.local.camdensoftware.com:/usr/obj/usr/src/sys/LIBERTAS amd64 Looks like it was this commit. CC'ing committer. http://freshbsd.org/2010/10/25/13/34/55 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 08:35:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F5B01065672 for ; Tue, 26 Oct 2010 08:35:35 +0000 (UTC) (envelope-from ohartman@mail.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 3B8C18FC28 for ; Tue, 26 Oct 2010 08:35:31 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-stable@freebsd.org with esmtp (envelope-from ) id <1PAeff-00022U-CT>; Tue, 26 Oct 2010 10:14:15 +0200 Received: from e178024033.adsl.alicedsl.de ([85.178.24.33] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-stable@freebsd.org with esmtpsa (envelope-from ) id <1PAeff-0007EG-6l>; Tue, 26 Oct 2010 10:14:15 +0200 Message-ID: <4CC68DD7.1070000@mail.zedat.fu-berlin.de> Date: Tue, 26 Oct 2010 10:14:15 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101020 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20101025223744.GD2107@libertas.local.camdensoftware.com> <86bp6hhf9v.fsf@pluton.xbsd.name> In-Reply-To: <86bp6hhf9v.fsf@pluton.xbsd.name> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.24.33 Subject: Re: stable GENERIC kernel build fails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 08:35:35 -0000 On 10/26/10 04:14, Denise H. G. wrote: > > On 2010/10/26 at 06:37, Chip Camden wrote: >> >> After a csup, building the GENERIC kernel on amd64 fails with: > > Exactly the same here, but with a custom kernel on 8-STABLE amd64. > >> make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" >> CC="cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe >> -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign >> -fformat-extensions -nostdinc -I. -I/usr/src/sys >> -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter >> -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath >> -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm >> -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD >> -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs >> -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb >> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel >> -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx >> -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >> -fstack-protector >> cc: /usr/src/sys/libkern/inet_ntop.c: No such file or directory >> cc: /usr/src/sys/libkern/inet_pton.c: No such file or directory >> mkdep: compile failed >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/GENERIC. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> libertas/usr/src# uname -a >> FreeBSD libertas.local.camdensoftware.com 8.1-STABLE FreeBSD 8.1-STABLE #81: Sun Oct 24 11:46:14 PDT 2010 sterling@libertas.local.camdensoftware.com:/usr/obj/usr/src/sys/LIBERTAS amd64 >> >> ................ > > > same here with a custom kernel and subversion-updated /usr/src, bug still there as I tried to compile kernel just minutes ago ... Oliver From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 09:19:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C88D6106566B for ; Tue, 26 Oct 2010 09:19:16 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 78BD18FC1D for ; Tue, 26 Oct 2010 09:19:16 +0000 (UTC) Received: by qyk7 with SMTP id 7so2228598qyk.13 for ; Tue, 26 Oct 2010 02:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=1PJxNLKFvcv73louoXeWJrhuBtkOHh3EvjfPOH/wh+w=; b=Vheo+SBNR4dga4skhcTwjcnH+sv6k92QVjVZ9rvs8QinG9az2Dm3sMcj+UqP/mPvUp HESKOJDYdIHGe6cuyEV6ONcbPtlK1VTfJuLRqgqIwnY0p0as+l7KyBjONDfjD7HxX2/2 gS0EUMCQa5dYQGGyDTPPK/vskkiEMpYAXyU24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=OHIu2VehPf0gAteKyMOS3FPoyy6BISohFZyi+oX1FeqRuTPVBLvfZVekuxXSiB9Dn9 ndBXSyfLyBRoL1pSsKkHeHNJw3NJtpnKCJv5F/lbzV4cIKY81cTr2hfCa9Pt43eMzGmO bdNMxAFaZmCiOn3SiiM7tajTGciIfNbKn0uHQ= MIME-Version: 1.0 Received: by 10.229.94.137 with SMTP id z9mr7384804qcm.271.1288083045535; Tue, 26 Oct 2010 01:50:45 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.237.9 with HTTP; Tue, 26 Oct 2010 01:50:41 -0700 (PDT) In-Reply-To: <20101025223744.GD2107@libertas.local.camdensoftware.com> References: <20101025223744.GD2107@libertas.local.camdensoftware.com> Date: Tue, 26 Oct 2010 10:50:41 +0200 X-Google-Sender-Auth: 0jHbPAPsW4lQFQkaCO8iu7fpwII Message-ID: From: Attilio Rao To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: stable GENERIC kernel build fails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 09:19:16 -0000 Sorry for the mis-service, it should be fixed now. Thanks, Attilio 2010/10/26 Chip Camden : > After a csup, building the GENERIC kernel on amd64 fails with: > > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | =C2=A0MKDEP_CPP=3D"cc -E" > CC=3D"cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe > -fno-strict-aliasing =C2=A0-std=3Dc99 -g -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes =C2=A0-Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual =C2=A0-Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc =C2=A0-I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > large-function-growth=3D1000 =C2=A0-fno-omit-frame-pointer -mcmodel=3Dker= nel > -mno-red-zone =C2=A0-mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx > -mno-3dnow =C2=A0-msoft-float -fno-asynchronous-unwind-tables -ffreestand= ing > -fstack-protector > cc: /usr/src/sys/libkern/inet_ntop.c: No such file or directory > cc: /usr/src/sys/libkern/inet_pton.c: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > libertas/usr/src# uname -a > FreeBSD libertas.local.camdensoftware.com 8.1-STABLE FreeBSD 8.1-STABLE #= 81: Sun Oct 24 11:46:14 PDT 2010 =C2=A0 =C2=A0 sterling@libertas.local.camd= ensoftware.com:/usr/obj/usr/src/sys/LIBERTAS =C2=A0amd64 > > -- > Sterling (Chip) Camden =C2=A0 =C2=A0| sterling@camdensoftware.com | 2048D= /3A978E4F > http://camdensoftware.com | http://chipstips.com =C2=A0 =C2=A0 =C2=A0 =C2= =A0| http://chipsquips.com > --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 09:33:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D6A0106566B for ; Tue, 26 Oct 2010 09:33:27 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id DAB898FC15 for ; Tue, 26 Oct 2010 09:33:26 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id o9Q9XPS5079610 for ; Tue, 26 Oct 2010 11:33:25 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id o9Q9XPHd011419 for ; Tue, 26 Oct 2010 11:33:25 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id o9Q9XPXo011418 for freebsd-stable@freebsd.org; Tue, 26 Oct 2010 11:33:25 +0200 (CEST) (envelope-from ry93) Date: Tue, 26 Oct 2010 11:33:25 +0200 From: "Patrick M. Hausen" To: freebsd-stable@freebsd.org Message-ID: <20101026093325.GE7744@hugo10.ka.punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.17 (2007-11-01) Subject: ATA error messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 09:33:27 -0000 Hi, all, recently I set up a FreeNAS box: FreeBSD freenas.intern.punkt.de 7.3-RELEASE-p3 FreeBSD 7.3-RELEASE-p3 #0: Sun Oct 17 12:57:33 CEST 2010 root@dev.freenas.org:/usr/obj/freenas/usr/src/sys/FREENAS-amd64 amd64 This is a HP/Compaq Microserver (Proliant N36L). After setting up the system with 4 used 500 GB Seagate drives to find out if FreeNAS would fit our needs, I replaced the drives with WDC RE4 2 TB (WD2002FYPS) and put the system in production to store backups. Yesterday the file system perfomance suddenly came to a crawl and the system log fills with entries like this: ad8: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=3907027968 ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad8: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad8: WARNING - SET_MULTI taskqueue timeout - completing request directly ... Only one of the for drives shows these timeouts. My question: does this necessarily mean I have an isolated problem with that particular drive, since the other three are running just fine, or could there still be someting more fundamental going on? atapci0: port 0xd000-0xd007,0xc000-0xc003,0xb000-0xb007,0xa000-0xa003,0x9000-0x900f mem 0xfdfffc00-0xfdffffff irq 19 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.20 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ... ad4: 1907729MB at ata2-master SATA300 ad6: 1907729MB at ata3-master SATA300 ad8: 1907729MB at ata4-master SATA300 ad10: 1907729MB at ata5-master SATA300 Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 09:36:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA7C21065670 for ; Tue, 26 Oct 2010 09:36:05 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay03-haj2.antispameurope.com (relay03-haj2.antispameurope.com [83.246.65.53]) by mx1.freebsd.org (Postfix) with ESMTP id 66B418FC15 for ; Tue, 26 Oct 2010 09:36:04 +0000 (UTC) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 26DE97D43D2; Tue, 26 Oct 2010 11:24:48 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 5844C7D43D5; Tue, 26 Oct 2010 11:24:47 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o9Q9OlXk029532; Tue, 26 Oct 2010 11:24:47 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Oct 2010 11:24:47 +0200 Date: Tue, 26 Oct 2010 11:24:47 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: freebsd-stable@freebsd.org, jakub_lach@mailplus.pl Message-ID: <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Oct 2010 09:24:47.0975 (UTC) FILETIME=[A2561F70:01CB74EF] Cc: Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 09:36:05 -0000 You wrote: ># cdrecord(wodim) dev=1,0,0 -v -data *.iso >Track 01: 0 of 2858 MB written.Errno: 5 (Input/output error), write_g1 >scsi sendcmd: retryable error >CDB: 2A 00 00 00 00 00 00 00 1F 00 >status: 0x2 (CHECK CONDITION) >Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 00 00 00 >Sense Key: 0xFFFFFFFF [], Segment 0 >Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 >Sense flags: Blk 0 (not valid) >cmd finished after 22.883s timeout 40s >write track data: error after 0 bytes >wodim: A write error occured. >wodim: Please properly read the error message above. >Writing time: 32.681s >Average write speed 77.7x. wodim is a dead end from a 6 year old version of cdrecord with the DVD support ripped off and replaced by something broken. But there have been even more bugs added to wodim and it is not under "development" since May 2007. If cdrecord gives the same message, I encourage you to make a kernel bug report. This message is a hint to a serious kernel problem. A sense key value -1 cannot happen, so you need to find out why the SCSI command has not been transported correctly by the kernel. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 10:02:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210831065670 for ; Tue, 26 Oct 2010 10:02:24 +0000 (UTC) (envelope-from erik@tefre.com) Received: from mta1-filtered.netlife.no (mail.netlife.no [62.92.26.226]) by mx1.freebsd.org (Postfix) with ESMTP id CCED48FC18 for ; Tue, 26 Oct 2010 10:02:23 +0000 (UTC) Received: from amavis2.netlife.no (unknown [10.115.1.12]) by mta1-filtered.netlife.no (Postfix) with ESMTP id AE7632EA541; Tue, 26 Oct 2010 12:02:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at netlife.no Received: from mta1-submission.netlife.no ([62.92.26.226]) by amavis2.netlife.no (amavis2.netlife.no [10.115.1.12]) (amavisd-new, port 10026) with ESMTP id TdpgtwpJ1nPe; Tue, 26 Oct 2010 12:02:21 +0200 (CEST) Received: from baviandesktop.netlife.no (kontor.netlife.no [217.13.28.50]) (Authenticated sender: erik_pop@netlife.no) by mta1-submission.netlife.no (Postfix) with ESMTPA id 48F7B2EA53B; Tue, 26 Oct 2010 12:02:21 +0200 (CEST) Message-ID: <4CC6A72C.80406@tefre.com> Date: Tue, 26 Oct 2010 12:02:20 +0200 From: Erik Stian Tefre User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.12) Gecko/20100910 Thunderbird/3.0.7 MIME-Version: 1.0 To: Giulio Ferro References: <4CC18BB9.2030200@zirakzigil.org> In-Reply-To: <4CC18BB9.2030200@zirakzigil.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS wrong size stats with amavis X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 10:02:24 -0000 On 10/22/10 15:03, Giulio Ferro wrote: > I've seen people discuss about this and it happened to me as well. > > Freebsd 8.1 stable 25th september amd64 > This server has one single boot disk with ufs + 1 array (hardware, 3ware) > which hold 2,7TB data. I've formatted the latter with ZFS. > > Things seemed to work ok until I upgraded the system. One day the server > jails didn't boot anymore. I checked and the array occupation was 100% with > 0 byte free. > > This sounded strange, so I found a hidden file under > /var/amavis/.spamassassin. > I removed the dir, started again, but after a while it grew again until > the system became unusable. > > This is how I solved: I moved the amavis partition under UFS, then > mounted with nullfs that dir under /var in the zfs jail. > > I solved in the sense that it didn't grow anymore, but the fs occupation > stayed very near 100%, with only 1GB free space. > > If I launch du -s under /zfs (host machine, not jail) I get a total space > of about 750GB, but df -h always turns up with 2,7TB space occupied. > > I tried a zpool upgrade zfs and zpool scrub zfs, but to no avail. > > What should I do. short of moving the data, destroying the pool and > creating it again (which I can't very easily do)? I had the same problem with extremely large files in /var/amavis/.spamassassin after upgrading from 7.x to 8.1 (zpool mirror, no compression, zpool upgraded to v14, zfs filesystems upgraded to v3). This worked for me as a fix/workaround: zfs create pool/newamavisjail rm /pool/oldamavisjail/var/amavis/.spamassassin/[hugefiles] rsync ... /pool/oldamavisjail /pool/newamavisjail portsnap fetch update; portupgrade -af (in newamavisjail) restart newamavisjail I don't think I permanently lost disk space from the pool because of this. I guess you have checked that there are no snapshots referring to the huge files? (zfs list and zfs list -t snapshot) -- Erik From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 10:41:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 584A9106564A for ; Tue, 26 Oct 2010 10:41:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7058FC08 for ; Tue, 26 Oct 2010 10:41:41 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta05.emeryville.ca.mail.comcast.net with comcast id PNeM1f0010S2fkCA5NhhNN; Tue, 26 Oct 2010 10:41:41 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta09.emeryville.ca.mail.comcast.net with comcast id PNhg1f00C3LrwQ28VNhg7X; Tue, 26 Oct 2010 10:41:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 513B09B422; Tue, 26 Oct 2010 03:41:40 -0700 (PDT) Date: Tue, 26 Oct 2010 03:41:40 -0700 From: Jeremy Chadwick To: "Patrick M. Hausen" Message-ID: <20101026104140.GA32172@icarus.home.lan> References: <20101026093325.GE7744@hugo10.ka.punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101026093325.GE7744@hugo10.ka.punkt.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: ATA error messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 10:41:42 -0000 On Tue, Oct 26, 2010 at 11:33:25AM +0200, Patrick M. Hausen wrote: > recently I set up a FreeNAS box: > > FreeBSD freenas.intern.punkt.de 7.3-RELEASE-p3 FreeBSD 7.3-RELEASE-p3 #0: Sun Oct 17 12:57:33 CEST 2010 root@dev.freenas.org:/usr/obj/freenas/usr/src/sys/FREENAS-amd64 amd64 > > This is a HP/Compaq Microserver (Proliant N36L). After setting up > the system with 4 used 500 GB Seagate drives to find out if FreeNAS > would fit our needs, I replaced the drives with WDC RE4 2 TB > (WD2002FYPS) and put the system in production to store backups. > > Yesterday the file system perfomance suddenly came to a crawl > and the system log fills with entries like this: > > ad8: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=3907027968 > ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad8: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad8: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > ad8: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > ad8: WARNING - SET_MULTI taskqueue timeout - completing request directly > ... > > Only one of the for drives shows these timeouts. > > My question: does this necessarily mean I have an isolated problem > with that particular drive, since the other three are running just fine, > or could there still be someting more fundamental going on? It's impossible to tell at this stage. Please install ports/sysutils/smartmontools (version 5.40) and provide the output from "smartctl -a /dev/ad8". We'll start there. Also, you might be interested in using ahci.ko (not ataachi.ko) since your controller supports AHCI. You'd gain NCQ capability and be given some of the perks of using CAM. Your disks would be renamed from things like ad4 to ada0 and ad6 to ada1, however. Just FYI. This is unrelated to your problem though. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 10:41:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D084C1065783 for ; Tue, 26 Oct 2010 10:41:54 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 967568FC1B for ; Tue, 26 Oct 2010 10:41:54 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PAgyX-00037N-57 for freebsd-stable@freebsd.org; Tue, 26 Oct 2010 03:41:53 -0700 Message-ID: <30056250.post@talk.nabble.com> Date: Tue, 26 Oct 2010 03:41:53 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: jakub_lach@mailplus.pl References: <29978939.post@talk.nabble.com> <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 10:41:55 -0000 Joerg Schilling-3 wrote: >=20 > wodim is a dead end from a 6 year old version of cdrecord with the DVD > support=20 > ripped off and replaced by something broken. But there have been even mor= e > bugs=20 > added to wodim and it is not under "development" since May 2007. >=20 > If cdrecord gives the same message, I encourage you to make a kernel bug > report. > This message is a hint to a serious kernel problem. A sense key value -1 > cannot > happen, so you need to find out why the SCSI command has not been > transported=20 > correctly by the kernel. >=20 Hi J=C3=B6rg. I usually prefer cdrtools, wodim was convenient way to try old code. After booting GENERIC kernel + ahci driver and compiling cdrtools release problem is still present. Full message. cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd8.1) Copyright (C) 1995-2010 J=C3=B6rg Schilling TOC Type: 1 =3D CD-ROM scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 Using libscg version 'schily-0.9'. SCSI buffer size: 65536 atapi: 0 Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities :=20 Vendor_info : 'HL-DT-ST' Identifikation : 'DVDRAM GSA-U20N ' Revision : 'HX11' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: DVD-R sequential recording Profile: DVD-RAM=20 Profile: DVD-R sequential recording (current) Profile: DVD-R/DL sequential recording=20 Profile: DVD-R/DL layer jump recording=20 Profile: DVD-RW sequential recording=20 Profile: DVD-RW restricted overwrite=20 Profile: DVD+RW=20 Profile: DVD+R=20 Profile: DVD+R/DL=20 Profile: DVD-ROM=20 Profile: CD-R=20 Profile: CD-RW=20 Profile: CD-ROM=20 Profile: Removable Disk=20 Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd). Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE=20 Supported modes: PACKET SAO LAYER_JUMP Drive buf size : 1114112 =3D 1088 KB Drive pbuf size: 1966080 =3D 1920 KB Drive DMA Speed: 15100 kB/s 85x CD 10x DVD 3x BD FIFO size : 4194304 =3D 4096 KB Track 01: data 2858 MB =20 Total size: 2858 MB =3D 1463428 sectors Current Secsize: 2048 Total power on hours: 0 Blocks total: 2298496 Blocks current: 2298496 Blocks remaining: 835068 Starting to write CD/DVD/BD at speed 8 in real SAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. BURN-Free is ON. Turning BURN-Free off Starting new track at sector: 0 Track 01: 0 of 2858 MB written.cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error CDB: 2A 00 00 00 00 00 00 00 20 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid)=20 cmd finished after 23.946s timeout 200s write track data: error after 0 bytes cdrecord: A write error occured. cdrecord: Please properly read the error message above. Writing time: 29.002s Average write speed 74.7x. Fixating... Fixating time: 22.355s cdrecord: fifo had 64 puts and 1 gets. cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%. I destroyed all my spare media, so I'm also spared from burning problems for now ;) I'm quite puzzled that only I have reported such problems,=20 it's like I'm on CURRENT again.. best regards,=20 - Jakub Lach --=20 View this message in context: http://old.nabble.com/cdrtools--devel-and-wod= im-broken-tp29978939p30056250.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 11:00:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69389106566B for ; Tue, 26 Oct 2010 11:00:21 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id EEA578FC18 for ; Tue, 26 Oct 2010 11:00:20 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id o9QB0JAE081011; Tue, 26 Oct 2010 13:00:19 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id o9QB0JhA014722; Tue, 26 Oct 2010 13:00:19 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id o9QB0JXu014721; Tue, 26 Oct 2010 13:00:19 +0200 (CEST) (envelope-from ry93) Date: Tue, 26 Oct 2010 13:00:19 +0200 From: "Patrick M. Hausen" To: Jeremy Chadwick Message-ID: <20101026110019.GA14069@hugo10.ka.punkt.de> References: <20101026093325.GE7744@hugo10.ka.punkt.de> <20101026104140.GA32172@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101026104140.GA32172@icarus.home.lan> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: ATA error messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 11:00:21 -0000 Hello, On Tue, Oct 26, 2010 at 03:41:40AM -0700, Jeremy Chadwick wrote: > Please install ports/sysutils/smartmontools (version 5.40) and provide > the output from "smartctl -a /dev/ad8". We'll start there. Thanks for the hints, but it looks like the drive just died ... Case closed, I think. Time to apply for an RMA/warranty form. > Also, you might be interested in using ahci.ko (not ataachi.ko) since > your controller supports AHCI. You'd gain NCQ capability and be given > some of the perks of using CAM. Your disks would be renamed from things > like ad4 to ada0 and ad6 to ada1, however. Just FYI. This is unrelated > to your problem though. I'll give that a try once I find out how to do that in FreeNAS. I know about the renaming - no problem. The system is running from flash and the hard disks contain one raidz2 pool. Best regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 12:29:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 340B9106566B for ; Tue, 26 Oct 2010 12:29:34 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id BC0A68FC1B for ; Tue, 26 Oct 2010 12:29:33 +0000 (UTC) Received: by wwb24 with SMTP id 24so4477274wwb.31 for ; Tue, 26 Oct 2010 05:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cFLFG/Nzp8NlBzGOFMx1/gROoZq54cZ1W835g2vxCGM=; b=QKK5jAgWotYzv6GPfYWMOdlURbwdS5ZEPOTA/gzxr3I4GeqJ3CgqNUOSjCIdpXnIO0 EpjjQsKtVcswCA1a88l2tmK5GWHgQN5m7BwTyfQkw7BkshuXfGnjyx+kfJGUDZSPjWmi NNWchKGBR9K4pYMnfdc6NsOCCxMvPJOOb8PEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qDFXA/Vabq0BNsW+Pi03qk3zgkWntPJNbYqIMd7DW8vmjYVS14lTMuhzX22dGQwddB 51aGrcJd4plhTlSurlOW3eSjd5OXI7dVIuKFLTUJAtUfUBecrkPAMFnb6eHKVFEgHGbv 8ZdRl7uWBrNhqRxqeX7lURIspwDLtyRWfq0O0= MIME-Version: 1.0 Received: by 10.227.134.206 with SMTP id k14mr3299323wbt.160.1288094475278; Tue, 26 Oct 2010 05:01:15 -0700 (PDT) Received: by 10.216.50.140 with HTTP; Tue, 26 Oct 2010 05:01:14 -0700 (PDT) In-Reply-To: <30056250.post@talk.nabble.com> References: <29978939.post@talk.nabble.com> <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> <30056250.post@talk.nabble.com> Date: Tue, 26 Oct 2010 12:01:14 +0000 Message-ID: From: Paul B Mahol To: Jakub Lach Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 12:29:34 -0000 On 10/26/10, Jakub Lach wrote: > > > Joerg Schilling-3 wrote: >> >> wodim is a dead end from a 6 year old version of cdrecord with the DVD >> support >> ripped off and replaced by something broken. But there have been even more >> bugs >> added to wodim and it is not under "development" since May 2007. >> >> If cdrecord gives the same message, I encourage you to make a kernel bug >> report. >> This message is a hint to a serious kernel problem. A sense key value -1 >> cannot >> happen, so you need to find out why the SCSI command has not been >> transported >> correctly by the kernel. >> > > Hi Joerg. > > I usually prefer cdrtools, wodim was convenient way to > try old code. > > After booting GENERIC kernel + ahci driver and compiling > cdrtools release problem is still present. > > Full message. > > cdrecord: No write mode specified. > cdrecord: Assuming -sao mode. > cdrecord: If your drive does not accept -sao, try -tao. > cdrecord: Future versions of cdrecord may have different drive dependent > defaults. > Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd8.1) Copyright (C) > 1995-2010 Joerg Schilling > TOC Type: 1 = CD-ROM > scsidev: '1,0,0' > scsibus: 1 target: 0 lun: 0 > Using libscg version 'schily-0.9'. > SCSI buffer size: 65536 > atapi: 0 > Device type : Removable CD-ROM > Version : 0 > Response Format: 2 > Capabilities : > Vendor_info : 'HL-DT-ST' > Identifikation : 'DVDRAM GSA-U20N ' > Revision : 'HX11' > Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. > Current: DVD-R sequential recording > Profile: DVD-RAM > Profile: DVD-R sequential recording (current) > Profile: DVD-R/DL sequential recording > Profile: DVD-R/DL layer jump recording > Profile: DVD-RW sequential recording > Profile: DVD-RW restricted overwrite > Profile: DVD+RW > Profile: DVD+R > Profile: DVD+R/DL > Profile: DVD-ROM > Profile: CD-R > Profile: CD-RW > Profile: CD-ROM > Profile: Removable Disk > Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd). > Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE > Supported modes: PACKET SAO LAYER_JUMP > Drive buf size : 1114112 = 1088 KB > Drive pbuf size: 1966080 = 1920 KB > Drive DMA Speed: 15100 kB/s 85x CD 10x DVD 3x BD > FIFO size : 4194304 = 4096 KB > Track 01: data 2858 MB > Total size: 2858 MB = 1463428 sectors > Current Secsize: 2048 > Total power on hours: 0 > Blocks total: 2298496 Blocks current: 2298496 Blocks remaining: 835068 > Starting to write CD/DVD/BD at speed 8 in real SAO mode for single session. > Last chance to quit, starting real write 0 seconds. Operation starts. > Waiting for reader process to fill input buffer ... input buffer ready. > BURN-Free is ON. > Turning BURN-Free off > Starting new track at sector: 0 > Track 01: 0 of 2858 MB written.cdrecord: Input/output error. write_g1: > scsi sendcmd: retryable error > CDB: 2A 00 00 00 00 00 00 00 20 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 > Sense Key: 0xFFFFFFFF [], Segment 0 > Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 > Sense flags: Blk 0 (not valid) > cmd finished after 23.946s timeout 200s > > write track data: error after 0 bytes > cdrecord: A write error occured. > cdrecord: Please properly read the error message above. > Writing time: 29.002s > Average write speed 74.7x. > Fixating... > Fixating time: 22.355s > cdrecord: fifo had 64 puts and 1 gets. > cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%. > > I destroyed all my spare media, so I'm also spared from burning problems > for now ;) And what kind of spare media was that? > I'm quite puzzled that only I have reported such problems, > it's like I'm on CURRENT again.. I burned bunch of DVD-R, DVD+R and DVD+R DL on FreeBSD 9.0 without any problems, using growisofs from ports. Only problem I ever had was mounting multi-sesion after 4GB (but -r flag is nice workaround). From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 13:08:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 935711065740 for ; Tue, 26 Oct 2010 13:08:18 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD8A8FC0C for ; Tue, 26 Oct 2010 13:08:18 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PAjG9-0004qE-Qm for freebsd-stable@freebsd.org; Tue, 26 Oct 2010 15:08:13 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Oct 2010 15:08:13 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Oct 2010 15:08:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 26 Oct 2010 15:08:06 +0200 Lines: 11 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20101018 Thunderbird/3.0.8 X-Enigmail-Version: 1.0.1 Subject: rpcbind, rpc.statd memory footprint X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 13:08:18 -0000 I'm not sure what to expect from these (i.e. what is "normal" in this case?) but the VM sizes for the NFS-used rpc.statd and rpcbind here look a bit too big, compared to their resident sizes: 778 root 1 44 0 26420K 3256K select 1 0:01 0.00% rpcbind 891 root 1 44 0 263M 1296K select 1 0:01 0.00% rpc.statd This is 8-stable amd64. Could there be a memory leak somewhere, especially in rpc.statd? From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 13:25:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5860106566C for ; Tue, 26 Oct 2010 13:25:36 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF208FC16 for ; Tue, 26 Oct 2010 13:25:36 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:24969 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1PAjVM-00052E-7v for freebsd-stable@freebsd.org; Tue, 26 Oct 2010 15:23:58 +0200 Received: (qmail 55704 invoked from network); 26 Oct 2010 15:23:54 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 26 Oct 2010 15:23:54 +0200 Received: (qmail 79216 invoked by uid 1001); 26 Oct 2010 15:23:54 +0200 Date: Tue, 26 Oct 2010 15:23:54 +0200 From: Erik Trulsson To: Ivan Voras Message-ID: <20101026132354.GA79188@owl.midgard.homeip.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1PAjVM-00052E-7v. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1PAjVM-00052E-7v d86297ee7f559b273fca28ba82ed7711 Cc: freebsd-stable@freebsd.org Subject: Re: rpcbind, rpc.statd memory footprint X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 13:25:37 -0000 On Tue, Oct 26, 2010 at 03:08:06PM +0200, Ivan Voras wrote: > I'm not sure what to expect from these (i.e. what is "normal" in this > case?) but the VM sizes for the NFS-used rpc.statd and rpcbind here look > a bit too big, compared to their resident sizes: > > 778 root 1 44 0 26420K 3256K select 1 0:01 0.00% > rpcbind > 891 root 1 44 0 263M 1296K select 1 0:01 0.00% > rpc.statd > > This is 8-stable amd64. Could there be a memory leak somewhere, > especially in rpc.statd? FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#STATD-MEM-LEAK (Short version: That is expected behaviour from rpc.statd) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 14:00:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56E68106564A for ; Tue, 26 Oct 2010 14:00:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id EA49D8FC12 for ; Tue, 26 Oct 2010 14:00:01 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id PNZW1f0081ap0As51S018C; Tue, 26 Oct 2010 14:00:01 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta22.westchester.pa.mail.comcast.net with comcast id PS001f00F3LrwQ23iS01XZ; Tue, 26 Oct 2010 14:00:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 699199B422; Tue, 26 Oct 2010 06:59:59 -0700 (PDT) Date: Tue, 26 Oct 2010 06:59:59 -0700 From: Jeremy Chadwick To: Erik Trulsson Message-ID: <20101026135959.GA35363@icarus.home.lan> References: <20101026132354.GA79188@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101026132354.GA79188@owl.midgard.homeip.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: rpcbind, rpc.statd memory footprint X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:00:02 -0000 On Tue, Oct 26, 2010 at 03:23:54PM +0200, Erik Trulsson wrote: > On Tue, Oct 26, 2010 at 03:08:06PM +0200, Ivan Voras wrote: > > I'm not sure what to expect from these (i.e. what is "normal" in this > > case?) but the VM sizes for the NFS-used rpc.statd and rpcbind here look > > a bit too big, compared to their resident sizes: > > > > 778 root 1 44 0 26420K 3256K select 1 0:01 0.00% > > rpcbind > > 891 root 1 44 0 263M 1296K select 1 0:01 0.00% > > rpc.statd > > > > This is 8-stable amd64. Could there be a memory leak somewhere, > > especially in rpc.statd? > > FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#STATD-MEM-LEAK > > (Short version: That is expected behaviour from rpc.statd) Plus, that's 263MB of SIZE/VSZ, not RES/RSS. A portion of it could also be utilised by ELF shared object stuff (dynamic linking): $ ldd /usr/sbin/rpc.statd /usr/sbin/rpc.statd: librpcsvc.so.5 => /usr/lib/librpcsvc.so.5 (0x60648000) libc.so.7 => /lib/libc.so.7 (0x60750000) Bottom line: don't worry "too" much about VSZ when it comes to memory usage. Bloated RSS is reason to worry. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 14:50:52 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7EFE1065670; Tue, 26 Oct 2010 14:50:52 +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 82C6A8FC18; Tue, 26 Oct 2010 14:50:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o9QEopCf033405; Tue, 26 Oct 2010 10:50:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9QEopVI033401; Tue, 26 Oct 2010 14:50:51 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Oct 2010 14:50:51 GMT Message-Id: <201010261450.o9QEopVI033401@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 , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:50:52 -0000 TB --- 2010-10-26 06:20:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-26 06:20:40 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-10-26 06:20:40 - cleaning the object tree TB --- 2010-10-26 06:23:51 - cvsupping the source tree TB --- 2010-10-26 06:23:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-10-26 06:28:44 - building world TB --- 2010-10-26 06:28:44 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-26 06:28:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-26 06:28:44 - TARGET=amd64 TB --- 2010-10-26 06:28:44 - TARGET_ARCH=amd64 TB --- 2010-10-26 06:28:44 - TZ=UTC TB --- 2010-10-26 06:28:44 - __MAKE_CONF=/dev/null TB --- 2010-10-26 06:28:44 - cd /src TB --- 2010-10-26 06:28:44 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 26 06:28:46 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Oct 26 14:25:11 UTC 2010 TB --- 2010-10-26 14:25:11 - generating LINT kernel config TB --- 2010-10-26 14:25:11 - cd /src/sys/amd64/conf TB --- 2010-10-26 14:25:11 - /usr/bin/make -B LINT TB --- 2010-10-26 14:25:12 - building LINT kernel TB --- 2010-10-26 14:25:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-26 14:25:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-26 14:25:12 - TARGET=amd64 TB --- 2010-10-26 14:25:12 - TARGET_ARCH=amd64 TB --- 2010-10-26 14:25:12 - TZ=UTC TB --- 2010-10-26 14:25:12 - __MAKE_CONF=/dev/null TB --- 2010-10-26 14:25:12 - cd /src TB --- 2010-10-26 14:25:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 26 14:25:12 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpi_support/acpi_wmi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-ss! e3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector cc: /src/sys/libkern/inet_ntop.c: No such file or directory cc: /src/sys/libkern/inet_pton.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-26 14:50:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-26 14:50:51 - ERROR: failed to build lint kernel TB --- 2010-10-26 14:50:51 - 4255.74 user 16233.66 system 30610.94 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 15:21:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C967106564A for ; Tue, 26 Oct 2010 15:21:34 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 5611E8FC08 for ; Tue, 26 Oct 2010 15:21:34 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PAlLB-0002y2-PZ for freebsd-stable@freebsd.org; Tue, 26 Oct 2010 08:21:33 -0700 Message-ID: <30058682.post@talk.nabble.com> Date: Tue, 26 Oct 2010 08:21:33 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <29978939.post@talk.nabble.com> <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> <30056250.post@talk.nabble.com> Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 15:21:34 -0000 Paul B Mahol wrote: > > And what kind of spare media was that? > DVD-R, to be honest I didn't have this kind of problems on 8-CURRENT :). regards, - Jakub Lach -- View this message in context: http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30058682.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 15:29:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DE89106564A for ; Tue, 26 Oct 2010 15:29:59 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id AE56F8FC17 for ; Tue, 26 Oct 2010 15:29:58 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PAlTI-000Dn3-Mp; Tue, 26 Oct 2010 16:29:56 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAlTI-000Gtb-Lz; Tue, 26 Oct 2010 16:29:56 +0100 Date: Tue, 26 Oct 2010 16:29:56 +0100 Message-Id: To: freebsd-stable@freebsd.org, to.my.trociny@gmail.com From: Pete French Cc: Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 15:29:59 -0000 > You can check if the queue size is an issue monitoring with netstat Recv-Q and > Send-Q for hastd connections during the test. Running something like below: > > while sleep 1; do netstat -na |grep '\.8457.*ESTAB'; done Interesting - I ran those and started a complete resilvert (I do this by changing the secindary to 'init', running 'create' and then changing the role back to secondary) On primary I get... tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 29872 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 115 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 80928 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 32883 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 115 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10062 10.17.18.2.8457 ESTABLISHED tcp4 0 0 10.17.18.1.10061 10.17.18.2.8457 ESTABLISHED And on the secondary.... tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 105544 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 8688 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 84360 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 102648 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 17376 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 64088 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 34216 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED tcp4 0 0 10.17.18.2.8457 10.17.18.1.10061 ESTABLISHED tcp4 0 27 10.17.18.2.8457 10.17.18.1.10062 ESTABLISHED Thats just an example - I see the same kind of behaviour throughout the sychronisation process. I cant comopare it to gmirror+ggated, but it looks far more bursty than I would expect. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 15:42:11 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3998F1065693; Tue, 26 Oct 2010 15:42:11 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE05D8FC19; Tue, 26 Oct 2010 15:42:10 +0000 (UTC) Received: by qwe4 with SMTP id 4so2692396qwe.13 for ; Tue, 26 Oct 2010 08:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=pKFTlfcSqMNBbgwmiN0W/m2XNZmqozgHa4FK1buc1KI=; b=ZGEHZcFmoaIBGnJLKQ0E60ut9El4vmjqEhgKbhJgruIXttj1nLW8Hyy9MLoYgWsI8b P+Ah+ebXgxzSvQjgNi8EMwYef3lwkQWn+cLn5yZzgUu08Hy7+OR39Oa8xrE2Pkl7psSI TJo2Ub3QNKZwWtlmm+r7VirB0iTjMCuJjZtj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gdcCC29KTcuL9UtyRrPh9Vr16hjDPwnTMOLW+b+k0H48Revdi8HMOtwkXPAo32NT1r 8gHpb7t/UIKWVZscPQ4WLStYZAAtocrOsVokGe8+RbWvgR2eTDBLNzFiA2QaoROSVbyN plvsP1AHh8rxHhqpHVjLI++JXYm1Ilwcsp0b0= MIME-Version: 1.0 Received: by 10.229.241.196 with SMTP id lf4mr177945qcb.55.1288106277911; Tue, 26 Oct 2010 08:17:57 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.237.9 with HTTP; Tue, 26 Oct 2010 08:17:55 -0700 (PDT) In-Reply-To: <201010261450.o9QEopVI033401@freebsd-current.sentex.ca> References: <201010261450.o9QEopVI033401@freebsd-current.sentex.ca> Date: Tue, 26 Oct 2010 17:17:55 +0200 X-Google-Sender-Auth: WNQNBp3NhcucpMp2HfGaTm_EJxs Message-ID: From: Attilio Rao To: FreeBSD Tinderbox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, stable@freebsd.org Subject: Re: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 15:42:11 -0000 This issue should be resolved by r214370 already; someone else can validate this? Thanks, Attilio 2010/10/26 FreeBSD Tinderbox : > TB --- 2010-10-26 06:20:40 - tinderbox 2.6 running on freebsd-current.sen= tex.ca > TB --- 2010-10-26 06:20:40 - starting RELENG_8 tinderbox run for amd64/am= d64 > TB --- 2010-10-26 06:20:40 - cleaning the object tree > TB --- 2010-10-26 06:23:51 - cvsupping the source tree > TB --- 2010-10-26 06:23:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/RELENG_8/amd64/amd64/supfile > TB --- 2010-10-26 06:28:44 - building world > TB --- 2010-10-26 06:28:44 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2010-10-26 06:28:44 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-10-26 06:28:44 - TARGET=3Damd64 > TB --- 2010-10-26 06:28:44 - TARGET_ARCH=3Damd64 > TB --- 2010-10-26 06:28:44 - TZ=3DUTC > TB --- 2010-10-26 06:28:44 - __MAKE_CONF=3D/dev/null > TB --- 2010-10-26 06:28:44 - cd /src > TB --- 2010-10-26 06:28:44 - /usr/bin/make -B buildworld >>>> World build started on Tue Oct 26 06:28:46 UTC 2010 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> stage 5.1: building 32 bit shim libraries >>>> World build completed on Tue Oct 26 14:25:11 UTC 2010 > TB --- 2010-10-26 14:25:11 - generating LINT kernel config > TB --- 2010-10-26 14:25:11 - cd /src/sys/amd64/conf > TB --- 2010-10-26 14:25:11 - /usr/bin/make -B LINT > TB --- 2010-10-26 14:25:12 - building LINT kernel > TB --- 2010-10-26 14:25:12 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2010-10-26 14:25:12 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-10-26 14:25:12 - TARGET=3Damd64 > TB --- 2010-10-26 14:25:12 - TARGET_ARCH=3Damd64 > TB --- 2010-10-26 14:25:12 - TZ=3DUTC > TB --- 2010-10-26 14:25:12 - __MAKE_CONF=3D/dev/null > TB --- 2010-10-26 14:25:12 - cd /src > TB --- 2010-10-26 14:25:12 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Tue Oct 26 14:25:12 UTC 2010 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies > [...] > awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -= h > awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h > awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpi_support/acpi_wmi_i= f.m -h > rm -f .newdep > /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | =C2=A0MKDEP_CPP= =3D"cc -E" CC=3D"cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe= -fno-strict-aliasing =C2=A0-std=3Dc99 =C2=A0-Wall -Wredundant-decls -Wnest= ed-externs -Wstrict-prototypes =C2=A0-Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual =C2=A0-Wundef -Wno-pointer-sign -fformat-extensions -no= stdinc =C2=A0-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfi= lter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I= /src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/= src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib= /opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEAD= ERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-= unit-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-func= tions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel= =3Dkernel -mno-red-zone =C2=A0-mfpmath=3D387 -mno-sse -mno-sse2 -mno-ss! > =C2=A0e3 -mno-mmx -mno-3dnow =C2=A0-msoft-float -fno-asynchronous-unwind-= tables -ffreestanding -fstack-protector > cc: /src/sys/libkern/inet_ntop.c: No such file or directory > cc: /src/sys/libkern/inet_pton.c: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /obj/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2010-10-26 14:50:51 - WARNING: /usr/bin/make returned exit code = =C2=A01 > TB --- 2010-10-26 14:50:51 - ERROR: failed to build lint kernel > TB --- 2010-10-26 14:50:51 - 4255.74 user 16233.66 system 30610.94 real > > > http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 16:01:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DED9D1065670 for ; Tue, 26 Oct 2010 16:01:04 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 642FD8FC1D for ; Tue, 26 Oct 2010 16:01:04 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PAlxN-000E2G-FX; Tue, 26 Oct 2010 17:01:01 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAlxN-000H5x-Eh; Tue, 26 Oct 2010 17:01:01 +0100 Date: Tue, 26 Oct 2010 17:01:01 +0100 Message-Id: To: freebsd-stable@freebsd.org, petefrench@ticketswitch.com, to.my.trociny@gmail.com In-Reply-To: From: Pete French Cc: Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 16:01:04 -0000 Actually, I just llooked I dmesg on the secondary - it is full of messages thus: Oct 26 15:44:59 serpentine-passive hastd[10394]: [serp0] (secondary) Unable to receive request header: RPC version wrong. Oct 26 15:45:00 serpentine-passive hastd[782]: [serp0] (secondary) Worker process exited ungracefully (pid=10394, exitcode=75). Oct 26 15:46:59 serpentine-passive hastd[10421]: [serp0] (secondary) Unable to receive request header: RPC version wrong. Oct 26 15:47:04 serpentine-passive hastd[782]: [serp0] (secondary) Worker process exited ungracefully (pid=10421, exitcode=75). Does that help explain my issues ? I have the same OS build running on both machines, so I dont see how I can have a version mismatch. The ethernet here cnsists of a pair of bge devices, which are bundled using LACP and lagg. I didnt see this on my test setup, but that was using ethernet directly - could there be a difference there ? -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 16:02:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAFAE1065670 for ; Tue, 26 Oct 2010 16:02:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id AAE978FC0C for ; Tue, 26 Oct 2010 16:02:12 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id PPoE1f0041YDfWL58U2Cxo; Tue, 26 Oct 2010 16:02:12 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta20.westchester.pa.mail.comcast.net with comcast id PU2B1f0083LrwQ23gU2CxD; Tue, 26 Oct 2010 16:02:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D7B419B422; Tue, 26 Oct 2010 09:02:09 -0700 (PDT) Date: Tue, 26 Oct 2010 09:02:09 -0700 From: Jeremy Chadwick To: Attilio Rao Message-ID: <20101026160209.GA38237@icarus.home.lan> References: <201010261450.o9QEopVI033401@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: amd64@freebsd.org, stable@freebsd.org, FreeBSD Tinderbox Subject: Re: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 16:02:13 -0000 On Tue, Oct 26, 2010 at 05:17:55PM +0200, Attilio Rao wrote: > This issue should be resolved by r214370 already; someone else can > validate this? I'll start a clean buildworld on my box. Should be done in about 10-15 minutes. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 16:35:39 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2516F1065673 for ; Tue, 26 Oct 2010 16:35:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id C420A8FC1A for ; Tue, 26 Oct 2010 16:35:38 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta07.westchester.pa.mail.comcast.net with comcast id PQTs1f0030EZKEL57UbemJ; Tue, 26 Oct 2010 16:35:38 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.westchester.pa.mail.comcast.net with comcast id PUbb1f0023LrwQ23MUbd04; Tue, 26 Oct 2010 16:35:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A67399B422; Tue, 26 Oct 2010 09:35:33 -0700 (PDT) Date: Tue, 26 Oct 2010 09:35:33 -0700 From: Jeremy Chadwick To: Attilio Rao Message-ID: <20101026163533.GA63115@icarus.home.lan> References: <201010261450.o9QEopVI033401@freebsd-current.sentex.ca> <20101026160209.GA38237@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101026160209.GA38237@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: amd64@freebsd.org, stable@freebsd.org, FreeBSD Tinderbox Subject: Re: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 16:35:39 -0000 On Tue, Oct 26, 2010 at 09:02:09AM -0700, Jeremy Chadwick wrote: > On Tue, Oct 26, 2010 at 05:17:55PM +0200, Attilio Rao wrote: > > This issue should be resolved by r214370 already; someone else can > > validate this? > > I'll start a clean buildworld on my box. Should be done in about 10-15 > minutes. -------------------------------------------------------------- >>> World build completed on Tue Oct 26 09:20:33 PDT 2010 -------------------------------------------------------------- -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 18:17:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C55E106566C for ; Tue, 26 Oct 2010 18:17:17 +0000 (UTC) (envelope-from sterling@camdensoftware.com) Received: from wh2.interactivevillages.com (wh2.interactivevillages.com [75.125.250.34]) by mx1.freebsd.org (Postfix) with ESMTP id C63898FC1B for ; Tue, 26 Oct 2010 18:17:16 +0000 (UTC) Received: from 174-21-107-164.tukw.qwest.net ([174.21.107.164] helo=_HOSTNAME_) by wh2.interactivevillages.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PAnx1-0002kV-SY for freebsd-stable@freebsd.org; Tue, 26 Oct 2010 11:08:49 -0700 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Tue, 26 Oct 2010 11:17:10 -0700 Date: Tue, 26 Oct 2010 11:17:10 -0700 From: Chip Camden To: freebsd-stable@freebsd.org Message-ID: <20101026181710.GA1924@libertas.local.camdensoftware.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <20101025223744.GD2107@libertas.local.camdensoftware.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Company: Camden Software Consulting URL: http://camdensoftware.com X-PGP-Key: http://pgp.mit.edu:11371/pks/lookup?search=0xD6DBAF91 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh2.interactivevillages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - camdensoftware.com Subject: Re: stable GENERIC kernel build fails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 18:17:17 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoth Attilio Rao on Tuesday, 26 October 2010: > Sorry for the mis-service, it should be fixed now. >=20 > Thanks, > Attilio >=20 > 2010/10/26 Chip Camden : > > After a csup, building the GENERIC kernel on amd64 fails with: > > > > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | =A0MKDEP_CPP=3D"cc -E" > > CC=3D"cc" xargs mkdep -a -f .newdep -O2 -frename-registers -pipe > > -fno-strict-aliasing =A0-std=3Dc99 -g -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes > > -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign > > -fformat-extensions -nostdinc =A0-I. -I/usr/src/sys > > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > > -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD > > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > > -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb > > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > > large-function-growth=3D1000 =A0-fno-omit-frame-pointer -mcmodel=3Dkern= el > > -mno-red-zone =A0-mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx > > -mno-3dnow =A0-msoft-float -fno-asynchronous-unwind-tables -ffreestandi= ng > > -fstack-protector > > cc: /usr/src/sys/libkern/inet_ntop.c: No such file or directory > > cc: /usr/src/sys/libkern/inet_pton.c: No such file or directory > > mkdep: compile failed > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/GENERIC. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > libertas/usr/src# uname -a > > FreeBSD libertas.local.camdensoftware.com 8.1-STABLE FreeBSD 8.1-STABLE= #81: Sun Oct 24 11:46:14 PDT 2010 =A0 =A0 sterling@libertas.local.camdenso= ftware.com:/usr/obj/usr/src/sys/LIBERTAS =A0amd64 > > Thanks, that fixed it. --=20 Sterling (Chip) Camden | sterling@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com | http://chipsquips= .com --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJMxxsmAAoJEIpckszW26+RMrcH/juWSEepWl66OAJwlQEdsXHY 5fyyUzUu8YRo0yagMUjN2q8RN1UCFMZ6iAEUAoioxQksedceZxRIrudmAw8rdex1 DwIYM8sB5+G/MH1sa04ag1YcckHsfD8NKY1KA9iGNUIhE30Vh0cc+Fr/qpY+7F8V uL3dwAupw+/MLHDhydiS7456J0wMaWdNMAmpdj9qSDeTDDF1Mde/IhUIA57bZbWd ePn7wqb+c6Hy1Wqj1gi5y9Ex3mbZeuK7IR9oIZPcSBBBiN18QPZcG6zb6JI3nCFr Q7djq1yN2ByaDk+ed0uD7hhVBa86hbSX8Ihjr/ZYEs1/x5cXK/fReF+d0f7b6JA= =2Vy6 -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 19:49:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D33F2106566B for ; Tue, 26 Oct 2010 19:49:24 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2A58FC08 for ; Tue, 26 Oct 2010 19:49:24 +0000 (UTC) Received: by iwn39 with SMTP id 39so6169668iwn.13 for ; Tue, 26 Oct 2010 12:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:cc:content-type; bh=TTQwW/05dC98KW7kSSnL1UN6xiaA2+07/6yv8nXh9+w=; b=MMhOV/5tiPj6UlN2YCfez+Q8rNGT1zvZNUKcmb7DBO9sTcXQ+JOuWcgSs9U7s76ZXw 7KLZ5Ihblf+oK///vGgAsFjJIkguhb8LiapkcwSZcw6K3KmC5QvrTwbCD3lcU2ctGLs1 DWTXYP3f7sUR7ShKYBW1F2th1mXSlZmQWLUCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; b=iJhOVYhfsjmyZZrNbcKY7tywpvYVADtwFQ6G+jIb3b3BRcU0LbtJbZAg6b7i6j08Pe lwG7oND4Y3v8H7FSlsKyiZ7uv67KzF7ayxrPpDtIoLw2W/PigYzYfp1Z3lECibrpltD8 kcUR24nHt7q/s3ITJImJsAL3Pp4IjDK8SJITg= MIME-Version: 1.0 Received: by 10.231.36.7 with SMTP id r7mr4374199ibd.79.1288121184620; Tue, 26 Oct 2010 12:26:24 -0700 (PDT) Received: by 10.231.32.194 with HTTP; Tue, 26 Oct 2010 12:26:24 -0700 (PDT) In-Reply-To: <30058682.post@talk.nabble.com> References: <29978939.post@talk.nabble.com> <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> <30056250.post@talk.nabble.com> <30058682.post@talk.nabble.com> Date: Wed, 27 Oct 2010 03:26:24 +0800 Message-ID: From: Buganini Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 19:49:24 -0000 I have problem in burning DVD with ahci on 9-CURRENT. without ahci everything works fine. With or without ahci, burning CD is okay. -- Buganini From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 19:55:21 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 951CB106566B for ; Tue, 26 Oct 2010 19:55:21 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 2FE218FC12 for ; Tue, 26 Oct 2010 19:55:21 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id o9QJtIlI046858; Tue, 26 Oct 2010 14:55:19 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Tue, 26 Oct 2010 14:55:18 -0500 (CDT) From: "Sean C. Farley" To: Paul B Mahol In-Reply-To: Message-ID: References: <29978939.post@talk.nabble.com> <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> <30056250.post@talk.nabble.com> 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-Status: No, score=-1.0 required=4.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.farley.org Cc: freebsd-stable@FreeBSD.org, Jakub Lach Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 19:55:21 -0000 On Tue, 26 Oct 2010, Paul B Mahol wrote: > On 10/26/10, Jakub Lach wrote: >> Joerg Schilling-3 wrote: >>> >>> wodim is a dead end from a 6 year old version of cdrecord with the >>> DVD support ripped off and replaced by something broken. But there >>> have been even more bugs added to wodim and it is not under >>> "development" since May 2007. >>> >>> If cdrecord gives the same message, I encourage you to make a kernel >>> bug report. This message is a hint to a serious kernel problem. A >>> sense key value -1 cannot happen, so you need to find out why the >>> SCSI command has not been transported correctly by the kernel. >>> >> >> Hi Joerg. >> >> I usually prefer cdrtools, wodim was convenient way to >> try old code. >> >> After booting GENERIC kernel + ahci driver and compiling >> cdrtools release problem is still present. *snip* > I burned bunch of DVD-R, DVD+R and DVD+R DL on FreeBSD 9.0 without any > problems, using growisofs from ports. > > Only problem I ever had was mounting multi-sesion after 4GB (but -r > flag is nice workaround). Personally, I have had trouble burning to a DVD+R using cdrecord. DVD+RW has generally worked for me on my workstation, however, I noticed something interesting last night. When trying to burn a recovery disc using my laptop onto a DVD-RW, a pause occurred near the start of the burn, maybe after two blocks were written, with the disc completing the burn "successfully". I use quotes because the disc did not boot. I am not sure why exactly it would fail (the disc may have been blank, but I do not recall), but here is my observation: 1. cdrecord starts examining the disc. 2. Drive spins up. 3. During grace time before burn the drive starts to slow. 4. Burn starts. 5. cdrecord (or driver or drive) pauses a brief amount of time. I think this is what happened with the DVD+R on my workstation when the drive increased its speed. 6. Drive spins up. 7. Burn continues until end. For me, the solution appeared to be setting the grace time to three seconds to avoid the slowdown of the drive: gracetime=3 At least, the disc worked on subsequent burns this way. Jakub, you may try to see if this setting helps. Sean -- scf@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue Oct 26 20:04:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FCE9106566C for ; Tue, 26 Oct 2010 20:04:54 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 042958FC0A for ; Tue, 26 Oct 2010 20:04:53 +0000 (UTC) Received: by qwe4 with SMTP id 4so2960027qwe.13 for ; Tue, 26 Oct 2010 13:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=it46j8xP3b8OwZV+5X20JLps5zgR9YI53P4RB4La2RI=; b=SYoJRppLan+gERKRcfwQTF2MNcPcLWrjnJg7VkPiw/L54oEnK85i3tqiVdJjwBxp13 ud43Mn8xVlU8LTQJnvAY8g/dw7prTwXC7J31fZgfizAlvdmCzERgZTSfh2E/8uZRAXPB 0SPum/v04PGEQtI5Z/03882umIns9GoSoocZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=f8bWrGfwXubux0IWQI1/ABBcTVzo1SBxwLEEesNvj2JtxDf0ZarjZpjvftkDu5QgIV xDxBPmgLPuuABEppty3MaHNvY+gWWX1kRF328VDLlImhu/bGk5q2BkOMuy7UmJm7jCP4 chNczDFYrg4Mn9BwpJ8uvAu2IuJ7kpnNPST70= MIME-Version: 1.0 Received: by 10.229.91.211 with SMTP id o19mr8054935qcm.87.1288123493251; Tue, 26 Oct 2010 13:04:53 -0700 (PDT) Received: by 10.229.89.138 with HTTP; Tue, 26 Oct 2010 13:04:53 -0700 (PDT) Date: Tue, 26 Oct 2010 13:04:53 -0700 Message-ID: From: Rumen Telbizov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 20:04:54 -0000 Hello everyone, After a few days of struggle with my degraded zpool on a backup server I decided to ask for help here or at least get some clues as to what might be wrong with it. Here's the current state of the zpool: # zpool status pool: tank state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 spare DEGRADED 0 0 0 replacing DEGRADED 0 0 0 17307041822177798519 UNAVAIL 0 299 0 was /dev/gpt/disk-e1:s2 gpt/newdisk-e1:s2 ONLINE 0 0 0 gpt/disk-e2:s10 ONLINE 0 0 0 gpt/disk-e1:s3 ONLINE 30 0 0 gpt/disk-e1:s4 ONLINE 0 0 0 gpt/disk-e1:s5 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s6 ONLINE 0 0 0 gpt/disk-e1:s7 ONLINE 0 0 0 gpt/disk-e1:s8 ONLINE 0 0 0 gpt/disk-e1:s9 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s10 ONLINE 0 0 0 gpt/disk-e1:s11 ONLINE 0 0 0 gpt/disk-e1:s12 ONLINE 0 0 0 gpt/disk-e1:s13 ONLINE 0 0 0 raidz1 DEGRADED 0 0 0 gpt/disk-e1:s14 ONLINE 0 0 0 gpt/disk-e1:s15 ONLINE 0 0 0 gpt/disk-e1:s16 ONLINE 0 0 0 spare DEGRADED 0 0 0 replacing DEGRADED 0 0 0 15258738282880603331 UNAVAIL 0 48 0 was /dev/gpt/disk-e1:s17 gpt/newdisk-e1:s17 ONLINE 0 0 0 gpt/disk-e2:s11 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s18 ONLINE 0 0 0 gpt/disk-e1:s19 ONLINE 0 0 0 gpt/disk-e1:s20 ONLINE 0 0 0 gpt/disk-e1:s21 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s22 ONLINE 0 0 0 gpt/disk-e1:s23 ONLINE 0 0 0 gpt/disk-e2:s0 ONLINE 0 0 0 gpt/disk-e2:s1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e2:s2 ONLINE 0 0 0 gpt/disk-e2:s3 ONLINE 0 0 0 gpt/disk-e2:s4 ONLINE 0 0 0 gpt/disk-e2:s5 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e2:s6 ONLINE 0 0 0 gpt/disk-e2:s7 ONLINE 0 0 0 gpt/disk-e2:s8 ONLINE 0 0 0 gpt/disk-e2:s9 ONLINE 0 0 0 spares gpt/disk-e2:s10 INUSE currently in use gpt/disk-e2:s11 INUSE currently in use gpt/disk-e1:s2 UNAVAIL cannot open gpt/newdisk-e1:s17 INUSE currently in use errors: 4 data errors, use '-v' for a list The problem is: after replacing the bad drives and resilvering the old/bad drives cannot be detached. The replace command didn't remove it automatically and manual detach fails. Here are some examples: # zpool detach tank 15258738282880603331 cannot detach 15258738282880603331: no valid replicas # zpool detach tank gpt/disk-e2:s11 cannot detach gpt/disk-e2:s11: no valid replicas # zpool detach tank gpt/newdisk-e1:s17 cannot detach gpt/newdisk-e1:s17: no valid replicas # zpool detach tank gpt/disk-e1:s17 cannot detach gpt/disk-e1:s17: no valid replicas Here's more information and history of events. This is a 36 disk SuperMicro 847 machine with 2T WD RE4 disks organized in raidz1 groups as depicted above. zpool deals only with partitions like those: => 34 3904294845 mfid30 GPT (1.8T) 34 3903897600 1 disk-e2:s9 (1.8T) 3903897634 397245 - free - (194M) mfidXX devices are disks connected to a SuperMicro/LSI controller and presented as jbods. JBODs in this adapter are actually constructed as raid0 array of 1 disk but this should be irrelevant in this case. This machine was working fine since September 6th but two of the disks (in different raidz1 vdevs) were going pretty bad and accumulated quite a bit of errors until eventually they died. This is how they looked like: raidz1 DEGRADED 0 0 0 gpt/disk-e1:s2 UNAVAIL 44 59.5K 0 experienced I/O failures gpt/disk-e1:s3 ONLINE 0 0 0 gpt/disk-e1:s4 ONLINE 0 0 0 gpt/disk-e1:s5 ONLINE 0 0 0 raidz1 DEGRADED 0 0 0 gpt/disk-e1:s14 ONLINE 0 0 0 gpt/disk-e1:s15 ONLINE 0 0 0 gpt/disk-e1:s16 ONLINE 0 0 0 gpt/disk-e1:s17 UNAVAIL 1.56K 49.0K 0 experienced I/O failures I did have two spare disks ready to replace them. So after they died here's what I executed: # zpool replace tank gpt/disk-e1:s2 gpt/disk-e2:s10 # zpool replace tank gpt/disk-e1:s17 gpt/disk-e2:s11 Resilvering started. While in the middle of it though the kernel paniced and I had to reboot the machine. After reboot I waited until the resilvering is complete. Now that it was complete I expected to see the old/bad device removed from the vdev but it was still there. Trying detach was complaining with no valid replicas. I sent colo technician to replace both those defective drives with brand new ones. Once I had them inserted I recreated them exactly the same way as the ones that I had before - jbod and gpart labeled partition with the same name! Then I added them as spares: # zpool add tank spare gpt/disk-e1:s2 # zpool add tank spare gpt/disk-e1:s17 That actually made it worse I think since now I had the same device name both as a 'previous' failed device inside the raidz1 group and as a hot spare spare device. I couldn't do anything with it. What I did was to export the pool fail the disk on the controller, import the pool and check that zfs could open it anymore (as a part of the hot spares). Then I recreated that disk/partition with a new label 'newdisk-XXX' and tried to replace the device that originally failed (and was only presented with a number). So I did this: # zpool replace tank gpt/disk-e1:s17 gpt/newdisk-e1:s17 # zpool replace tank gpt/disk-e1:s2 gpt/newdisk-e1:s2 Resilvering completed after 17 hours or so and I expected for the 'replacing' operation to disappear and the replaced device to go away. But it didn't! Instead I have the state of the pool as shown in the beginning of the email. As for the 'errors: 4 data errors, use '-v' for a list' I suspect that it's due another failing device (gpt/disk-e1:s3) inside the first (currently degraded) raidz1 vdev. Those 4 corrupted files actually could be read sometimes so that tells me that the disk has trouble reading *sometimes* those bad blocks. Here's the output of zdb -l tank version=14 name='tank' state=0 txg=200225 pool_guid=13504509992978610301 hostid=409325918 hostname='XXXX' vdev_tree type='root' id=0 guid=13504509992978610301 children[0] type='raidz' id=0 guid=3740854890192825394 nparity=1 metaslab_array=33 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='spare' id=0 guid=16171901098004278313 whole_disk=0 children[0] type='replacing' id=0 guid=2754550310390861576 whole_disk=0 children[0] type='disk' id=0 guid=17307041822177798519 path='/dev/gpt/disk-e1:s2' whole_disk=0 not_present=1 DTL=246 children[1] type='disk' id=1 guid=1641394056824955485 path='/dev/gpt/newdisk-e1:s2' whole_disk=0 DTL=55 children[1] type='disk' id=1 guid=13150356781300468512 path='/dev/gpt/disk-e2:s10' whole_disk=0 is_spare=1 DTL=1289 children[1] type='disk' id=1 guid=6047192237176807561 path='/dev/gpt/disk-e1:s3' whole_disk=0 DTL=250 children[2] type='disk' id=2 guid=9178318500891071208 path='/dev/gpt/disk-e1:s4' whole_disk=0 DTL=249 children[3] type='disk' id=3 guid=2567999855746767831 path='/dev/gpt/disk-e1:s5' whole_disk=0 DTL=248 children[1] type='raidz' id=1 guid=17097047310177793733 nparity=1 metaslab_array=31 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=14513380297393196654 path='/dev/gpt/disk-e1:s6' whole_disk=0 DTL=266 children[1] type='disk' id=1 guid=7673391645329839273 path='/dev/gpt/disk-e1:s7' whole_disk=0 DTL=265 children[2] type='disk' id=2 guid=15189132305590412134 path='/dev/gpt/disk-e1:s8' whole_disk=0 DTL=264 children[3] type='disk' id=3 guid=17171875527714022076 path='/dev/gpt/disk-e1:s9' whole_disk=0 DTL=263 children[2] type='raidz' id=2 guid=4551002265962803186 nparity=1 metaslab_array=30 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=12104241519484712161 path='/dev/gpt/disk-e1:s10' whole_disk=0 DTL=262 children[1] type='disk' id=1 guid=3950210349623142325 path='/dev/gpt/disk-e1:s11' whole_disk=0 DTL=261 children[2] type='disk' id=2 guid=14559903955698640085 path='/dev/gpt/disk-e1:s12' whole_disk=0 DTL=260 children[3] type='disk' id=3 guid=12364155114844220066 path='/dev/gpt/disk-e1:s13' whole_disk=0 DTL=259 children[3] type='raidz' id=3 guid=12517231224568010294 nparity=1 metaslab_array=29 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=7655789038925330983 path='/dev/gpt/disk-e1:s14' whole_disk=0 DTL=258 children[1] type='disk' id=1 guid=17815755378968233141 path='/dev/gpt/disk-e1:s15' whole_disk=0 DTL=257 children[2] type='disk' id=2 guid=9590421681925673767 path='/dev/gpt/disk-e1:s16' whole_disk=0 DTL=256 children[3] type='spare' id=3 guid=4015417100051235398 whole_disk=0 children[0] type='replacing' id=0 guid=11653429697330193176 whole_disk=0 children[0] type='disk' id=0 guid=15258738282880603331 path='/dev/gpt/disk-e1:s17' whole_disk=0 not_present=1 DTL=255 children[1] type='disk' id=1 guid=908651380690954833 path='/dev/gpt/newdisk-e1:s17' whole_disk=0 is_spare=1 DTL=52 children[1] type='disk' id=1 guid=7250934196571906160 path='/dev/gpt/disk-e2:s11' whole_disk=0 is_spare=1 DTL=1292 children[4] type='raidz' id=4 guid=7622366288306613136 nparity=1 metaslab_array=28 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=11283483106921343963 path='/dev/gpt/disk-e1:s18' whole_disk=0 DTL=254 children[1] type='disk' id=1 guid=14900597968455968576 path='/dev/gpt/disk-e1:s19' whole_disk=0 DTL=253 children[2] type='disk' id=2 guid=4140592611852504513 path='/dev/gpt/disk-e1:s20' whole_disk=0 DTL=252 children[3] type='disk' id=3 guid=2794215380207576975 path='/dev/gpt/disk-e1:s21' whole_disk=0 DTL=251 children[5] type='raidz' id=5 guid=17655293908271300889 nparity=1 metaslab_array=27 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=5274146379037055039 path='/dev/gpt/disk-e1:s22' whole_disk=0 DTL=278 children[1] type='disk' id=1 guid=8651755019404873686 path='/dev/gpt/disk-e1:s23' whole_disk=0 DTL=277 children[2] type='disk' id=2 guid=16827379661759988976 path='/dev/gpt/disk-e2:s0' whole_disk=0 DTL=276 children[3] type='disk' id=3 guid=2524967151333933972 path='/dev/gpt/disk-e2:s1' whole_disk=0 DTL=275 children[6] type='raidz' id=6 guid=2413519694016115220 nparity=1 metaslab_array=26 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=16361968944335143412 path='/dev/gpt/disk-e2:s2' whole_disk=0 DTL=274 children[1] type='disk' id=1 guid=10054650477559530937 path='/dev/gpt/disk-e2:s3' whole_disk=0 DTL=273 children[2] type='disk' id=2 guid=17105959045159531558 path='/dev/gpt/disk-e2:s4' whole_disk=0 DTL=272 children[3] type='disk' id=3 guid=17370453969371497663 path='/dev/gpt/disk-e2:s5' whole_disk=0 DTL=271 children[7] type='raidz' id=7 guid=4614010953103453823 nparity=1 metaslab_array=24 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=10090128057592036175 path='/dev/gpt/disk-e2:s6' whole_disk=0 DTL=270 children[1] type='disk' id=1 guid=16676544025008223925 path='/dev/gpt/disk-e2:s7' whole_disk=0 DTL=269 children[2] type='disk' id=2 guid=11777789246954957292 path='/dev/gpt/disk-e2:s8' whole_disk=0 DTL=268 children[3] type='disk' id=3 guid=3406600121427522915 path='/dev/gpt/disk-e2:s9' whole_disk=0 DTL=267 OS: 8.1-STABLE FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 amd64 Hardware: Chassis: SuperMicro 847E1 (two backplanes 24 disks front and 12 disks in the back) Motherboard: X8SIL CPU: 1 x X3430 @ 2.40GHz RAM: 16G HDD Controller: SuperMicro / LSI 9260 (pciconf -lv SAS1078 PCI-X Fusion-MPT SAS) : 2 ports Disks: 36 x 2T Western Digital RE4 Any help would be appreciated. Let me know what additional information I should provide. Thank you in advance, -- Rumen Telbizov From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 00:02:10 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C93A31065693; Wed, 27 Oct 2010 00:02:10 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9488FC21; Wed, 27 Oct 2010 00:02:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9R02AUr028641; Wed, 27 Oct 2010 00:02:10 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9R02AnK028634; Wed, 27 Oct 2010 00:02:10 GMT (envelope-from danger) Date: Wed, 27 Oct 2010 00:02:10 +0000 From: Daniel Gerzo To: hackers@freebsd.org Message-ID: <20101027000210.GA18428@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: FreeBSD Status Report July - September, 2010 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 00:02:10 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD-related projects between July and September 2010. It is the third of the four reports planned for 2010. During this period, we were victims of one of the biggest BSD events of the year -- EuroBSDCon. We hope that the ones of you who have been able to attend it have enjoyed your stay. Another good news is that work on the new minor versions of FreeBSD, 7.4 and 8.2, is progressing well. This report, with 55 entries, is the longest report in the whole history and shows a good condition of the FreeBSD community. Thanks to all the reporters for the excellent work! We hope you enjoy reading it. Please note that the deadline for submissions covering the period between October and December 2010 is January 15th, 2011. __________________________________________________________________ Google Summer of Code * Atheros AR913x SoC Support * Binary Package Patch Infrastructure -- pkg_patch * ExtFS Status Report * Packet Capturing Stack -- ringmap * Registration of Optional Kernel Subsystems via sysctl Projects * BSD# Project * BSNMP Enhancements * Capsicum: Practical Capabilities for UNIX * Clang Replacing GCC in the Base System * DAHDI/FreeBSD Project * External Toolchain Support * GELI Additions * gptboot Improvements * HAST (Highly Available Storage) Improvements * Kernel-level Stacked Cryptographic File System -- PEFS * pc-sysinstall * Target Big Endian Must Die * Userland DTrace * V4L Support in Linux Emulator * ZFSv28 is Ready for Wider Testing FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD KDE Team * FreeBSD Release Engineering Team * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * Five New TCP Congestion Control Algorithms for FreeBSD * Syncing pf(4) with OpenBSD 4.5 Kernel * Kernel Event Timers Infrastructure * Netdump Support * Resource Containers * USB Stack Documentation * mandoc/mdocml -- groff Replacement for Rendering Manual Pages in FreeBSD * The FreeBSD German Documentation Project * The FreeBSD Japanese Documentation Project * Web Feeds for UPDATING Files Userland Programs * FreeBSD Services Control (fsc) * Updating Base Tools to Accommodate Ports Requirements * xz Compression for Packages and Log Files Architectures * Bringing up ARM to FreeBSD Tree * FreeBSD on the Playstation 3 * FreeBSD/mips on Octeon * FreeBSD/mips Ralink RT3052F/Broadcom BCM5354 * FreeBSD/sparc64 Ports * Chromium Web Browser * OpenAFS Port * pkg_upgrade (sysutils/bsdadminscripts) * Ports Collection * Ports Distfile and WWW Checker * Valgrind Port Miscellaneous * BSD-Day@2010 * EuroBSDCon 2010 * EuroBSDCon 2011 * FreeBSD Developer Summit, Karlsruhe * FreeBSD Developer Summit, meetBSD California 2010 * PC-BSD __________________________________________________________________ Atheros AR913x SoC Support URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosStuff URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosHalStuff Contact: Adrian Chadd FreeBSD-CURRENT runs on the AR9132 SoC. Minor platform-specific tweaks are needed to use it on a given piece of hardware (eg., where in flash the Ethernet MAC address is stored.) The AR910x wireless MAC/PHY is supported. The only available test platform uses a 2.4GHz radio; 5GHz 11a mode has not been tested. As with other Atheros chipset support in FreeBSD, 11n support is not yet finished. The current development platform is the TP-Link TP-WN1043ND 802.11n wireless bridge/router. It is currently being successfully used as a 11bg access point. Open tasks: 1. USB support is currently not functional. 2. There is currently no support for the Realtek Gigabit switch/PHY chip. This is being worked on. __________________________________________________________________ Binary Package Patch Infrastructure -- pkg_patch URL: http://wiki.FreeBSD.org/IvanVoras/pkg_patch Contact: Ivan Voras pkg_patch is a tool meant to be used with the rest of the pkg_* utilities whose job is to create and apply binary patches to FreeBSD package archives. The SoC project was successfully completed but there are some open issues about the integration of the tool in the FreeBSD system. Some changes are necessary to the port/patch infrastructure to support the "update" mode instead of "remove+add". Open tasks: 1. Solve pending issues about the ports install/upgrade workflow, probably within the pkg_install2 effort. __________________________________________________________________ Bringing up ARM to FreeBSD Tree Contact: Warner Losh Contact: Mohammed Farrag We are still in the beginning of the project since we started it after the summer of code. Open tasks: 1. Reading ARM structure. 2. Reading MicroC OS. 3. Using Qemu to emulate the work. __________________________________________________________________ BSD# Project URL: http://code.google.com/p/bsd-sharp/ URL: http://www.mono-project.org/ Contact: Romain TartiÄre The BSD# Project is devoted to porting the Mono .NET framework and applications to the FreeBSD operating system. Mono 2.8 has been released a few days ago and is already available in the BSD# repository. The update breaks a few ports so the lang/mono update in the FreeBSD ports tree will be delayed until those programs are fixed for a smoother update experience. Work is in progress to include some long-awaited ports such as deskutils/gnome-do but they require a lot of testing and hacking because they have clearly been designed to run on GNU/Linux and portability has never been a priority (which is quite amusing if you consider portability is the main reason to be for mono). Open tasks: 1. If you have some time, test mono ports and send feedback. 2. If you have more time, join the BSD# Team! There are many ways to help out! 3. Currently low priority, some mono hackers who do not use FreeBSD would be interested in a debug live-image of FreeBSD to help us diagnose and fix bugs more effectively. __________________________________________________________________ BSD-Day@2010 URL: http://wiki.FreeBSD.org/BSDDay_2010 Contact: Gábor Páli The purpose of this one-day event is to gather Central European developers of today's open-source BSD systems to popularize their work and their organizations, and to meet each other in the real life. We would also like to motivate potential future developers and users, especially undergraduate university students to work with BSD systems. This year's BSD-Day will be held in Budapest, Hungary at Eötvös Loránd University, Faculty of Informatics on November 20, 2010. Everybody is welcome! __________________________________________________________________ BSNMP Enhancements URL: http://wiki.FreeBSD.org/CategorySNMP URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/syrinx/s nmp_ieee80211&HIDEDEL=NO URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/syrinx/s yrinx_bsnmpv3&HIDEDEL=NO Contact: Shteryana Shopova Contact: Philip Paeps During the previous few months several additions were developed to FreeBSD's built-in SNMP daemon -- bsnmpd(1). First a snmp_wlan(3) module was developed that allows monitoring and configuration of wlan(4) interfaces operating in various modes, including statistics, attached/neighboring station information, MAC access control entries and mesh routing information. The module's code was submitted in SVN and is now a part of the FreeBSD base system. Next, SNMPv3 authentication and encryption support were added to bsnmplib(3), bsnmpd(1) and bsnmptools (which are available via the ports system currently). The message digest and cipher calculation calls use the implementation of the relevant cryptographic algorithm implementation in OpenSSL's crypto(3) library. bsnmpd(1) may still optionally be compiled without the crypto(3) library, in which case only unauthenticated plain-text SNMPv3 PDUs may be processed. In addition, a snmp_usm(3) module was developed that is used to configure SNMPv3 users parameters (name, authentication & encryption algorithms used and relevant keys, etc.) into bsnmpd(1) as per RFC 3414. Finally, a snmp_vacm(3) module was developed that allows configuration of view-based access control as per RFC 3415, and relevant checks are made by bsnmpd(1) that allow or restrict access to specific SNMPv1/SNMPv2 communities or SNMPv3 users to certain MIB subtrees as per the configuration in the snmp_vacm(3) module. If none of the SNMPv3-related modules is loaded, bsnmpd(1) preserves its current behavior with SNMPv1/SNMPv2c PDUs. This work is being funded by the FreeBSD Foundation. Open tasks: 1. Update Wiki Page to reflect latest work and document proper use. 2. Finish cleanup and have it reviewed. 3. More extensive user testing. __________________________________________________________________ Capsicum: Practical Capabilities for UNIX URL: http://www.cl.cam.ac.uk/research/security/capsicum/ URL: https://lists.cam.ac.uk/mailman/listinfo/cl-capsicum-discuss URL: http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-se curity-capsicum-website.pdf Contact: Robert Watson Contact: Jonathan Anderson Contact: Ben Laurie Contact: Kris Kennaway Capsicum is a lightweight OS capability and sandbox framework developed at the University of Cambridge Computer Laboratory, supported by a grant from Google. Capsicum extends the POSIX API, providing several new OS primitives to support object-capability security on UNIX-like operating systems: capabilities, a new sandboxed capability mode for processes, anonymous shared memory objects, process descriptors, and a modified C runtime able to support distributed applications within sandboxes. Capsicum has been prototyped on FreeBSD -CURRENT, with a 8-STABLE backport. Capsicum is intended to supplement existing system-centric mandatory access control protections by providing an application-centric protection model, which better supports compartmentalised user programs that set up one (or many) sandboxes to process untrustworthy data in. A number of applications, from tcpdump to the Chromium web browser, have been modified to use sandboxing to confine risky activities such as the parsing of untrusted packets and HTML/JavaScript rendering. We plan to begin merging the core Capsicum kernel features to FreeBSD -CURRENT in November/December 2010 once a number of known problems have been resolved. Following a KBI analysis, we will consider merging our 8-STABLE backport to Subversion. For the time being, and while APIs stabilise, we plan to distribute the Capsicum libraries via ports. However, simply having the kernel features in place is sufficient to support sandboxing in tcpdump and Chromium. The Capsicum paper by Robert Watson / Jonathan Anderson (Cambridge) and Ben Laurie / Kris Kennaway (Google) won a best paper award at the 2010 USENIX Security Symposium! Open tasks: 1. More aggressively test (and as needed, fix) possible UNIX domain socket garbage collector interactions with Capsicum. 2. Using results of our recent model checking analysis of the namei() sandboxing approach, make robustness improvements. 3. Merge to FreeBSD -CURRENT in November/December. 4. KBI analysis for possible 8-STABLE merge. 5. Convert more applications to use Capsicum sandboxing! __________________________________________________________________ Chromium Web Browser URL: http://chromium.hybridsource.org URL: http://chromium.hybridsource.org/issues Contact: Ruben Chromium is a Webkit-based web browser that is largely BSD licensed and was recently committed to ports. It has been working well on FreeBSD and supports new features like HTML 5 video. Newer builds use the Clang compiler, Clang first compiled a non-debug build of Chromium, a very large C++ project, on FreeBSD. This porting effort employs a new hybrid-source model: portions of the latest FreeBSD patches are kept closed for a limited time and new builds are made available only to paying subscribers, while older builds are eventually spun off to ports. Further work remains to port all of Chromium to FreeBSD, I am now porting the task manager to use FreeBSD's libkvm and the ALSA audio backend needs to be ported to OSS. There are other issues listed at the porting summary, contact me if you would like to pitch in. __________________________________________________________________ Clang Replacing GCC in the Base System URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach Contact: Dimitry Andric We recently imported the 2.8 release of Clang into -CURRENT. This release contains many new features and improvements. The integrated assembler ships with this version, but it is not ready for general use yet. Since r212979, all necessary changes have been committed to be able to build world with Clang, at least on amd64 and i386. It can also be installed and run, and we are now starting the process of shaking out the inevitable bugs. Because LLVM and Clang are still being improved continuously, we want to import new versions regularly, approximately every two months, to gain access to new features, bug fixes and performance improvements. There is also an effort on behalf of the ports people, to make as many ports as possible compile and run properly with Clang. Most of the time, this means fixing the incorrect assumption that gcc is the only existing compiler, but sometimes more complicated issues pop up. Help in this area is greatly appreciated. Open tasks: 1. Importing new Clang snapshots fairly regularly (approximately bi-monthly). 2. Seeing if Clang can be used to build world for ARM (volunteers and ARM experts wanted). 3. Fixing as many ports as possible to build with Clang. 4. Running periodical ports exp builds with Clang (on amd64 and i386), for example once a month. __________________________________________________________________ DAHDI/FreeBSD Project URL: http://www.asterisk.org/dahdi/ URL: http://svn.digium.com/svn/dahdi/freebsd/ URL: https://spreadsheets.google.com/pub?key=0Arw6eRL10yIwdGhLdGJWUHF4b3ExQz Bsd3BGd2tublE&hl=en&single=true&gid=0&output=html Contact: Max Khon The purpose of DAHDI/FreeBSD project is to make it possible to use FreeBSD as a base system for software PBX solutions. DAHDI (Digium/Asterisk Hardware Device Interface) is an open-source device driver framework and a set of hardware drivers for E1/T1, ISDN digital, and FXO/FXS analog cards [1]. Asterisk is one of the most popular open-source software PBX solutions [2]. The project includes porting DAHDI framework and hardware drivers for E1/T1, FXO/FXS analog, and ISDN digital cards to FreeBSD. This also includes TDMoE support, software and hardware echo cancellation (Octasic, VPMADT032), and hardware transcoding support (TC400B). The work is ongoing in the official DAHDI SVN repository with the close collaboration with DAHDI folks at Digium. DAHDI/FreeBSD project is completed. ports/misc/dahdi now contains the most recent DAHDI/FreeBSD version and additional stuff that is not available in DAHDI/FreeBSD SVN repository due to licensing and copyright restrictions (OSLEC echo canceler, experimental zaphfc driver). Experimental sparc64 support is also implemented and is currently being tested. There is a pile of minor changes in queue that will be handled soon: * Add ability to run asterisk+dahdi under non-root user account. * Add support for bri_net_ptmp ISDN signalling to asterisk port and drop old and outdated zaptel+asterisk-bristuff ports. Periodic merges from DAHDI/Linux SVN will be continued on a regular basis with rolling out new DAHDI/FreeBSD releases (most likely synchronized with DAHDI/Linux releases). __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDFoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart All outstanding patches have been committed to -CURRENT after a lengthy review process. It is anticpated to merge all of the project's SIFTR and reassembly queue-related patches from -CURRENT to the stable branches in time for the upcoming 7.4 and 8.2 releases. __________________________________________________________________ EuroBSDCon 2010 URL: http://2010.EuroBSDCon.org/ URL: http://2011.EuroBSDCon.org/ Contact: Wolfgang Zenker Contact: Gábor Páli EuroBSDCon 2010 happened in Karlsruhe, Germany, with many users, developers, friends, and others. We had many tutorials, and 22 interesting presentations on various topics connected to FreeBSD, OpenBSD, NetBSD, like the new USB stack, jail improvements, Virtual Private Systems, SSH and PGP convergence, ZFS, journaled Soft-Updates, BSD certification, porting to the latest ARM processors, and pc-sysinstall. The event was opened by a keynote speech from Poul-Henning Kamp on software tools and their future, and it was closed by short status reports on different BSD flavors. __________________________________________________________________ EuroBSDCon 2011 URL: http://2011.eurobsdcon.org/ URL: http://2011.eurobsdcon.org/CfP.html Contact: Philip Paeps EuroBSDCon is the European technical conference for users and developers on BSD based systems. The EuroBSDCon 2011 conference will be held in the Netherlands from Thursday 6 October 2011 to Sunday 9 October 2011, with tutorials on Thursday and Friday and talks on Saturday and Sunday. The EuroBSDCon conference is inviting developers and users of BSD based systems to submit innovative and original papers not submitted to other European conferences on BSD-related topics. Please see the EuroBSDCon 2011 website for more details. __________________________________________________________________ External Toolchain Support Contact: Warner Losh One problem that the project has with its push towards embedded platforms is with the toolchain. The compilers and linkers and such in the current FreeBSD support the architectures generically, but often times silicon vendors produce specialized toolchains to wring the most performance out of their silicon. Right now, it is difficult to compile FreeBSD with these tools, as many manual steps are required to make things 'just so'. The external toolchain project will leverage some of the work done by the Clang team to support Clang in the base system (breaking the strict dependency on CC=cc (except for the broken intel CC support)). In addition, the orchestration of the build (make buildworld) will change to avoid bootstrapping certain tools, or compiling the compilers at all. In addition, support for using alternate assemblers, linkers, etc., will be added. The work will be done in subversion in projects/xtc (for eXternal Tool Chain). __________________________________________________________________ ExtFS Status Report URL: http://wiki.FreeBSD.org/SOC2010ZhengLiu URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/soc2010/extfs/src/sy s/fs/&c=rFV@//depot/projects/soc2010/extfs/src/sys/fs/ext2fs/?ac=83 URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/soc2010/ext4fs/src/s ys/fs/&c=cc4@//depot/projects/soc2010/ext4fs/src/sys/fs/ext4fs/?ac=83 Contact: Zheng Liu This project has two goals: pre-allocation algorithm for ext2fs and ext4 read-only mode. Aim of the pre-allocation algorithm is to implement a reservation window mechanism. This mechanism has been implemented and a patch have been submitted. The aim of ext4 read-only mode is to make it possible to read ext4 file systems in read-only mode when the disk is formatted with default features. Until now it can read data from ext4 file systems with default features in read-only mode. A patch has been submitted a patch to the freebsd-fs mailing list and there is a new kernel module, called ext4fs, is under development for it. Open tasks: 1. More testing of the pre-allocation algorithm. __________________________________________________________________ Five New TCP Congestion Control Algorithms for FreeBSD URL: http://caia.swin.edu.au/freebsd/5cc/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDFoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/5cc/ Contact: David Hayes Contact: Lawrence Stewart Contact: Grenville Armitage Contact: Rui Paulo Work has commenced on a newly funded FreeBSD Foundation project to bring six modular TCP congestion control (CC) algorithm implementations (the existing NewReno and five new algorithms: HTCP, CUBIC, Vegas, HD and CHD) to the FreeBSD kernel. See the CAIA 5cc and NewTCP websites for more details on the algorithms. To support the project's primary deliverable, we will also be incorporating the CAIA modular CC and Khelp frameworks into the FreeBSD kernel, along with the Enhanced Round Trip Time Khelp module. The project will make a sizable, state-of-the-art contribution to FreeBSD and in certain areas, add completely novel work unavailable in any other operating system known to us. We anticipate a number of benefits, including vastly improved researcher friendliness, reduced work for TCP oriented vendors of FreeBSD-based appliances, and greater choice for system administrators who operate FreeBSD systems in atypical network scenarios. Keep an eye on the freebsd-net mailing list for project-related announcements. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth The bugbusting team continue work on trying to make the contents of the GNATS PR database cleaner, more accessible and easier for committers to find and resolve PRs, by tagging PRs to indicate the areas involved, and by ensuring that there is sufficient info within each PR to resolve each issue. July saw the addition of Alexander Best (arundel@) to this bugbusting team, he is helping with the triaging PRs as they come in, creating patches for problems and working with submitters to get the solutions tested, and working through the PR backlog. Also in July, Gavin Atkinson worked with Hans Petter Selasky on the USB PRs, attempting to go through many of them and determine the status of each of them. As a result, nearly 10% of the USB PRs were determined to be closeable, with many more either being marked as patched already or able to be committed quickly. Several PRs that only affect the old (pre-8.0) USB stack were also identified and marked as such. More work will take place in this area in the future. August saw us host another bugathon, with an aim of investigating and getting into a committable state several of the PRs with patches. Turnout was not as great as in the past -- mainly believed to be die to the short notice, but still several PRs were progressed, with several commits made and several PRs closed. The number of PRs has held steady over the last three months, with improvements in numbers in some categories (especially usb and bin) being offset by slight increases in others. Reports continue to be produced from the PR database, all of which can be found from the links above. Committers interested in custom reports are encouraged to discuss requirements with bugmeister@ -- we are happy to create new reports where needs are identified. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. 2. Try to get more non-committers involved with the triaging of PRs as they come in, and generating patches to fix reported problems. __________________________________________________________________ FreeBSD Developer Summit, Karlsruhe URL: http://wiki.FreeBSD.org/201010DevSummit Contact: Gábor Páli We were happy to have more than 40 FreeBSD developers and guests attending the FreeBSD Developer Summit prior to EuroBSDCon 2010 in Karlsruhe, Germany. This workshop-style event was hosted at Karlsruhe Institute of Technology, and included prepared presentations in the morning, as well as group hacking and discussion sections in the afternoon. We had various talks on several topics, covering the USB subsystem, state of the toolchain, the FreeBSD documentation, NanoBSD improvements, FreeBSD port of PF, jails, Virtual Private Systems, cooperation with the PC-BSD Project, FreeNAS, the new event timers subsystems, bugbusting discussions and Ports Tinderbox presentations, and many of this year's and last year's Google Summer of Code projects. Photos, videos, and slides for most of the talks are available on the wiki page. __________________________________________________________________ FreeBSD Developer Summit, meetBSD California 2010 URL: http://wiki.FreeBSD.org/201011DevSummit Contact: Warner Losh We will be having a developers summit meeting at meetBSD California 2010 on November 4th, the day before the conference. Based on who is in attendance, we will be talking about the status of pressing issues; working on pressing problems and using the opportunity for face to face meetings to work out issues that are difficult in email. This is an invitation-only event, but any developer can invite people they think would help drive this meeting forward. An agenda will be published closer to the date. __________________________________________________________________ FreeBSD KDE Team URL: http://FreeBSD.kde.org Contact: FreeBSD KDE Team Contact: Thomas Abthorpe Contact: Max Brazhnikov Contact: Kris Moore Contact: Dima Panov Contact: Alberto Villa The FreeBSD KDE team has been actively keeping pace with development cycle as it is released by the KDE developers. Often having KDE in the ports tree within the same week it has been released. An integral part of maintaining KDE exists in supporting the Qt toolchain. As Nokia releases Qt, our team is keeping pace making it available in our development repository. We are fortunate to have a strong contributor base that helps to keep the process moving along. Our heartfelt thanks go out to all that have helped with patches, maintaining ports, and responding with help on the mailing lists. Open tasks: 1. KDE 4.5.4 is due out at the end of November, with 4.6.0 to be released early in 2011. 2. The FreeBSD KDE team is always looking for helpers, if you are interested in assisting, please feel free to contact any of our team members. __________________________________________________________________ FreeBSD on the Playstation 3 URL: svn://svn.FreeBSD.org/base/user/nwhitehorn/ps3 URL: http://people.FreeBSD.org/~nwhitehorn/ps3 Contact: Nathan Whitehorn Contact: Peter Grehan FreeBSD/powerpc64 now boots multi-user SMP and is self-hosting on the Playstation 3. Booting requires a PS3 console with the OtherOS capability (fat model console with firmware < 3.21). The only supported hardware at present is USB and the Ethernet controller. Open tasks: 1. SATA support. 2. Boot loader enhancements to allow user input at the loader prompt. 3. Support for the Cell SPU units. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team has announced the schedule for the upcoming joint release of FreeBSD 7.4 and 8.2. The schedules are available on the web site: * 7.4-RELEASE schedule * 8.2-RELEASE schedule It is expected that 7.4 will be the last of the 7.X releases. __________________________________________________________________ FreeBSD Services Control (fsc) URL: http://people.FreeBSD.org/~trhodes/fsc/ Contact: Tom Rhodes FreeBSD Services Control is a mix of binaries which integrate into the rc.d system and provide for service (daemon) monitoring. It knows about signals, pidfiles, and uses very little resources. The fsc daemon (fscd) runs in the background once the system has started. Services are then added to this daemon via the fscadm control utility and from there they will be monitored. When they die, depending on the reason, they will be restarted. Certain signals may be ignored (list not decided), and fscd will remove that service from monitoring. Every action is logged to the system logging daemon. Additionally, the fscadm utility may be used to inquire about what services are monitored, their pidfile location, and current process id. FSC provides several advantages over the third-party daemontools package. For example, fscd uses push notifications instead of polling; fscd is an internal, FreeBSD-maintained software package accessible to all developers where daemontools would have to be a port and require us to maintain patches; fscd could be easily integrated with the current rc.d infrastructure. Partially based on the ideas of daemontools and Solaris Service Management Facility (SMF), this could be an extremely useful tool for FreeBSD systems. Since the last status report, two bugs have been fixed and the documentation has been updated. In the coming weeks we hope to get more developer attention and review, perhaps even push to commit the code into FreeBSD. Open tasks: 1. Testing and feedback would be really helpful. __________________________________________________________________ FreeBSD/mips on Octeon URL: http://wiki.FreeBSD.org/FreeBSD/mips/Octeon Contact: Juli Mallett All Octeon development is now ongoing in -CURRENT and most Octeon-specific and general MIPS changes from the old Octeon branch have been checked in. The Simple Executive from the Cavium Octeon SDK has been checked into Subversion and most of the Octeon port has been updated to use it where appropriate, including moving to a port of the Linux Ethernet driver, octe. SMP support is stable on 2-core systems and has seen some testing on systems with up to 16 cores. Open tasks: 1. Some PCI devices still do not seem to work completely. 2. Host-mode USB support is incomplete and needs further testing and debugging. 3. Work on an ATA-based Compact Flash driver for boards that support DMA has begun. 4. A GPIO driver should be trivial using the Simple Executive. 5. Performance in the Linux-derived octe Ethernet driver could be improved. Support for some switch chipsets that are commonly present in Octeon-based equipment is in progress. __________________________________________________________________ FreeBSD/mips Ralink RT3052F/Broadcom BCM5354 URL: http://wiki.ddteam.net/wiki.cgi?page=DIR-320+FreeBSD URL: http://my.ddteam.net/hg/BASE/ Contact: Aleksandr Rybalko FreeBSD/mips has been ported to D-Link DAP-1350, wireless AP/router based on Ralink RT3052F SoC. Drivers status: * rt2860: Ralink RT2860 802.11n -- Worked, but RT3022 2.4G 2T2R radio tuning required. * rt: Ralink RT3052F onChip Ethernet MAC -- Done. * rtsw: OnChip Ethernet switch -- Not done (initialized by UBoot). * usb-otg: DWC like USB OTG controller -- Worked. * gpio: RT3052F onChip GPIO -- Worked (LEDs, Buttons). * cfi: CFI NOR Flash -- Worked. FreeBSD/mips D-Link DIR-320 project(BCM5354 SoC). New profile openvpn-router available for testing. Open tasks: 1. Debug/Fix USB OTG driver (RT3052F). 2. Debug/Fix 802.11n driver (RT3052F). 3. Write rtswitch driver (RT3052F). 4. Implement Timer unit driver (RT3052F). 5. Implement Hardware NAT/PPPoE/VLAN offload (RT3052F). 6. Implement I2C/I2S/PCM/SPI drivers (RT3052F). 7. switch configuration utility (BCM5354). __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Apart from the constant bug fixing and adaptions to machine-independent changes that pretty much always take place, not much has happened in the area of sparc64 since the last status report. The only noteworthy exception are some performance optimizations which take advantage of features of Fujitsu SPARC64 CPUs. These were a bit too risky for putting them in shortly before FreeBSD 8.1-RELEASE but will be part of 7.4-RELEASE and 8.2-RELEASE now that they have received the necessary testing. Part of reasons why not much has happened in this spot was some lack of time on my side but also due to nobody showing up with a not yet supported sun4u machine lately and me delving in the network land instead, which yielded some things to report about in the next status report. On the other hand I recently got a hold of a Sun Fire 3800, so these and other models from the same family likely will be supported by FreeBSD at some point in the future. __________________________________________________________________ GELI Additions Contact: Pawel Jakub Dawidek There are three new GELI (a disk encryption GEOM class) features available in -CURRENT: * AES-XTS encryption. XTS mode is a standard that is recommended these days for storage encryption. This is the default now. AES-XTS support was also added to opencrypto framework and aesni(4) driver. * Multiple encryption keys. GELI will use one encryption key for at most 2^20 blocks (sectors), as it is not recommended to use the same encryption key for too much data. It generates a key array from the master key on attach and uses it accordingly. This is the default now. * Passphrase can now also be loaded from a file (-J and -j options). __________________________________________________________________ gptboot Improvements URL: http://lists.FreeBSD.org/pipermail/svn-src-head/2010-September/020957.h tml Contact: Pawel Jakub Dawidek The gptboot now fully follows GPT specification (verifies checksums and falls back to backup header and table if primary is corrupted). One can now use new attributes to configure partition that gptboot will try to boot only once from and in case of a failure it will fall back to the previous one. For more information check out the commit message. __________________________________________________________________ HAST (Highly Available Storage) Improvements Contact: Pawel Jakub Dawidek HAST is now better than ever! Some recent improvements include: * Hooks supports -- HAST will execute the given command on various events (connect, disconnect, synchronization start, synchronization completed, synchronization interrupted, split-brain condition, role change). * Configuration reload on SIGHUP, a very missing functionality. * Internal keepalive mechanism. * Many bug fixes, majority of them reported by Mikolaj Golub. __________________________________________________________________ Kernel Event Timers Infrastructure URL: http://wiki.FreeBSD.org/201010DevSummit?action=AttachFile&do=get&target =timers.pdf URL: http://people.FreeBSD.org/~mav/tm6292_idle.patch Contact: Alexander Motin Work on new event timers infrastructure continues. In -CURRENT amd64, arm (Marvell), i386, mips, pc98, powerpc, sparc64, sun4v architectures were refactored to use new timers API. New machine-independent timers management code was written. It can utilize both legacy periodic and new one-shot timer operation modes. Using one-shot mode allows to significantly reduce the number of timer interrupts and respectively increase CPU sleep time during idle periods. Timer interrupts on idle CPUs are now generated only when they are needed to handle registered time-based events. Busy CPUs unluckily still receive the full interrupt rate for purposes of resource accounting, scheduling and timekeeping. With some additional tuning it is now possible to have an 8-core system, receiving only about 100 interrupts per second and respectively have CPU idle periods up to 100ms. This allows to effectively use any supported CPU idle states (C-states), that reduces power consumption and increases effect of the Intel TurboBoost technology. New manual pages were written to document this functionality: eventtimers(7), attimer(4), atrtc(4), hpet(4). Open tasks: 1. Troubleshoot possible hardware issues. 2. Refactor remaining architectures (arm, ia64, XEN PV). 3. Do some optimizations in different subsystems to reduce number of time-based events. Extend callout API with terms of precision, allowing to group close events. 4. Make schedulers tickless, or at least less depending on time events to make skipping timer interrupts possible when CPUs are busy. 5. Merge code into 8-STABLE when it is considered ready. __________________________________________________________________ Kernel-level Stacked Cryptographic File System -- PEFS URL: http://wiki.FreeBSD.org/PEFS URL: http://github.com/glk/pefs Contact: Gleb Kurtsou PEFS is a kernel level stacked cryptographic file system, i.e. it stacks on top of existing mounted filesystems. AES and Camellia algorithms in XTS mode are supported. The project has matured since Summer of Code 2009, most important improvements for last few months include: switch to use XTS encryption mode, implementation of sparse file support, fixing rename bugs including race and livelock conditions, addition of ext2 support. PEFS suite contains pam module facilitating user authentication with file system key and adding keys to mounted file system on login. PEFS passes fsx, pjdfstest, blogbench and dbench tests running on top of UFS and ZFS. __________________________________________________________________ mandoc/mdocml -- groff Replacement for Rendering Manual Pages in FreeBSD URL: http://mdocml.bsd.lv/ URL: https://www.spoerlein.net/cgit/cgit.cgi/freebsd.work/log/?h=mdocml Contact: Ulrich Spörlein Kristaps' groff-replacement (only for rendering manual pages) is already available in NetBSD and OpenBSD, and used to render the base system manpages for the latter. This project aims to do similar things for FreeBSD. mandoc(1) is more strict in what it accepts as input and is still lacking some features that are used by some selected few manpages. Getting manual page fixes accepted by upstream vendors has been challenging. Waiting for them to round-trip back into FreeBSD will take even longer. Future work will therefore result in direct commits to our contrib/ and gnu/ repository areas, in the hope this will not impact future vendor imports too much. Open tasks: 1. Finish the Big Manpage Cleanup of 2010. 2. Write a textproc/groff port for the latest groff version. 3. Import mandoc(1), switch to catpages for base. 4. Supply necessary ports infrastructure to opt-in to mandoc(1). 5. Discuss future of groff(1) in base wrt. share/doc. __________________________________________________________________ Netdump Support URL: http://wiki.FreeBSD.org/Netdump URL: svn://svn.FreeBSD.org/base/project/sv/ Contact: Attilio Rao Contact: Ed Maste Netdump provides kernel core dumping over the network, instead of to a local disk. It implements a very minimal TCP/IPv4 stack and uses a custom UDP protocol to transmit the dump to the netdump server running on another host. Network interfaces selected for dumping perform I/O in polling mode. Netdump should find its use in diskless workstation clusters, PXE-booted test machines, and perhaps when doing disk driver development. Open tasks: 1. General FreeBSD dumping mechanism refinements. 2. Implement checksum on UDP packets. 3. Investigate the possibility to replace the custom protocol with tftp. 4. Investigate the possibility to replace the custom TCP/IPv4 stack with Contiki. 5. Implement network console and gdb backend using a shared debug context stack. 6. Add IPv6 support. __________________________________________________________________ OpenAFS Port URL: http://openafs.org URL: http://web.mit.edu/freebsd/openafs/openafs.shar Contact: Benjamin Kaduk Contact: Derrick Brashear AFS is a distributed network file system that originated from the Andrew Project at Carnegie-Mellon University; the OpenAFS client implementation has not been particularly useful on FreeBSD since the FreeBSD 4.X releases. The previous status report brought the OpenAFS client to a useful form on -CURRENT, though with many rough edges. Only a couple of those edges have been smoothed out during the past few months, as developer time was scarce. A mismatch between file size and vmobject size tracking was resolved (allowing executables to be run from AFS), and our system call entry has been updated on -CURRENT and 8-STABLE to match reality. Thanks to Kostik Belusov for both of those! The code is useful enough that we plan to submit an openafs-devel port to the Ports Collection in the coming cycle. There are several known outstanding issues that are being worked on, but detailed bug reports are welcome at port-freebsd@openafs.org. Open tasks: 1. Rework vnode locking for lookup operations to avoid an easily-triggered deadlock between two threads when one is looking up the parent directory. 2. Update VFS locking to allow the use of disk-based client caches as well as memory-based caches. 3. Track down races and deadlocks that appear under load. 4. Integrate with the bsd.kmod.mk kernel-module build infrastructure. __________________________________________________________________ Packet Capturing Stack -- ringmap URL: http://code.google.com/p/ringmap/ URL: http://ringmap.googlecode.com/files/ringmap_slides.pdf URL: http://wiki.FreeBSD.org/AlexandreFiveg Contact: Alexander Fiveg Ringmap is a complete FreeBSD packet capturing stack specialized for very high-speed networks. The goal of this project is to develop the software for efficient packet capturing and integrate it with the generic network drivers and libpcap. Current Status: * Integrated with the lem driver. Intel network controllers: 8254X are supported. * Packet filtering using BPF in both kernel and user space. * Partly integrated with ixgbe driver for 10Gb capturing. Open tasks: 1. Support for hardware timestamping. 2. Writing packets to the disc from within the kernel. 3. Multiqueue support. 4. Extending the "ringmap" for packet transmission. __________________________________________________________________ PC-BSD URL: http://www.pcbsd.org URL: http://trac.pcbsd.org/browser/pcbsd/current/ Contact: Kris Moore Work is progressing quickly on a major re-factoring of PC-BSD tools and the PBI format for 9.0. Our GUI tools have been converted to compile / run within native QT without KDE now, allowing us to begin offering support for other desktop environments for 9.0, such as Gnome, XFCE, LXDE, KDE, etc. The PBI format has undergone a complete evolution, and is now entirely command-line based for all aspects of it, with only a few dependencies upon curl & xdg-utils. This will allow us to begin offering PBIs for traditional FreeBSD users starting with 9.0, who will be able to install the pbi-manager from ports in the near future. Open tasks: 1. We are still busy converting / fixing all our tools to play nicely with various DE's, but making quick progress. 2. The new PBI format is still undergoing extensive testing, and bugs are being isolated and fixed. __________________________________________________________________ pc-sysinstall URL: http://it.toolbox.com/blogs/bsd-guru/eurobsdcon-presentation-on-pcsysin stall-41831 Contact: Kris Moore Contact: John Hixson Contact: Josh Paetzel pc-sysinstall was imported into CURRENT recently. For the moment it is feature complete, although progress on the text front end for it may expose additional functionality it needs. Open tasks: 1. The automated/scripted install features of pc-sysinstall need wider testing and use to expose potential weaknesses, bugs, and additional features it may require. 2. Related tasks include getting a text front-end to pc-sysinstall working and hooking up pc-sysinstall to the build so install media is generated that runs pc-sysinstall. __________________________________________________________________ pkg_upgrade (sysutils/bsdadminscripts) URL: http://sf.net/projects/bsdadminscripts URL: http://sf.net/projects/bsdadminscripts/files/publications/2010-10-eurob sdcon/ Contact: Dominic Fandrey pkg_upgrade was (to my knowledge) the first binary packages only update tool for the FreeBSD ports. Using it does not require a copy of the ports tree. Currently the tool is in the final stages of a recode, that will greatly improve support for sharing packages over NFS or nullfs mounts (e.g. for distributing packages into jails) and also offers improved dependency tracking and performance, more in line with how pointyhat and Tinderbox build packages. I recently had the opportunity to present my work at the EuroBSDCon 2010. Open tasks: 1. Complete session code. 2. Add INDEX generator script that harvests information directly from packages and hence is always accurate. 3. Testing. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/group.php?gid=135441496471197 URL: http://tinderbox.marcuscom.com/ Contact: Thomas Abthorpe Contact: Port Management Team The ports tree count now exceeds 22,000. With the assistance of many people, especially Philip Gollucci, the open PR count is below 1000 for the first time in quite a while. This is very encouraging progress. Since the last report, we added five new committers, and took in two commit bits for safe keeping. With onsite assistance from jhb@, gnn@, skreuzer@, and pgollucci@, we now have 11 new servers at NYI. The machines still need testing for stability and will soon be assigned for package building. The Ports Management team have been running -exp runs on an on-going basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * des: test libfetch * gabor: tests for BSD iconv and grep * mezz: switch www/neon28 to www/neon29 * beat: update www/libxul * johans: update devel/bison and devel/m4 * dinoex: update graphics/tiff * jpaetzel: update devel/popt * ade: multiple runs autotools upgrade * gerald: setting USE_GCC=4.5 as default * ashish: changes to Mk/bsd.license.mk * kwm: test of Clang in -CURRENT Open tasks: 1. Looking for help fixing ports broken on -CURRENT. 2. Looking for help with Tier-2 architectures. 3. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ Ports Distfile and WWW Checker URL: http://people.FreeBSD.org/~ehaupt/distilator/ Contact: Emanuel Haupt Given the current status of fenner's Distfiles Survey, a new distfile checker was written in order to have an overview for the state of each distfile in the ports tree. The distfile checker is also able to verify WWW entries in pkg-descr files. This is an attempt to weed out broken MASTER_SITES and outdated WWW entries. The current version uses a MySQL database backend and is able to verify 432512 distfiles (30 concurrent threads) within 24 hours. Open tasks: 1. Provide JavaScript to sort/filter/search tables. __________________________________________________________________ Registration of Optional Kernel Subsystems via sysctl URL: http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/fr eebsd/t127230759508 URL: http://wiki.FreeBSD.org/201010DevSummit?action=AttachFile&do=view&targe t=kibab_sysctlreg.pdf Contact: Ilya Bakulin All work is now in Perforce. Rich set of features is added to the kernel, userland tools and libc modifications are ready, documentation is ready. Open tasks: 1. Documentation review. 2. Presentation of feature set on the various mailing lists. 3. Committing to -CURRENT, possibly merging to stable branches (changes do not break ABI/KBI). __________________________________________________________________ Resource Containers Contact: Edward Tomasz Napierala The goal of this project is to implement resource containers and a simple per-jail resource limits mechanism. Resource containers are also a prerequisite for other resource management mechanisms, such as Hierarchical Resource Limits, for "Collective Limits on Set of Processes (aka. Jobs)" Google Summer of Code 2010 project, for implementing mechanism similar to Linux cgroups, and might be also used to e.g. provide precise resource usage accounting for administrative or billing purposes. So far, a generic resource usage framework has been developed, along with limit enforcement for most resources. Work is on-going on adding limits for remaining resources, debugging and generally improving the implementation. This project is being sponsored by The FreeBSD Foundation. __________________________________________________________________ Syncing pf(4) with OpenBSD 4.5 URL: http://svn.FreeBSD.org/viewvc/base/user/eri/pf45/ URL: http://svn.FreeBSD.org/base/user/eri/pf45/head/ URL: http://lists.FreeBSD.org/pipermail/freebsd-pf/2010-October/005842.html Contact: Ermal Luçi This work is based on OpenBSD 4.5 state of pf(4). It includes many improvements over the code currently present in FreeBSD. The actual new feature present in pf45 repository is support for divert(4), which should allow tools like snort_inline to work with pf(4) too. This work also enables pfsync(4) to be loaded as a module as well. Currently, this work is considered stable and a patch against -CURRENT has been released on freebsd-pf mailing list. The reason why this work is based off of OpenBSD 4.5 is that after this release they have changed the syntax which is not backwards compatible. After importing this one the work will go on the newest version and decisions on it will then be done. Open tasks: 1. Make a decision whether we need pflow(4) in base. 2. More regression testing is needed. __________________________________________________________________ Target Big Endian Must Die Contact: Warner Losh The "tbemd" or Target Big Endian Must Die effort is nearing completion. Most of the big sweeping changes to the tree have been committed. The last change, actually pulling the switch, is stalled waiting for make universe improvements. This work will change the TARGET_ARCH from a plain 'mips' to 'mipsel' or 'mipseb' based on which endian the platform has. It introduces the concept of multiple architectures being implemented with one set of files, and regularizes that design pattern into the FreeBSD build process. In the past, you had to set TARGET_BIG_ENDIAN=t to compile for big endian, but that had a number of problems: can not share /usr/obj between little and big endian targets, sometimes the produced compilers will not work right unless TARGET_BIG_ENDIAN is defined in the environment, etc. Open tasks: 1. Update make universe to cope with the new architectures when building kernels. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org Contact: Deb Goodkin We were proud to be a sponsor for MeetBSD 2010 Poland and KyivBSD 2010 in Kiev, Ukraine. We also committed to sponsoring BSDDay Argentina 2010, MeetBSD California 2010, and NYBSDCon 2010 all in November. The Foundation was also represented at MeetBSD Poland and Ohio LinuxFest. Completed the Foundation funded projects: "FreeBSD Jail-Based Virtualization" by Bjoern Zeeb and "DTrace Userland" by Rui Paulo. We kicked off a new project by Swinburne University called "Five New TCP Congestion Control Algorithms for FreeBSD". We continued our work on infrastructure projects to beef up hardware for package-building, network-testing, etc. This includes purchasing equipment as well as managing equipment donations. We are three quarters of the way through the year and we have raised around $160,000 towards our goal of $350,000. Find out how to make a donation at http://www.FreeBSDFoundation.org/donate/ Stop by and visit with us at MeetBSD California (Nov 5-6), LISA (Nov 10-11), and NYCBSDCon (Nov 12-14). __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de Contact: Johann Kois Contact: Benedict Reuschling The committers to the German Documentation Project were mostly trying to keep the documents and the website translations in sync with the ones on FreeBSD.org. Fabian Ruch was helpful in catching up with the changes to the Porters Handbook. Benedict translated the Solid State article into German because this is becoming a good addition to traditional hard drive storage. We tried to re-activate committers who did not contribute for some time but most of them are currently unable to free up enough time. We hope to gain fresh contributor blood as we are getting occasional reports about bugs and grammar in the German translation. Open tasks: 1. Submit grammar, spelling or other errors you find in the German documents and the website. 2. Translate more articles and other open handbook sections. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki The www/ja and doc/ja_JP.eucJP/ have been updated constantly since the last status report. We committed a big patch for the "Installing FreeBSD" chapter of the FreeBSD Handbook which was contributed by many people since a long time. This chapter is still outdated and needs more work. Some progress was made in the Porter's Handbook as well. Open tasks: 1. Further translation of the FreeBSD Handbook and contents of the www.FreeBSD.org site to the Japanese language. 2. Pre-/post-commit review of the translation. __________________________________________________________________ Updating Base Tools to Accommodate Ports Requirements Contact: Gordon Tetlow The goal of the project is to allow easier extension of base system tools by the ports system. Ideally, no files in /etc should need to be modified by a port installation. The man toolset was recently reimplemented as a BSDL version instead of the old GPL version. It is also a single shell script instead of multiple C programs. Ports can extend the man functionality by dropping files into /usr/local/etc/man.d/portname.conf. Next up on the list is to finish the implementation for newsyslog thereby allowing ports that need logs rotated to take advantage of that tool. __________________________________________________________________ USB Stack URL: http://svn.FreeBSD.org/viewvc/base/head/sys/dev/usb/controller/xhci.c?v iew=log Contact: Hans Petter Selasky During the last two months the USB stack in -CURRENT has been enhanced to support USB 3.0 and the XHCI USB 3.0 chipset from Intel. The XHCI chip will eventually replace the EHCI, OHCI and UHCI chips. Open tasks: 1. FreeBSD testers which have access to USB 3.0 hardware are wanted. __________________________________________________________________ Userland DTrace URL: http://wiki.FreeBSD.org/DTrace/userland Contact: Rui Paulo Userland DTrace support was a FreeBSD Foundation sponsored project that was developed during this summer. The project aimed to bring the userland DTracing functionality to FreeBSD as it is available on OpenSolaris. FreeBSD now supports the pid provider and the usdt probes. plockstat is available with a separate patch. Dtruss, a DTrace script that works similarly to ktrace, but with other advantages was imported into FreeBSD. The mysql-server and postgresql-server ports also have DTrace support. __________________________________________________________________ V4L Support in Linux Emulator URL: http://opal.com/freebsd/sys/compat/linux/ Contact: J.R. Oldroyd The V4L support in the Linux emulator has been merged to 8-STABLE allowing use of video in Skype calls using a camera supported by the pwcbsd or video4bsd drivers. A known issue for Skype is that your camera must support YUV420 mode which is what Skype uses. Note that V4L2 support is not included in the current work, and remains as a project for anyone interested. __________________________________________________________________ Valgrind Port URL: http://wiki.freebsd.org/Valgrind URL: http://bitbucket.org/stass/valgrind-freebsd/overview URL: https://bugs.kde.org/show_bug.cgi?id=208531 Contact: Stanislav Sedov Contact: Ed Maste Valgrind is a tool for detecting memory management and threading bugs, and profiling. Version 3.6.0 has recently been released and the FreeBSD port has now been updated. Development of the Valgrind port has moved from Perforce to bitbucket.org, in order to make it easier for others to track changes as we progress towards getting the port into shape to commit upstream. The repository's Bitbucket address is at the beginning of the report. A bugzilla entry has been submitted to track the FreeBSD Valgrind port. You can see the status and vote for the bug to express your interest at https://bugs.kde.org/show_bug.cgi?id=208531. Open tasks: 1. Port exp-ptrcheck valgrind tool and fix outstanding issues that show up in memcheck/helgrind/DRD in the Valgrind regression tests suite. 2. More testing (please, help). 3. Integrate our patches upstream. __________________________________________________________________ Web Feeds for UPDATING Files URL: http://updating.versia.com/ Contact: Alexander Kojevnikov updating.versia.com features web feeds for UPDATING files from ports, head, stable/7 and stable/8. These feeds provide an easy way to track important changes in the ports tree and the base system. __________________________________________________________________ xz Compression for Packages and Log Files Contact: Martin Matuska Support for xz compression has been enabled in bsdtar (-CURRENT 8-STABLE) and added to pkg_create(1) and pkg_add(1) (-CURRRENT). Packages with the .txz suffix can be created and installed. Log file compression using xz in newsyslog(8) will be integrated soon. Benchmarks show 15-30% better compression ratios and up to halved decompression times when compared to bzip2. A switch from the default package format from .tbz to .txz is to be considered. Open tasks: 1. Test building all FreeBSD packages with xz compression. __________________________________________________________________ ZFSv28 is Ready for Wider Testing URL: http://lists.FreeBSD.org/pipermail/freebsd-fs/2010-August/009197.html Contact: Pawel Jakub Dawidek ZFS v28 which includes data deduplication and plenty of other shiny new features is ready for testing. For more information check out the announcement. __________________________________________________________________ (c) 1995-2010 The FreeBSD Project. All rights reserved. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 01:04:20 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A234D1065679; Wed, 27 Oct 2010 01:04:20 +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 538EB8FC08; Wed, 27 Oct 2010 01:04:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o9R14JuQ081549; Tue, 26 Oct 2010 21:04:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9R14J4I081548; Wed, 27 Oct 2010 01:04:19 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Oct 2010 01:04:19 GMT Message-Id: <201010270104.o9R14J4I081548@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 , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 01:04:20 -0000 TB --- 2010-10-26 21:04:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-26 21:04:04 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-10-26 21:04:04 - cleaning the object tree TB --- 2010-10-26 21:06:16 - cvsupping the source tree TB --- 2010-10-26 21:06:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-10-26 21:11:03 - building world TB --- 2010-10-26 21:11:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-26 21:11:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-26 21:11:03 - TARGET=sparc64 TB --- 2010-10-26 21:11:03 - TARGET_ARCH=sparc64 TB --- 2010-10-26 21:11:03 - TZ=UTC TB --- 2010-10-26 21:11:03 - __MAKE_CONF=/dev/null TB --- 2010-10-26 21:11:03 - cd /src TB --- 2010-10-26 21:11:03 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 26 21:11:04 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Oct 27 00:39:02 UTC 2010 TB --- 2010-10-27 00:39:03 - generating LINT kernel config TB --- 2010-10-27 00:39:03 - cd /src/sys/sparc64/conf TB --- 2010-10-27 00:39:03 - /usr/bin/make -B LINT TB --- 2010-10-27 00:39:03 - building LINT kernel TB --- 2010-10-27 00:39:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-27 00:39:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-27 00:39:03 - TARGET=sparc64 TB --- 2010-10-27 00:39:03 - TARGET_ARCH=sparc64 TB --- 2010-10-27 00:39:03 - TZ=UTC TB --- 2010-10-27 00:39:03 - __MAKE_CONF=/dev/null TB --- 2010-10-27 00:39:03 - cd /src TB --- 2010-10-27 00:39:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 27 00:39:03 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f @/tools/makeobjops.awk @/dev/mii/miibus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sparc64/src/sys/LINT /src/sys/modules/wb/../../dev/wb/if_wb.c ===> wlan (depend) @ -> /src/sys machine -> /src/sys/sparc64/include make: don't know how to make ieee80211_ratectl_none.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-27 01:04:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-27 01:04:19 - ERROR: failed to build lint kernel TB --- 2010-10-27 01:04:19 - 2792.73 user 10470.55 system 14414.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 07:44:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94A1C106564A for ; Wed, 27 Oct 2010 07:44:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 434448FC19 for ; Wed, 27 Oct 2010 07:44:03 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id Pjk41f0021swQuc58jk4eu; Wed, 27 Oct 2010 07:44:04 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.westchester.pa.mail.comcast.net with comcast id Pjk31f0093LrwQ23bjk3kY; Wed, 27 Oct 2010 07:44:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0AC1D9B425; Wed, 27 Oct 2010 00:44:02 -0700 (PDT) Date: Wed, 27 Oct 2010 00:44:02 -0700 From: Jeremy Chadwick To: pjd@freebsd.org Message-ID: <20101027074401.GA18014@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 07:44:04 -0000 The below commit has broken the ability to build system boot blocks (including pxeldr) the "historic way"[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): ======================================== # rm -fr /usr/obj/* # cd /sys/boot # make clean [...] # make [...] cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. ======================================== Please advise. If there is a new/correct method, then I'd like to know what it is, in addition to the Handbook needing to be updated. [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html (See Section 26.6.5.2) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 08:09:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C1AB1065673 for ; Wed, 27 Oct 2010 08:09:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id BFD108FC0A for ; Wed, 27 Oct 2010 08:09:01 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2556D45E82; Wed, 27 Oct 2010 10:09:00 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8840D456B1; Wed, 27 Oct 2010 10:08:52 +0200 (CEST) Date: Wed, 27 Oct 2010 10:08:17 +0200 From: Pawel Jakub Dawidek To: Jeremy Chadwick Message-ID: <20101027080817.GC1848@garage.freebsd.pl> References: <20101027074401.GA18014@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctP54qlpMx3WjD+/" Content-Disposition: inline In-Reply-To: <20101027074401.GA18014@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 08:09:02 -0000 --ctP54qlpMx3WjD+/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote: > The below commit has broken the ability to build system boot blocks > (including pxeldr) the "historic way"[1]: >=20 > http://freshbsd.org/2010/10/17/20/10/00 >=20 > The breakage on RELENG_8 (dated as of a few minutes ago): >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > # rm -fr /usr/obj/* > # cd /sys/boot > # make clean > [...] > # make > [...] > cc -DBOOTPROG=3D\"gptboot\" -Os -fno-guess-branch-probability -fomit-f= rame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx= -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT= =3D0x3f8 -DSIOFMT=3D0x3 -DSIOSPD=3D9600 -I/usr/src/sys/boot/i386/gptboot= /../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/b= oot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 = -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-decla= rations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Ws= trict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single= =3D100 -ffreestanding -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -= mno-sse -mno-sse2 -mno-sse3 -m32 -march=3Di386 -std=3Dgnu99 -c /usr/src/s= ys/boot/i386/gptboot/../../common/gpt.c > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_AT= TR_BOOTME' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undec= lared identifier is reported only once > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each fu= nction it appears in.) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_AT= TR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfa= iled': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_AT= TR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_AT= TR_BOOTFAILED' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootco= nv': > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_AT= TR_BOOTME' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_AT= TR_BOOTONCE' undeclared (first use in this function) > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_AT= TR_BOOTFAILED' undeclared (first use in this function) > *** Error code 1 >=20 > Stop in /usr/src/sys/boot/i386/gptboot. > *** Error code 1 >=20 > Stop in /usr/src/sys/boot/i386. > *** Error code 1 >=20 > Stop in /usr/src/sys/boot. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Please advise. If there is a new/correct method, then I'd like to know > what it is, in addition to the Handbook needing to be updated. >=20 > [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html > (See Section 26.6.5.2) Well, your problem is that gptboot.c is including gpt.h not from your source tree, but from /usr/include/sys/, which has an old version of this header file. This can be easly fixed by extending CFLAGS in one of the Makefiles (which is already done in HEAD), but I'm afraid this procedure is incorrect (and never was correct). Apart from including wrong files it also links to wrong libraries, etc. The proper way is to: # cd /usr/src # make buildenv # cd sys/boot # make clean && make && make install --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ctP54qlpMx3WjD+/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzH3fAACgkQForvXbEpPzTRwACghgKgz6hNhG7JEBj98vZxoSTR xsUAnj5j+suzPxx6bP2kgYKD6KFPbN9X =OtoJ -----END PGP SIGNATURE----- --ctP54qlpMx3WjD+/-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 09:17:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 112281065673 for ; Wed, 27 Oct 2010 09:17:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id E9C388FC0C for ; Wed, 27 Oct 2010 09:17:28 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta14.emeryville.ca.mail.comcast.net with comcast id PlCN1f0011Y3wxoAElHU44; Wed, 27 Oct 2010 09:17:28 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.emeryville.ca.mail.comcast.net with comcast id PlHT1f0023LrwQ28blHTWd; Wed, 27 Oct 2010 09:17:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 673829B425; Wed, 27 Oct 2010 02:17:27 -0700 (PDT) Date: Wed, 27 Oct 2010 02:17:27 -0700 From: Jeremy Chadwick To: Pawel Jakub Dawidek Message-ID: <20101027091727.GA44893@icarus.home.lan> References: <20101027074401.GA18014@icarus.home.lan> <20101027080817.GC1848@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101027080817.GC1848@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 09:17:29 -0000 On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote: > On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote: > > The below commit has broken the ability to build system boot blocks > > (including pxeldr) the "historic way"[1]: > > > > http://freshbsd.org/2010/10/17/20/10/00 > > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > > ======================================== > > # rm -fr /usr/obj/* > > # cd /sys/boot > > # make clean > > [...] > > # make > > [...] > > cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) > > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) > > *** Error code 1 > > > > Stop in /usr/src/sys/boot/i386/gptboot. > > *** Error code 1 > > > > Stop in /usr/src/sys/boot/i386. > > *** Error code 1 > > > > Stop in /usr/src/sys/boot. > > ======================================== > > > > Please advise. If there is a new/correct method, then I'd like to know > > what it is, in addition to the Handbook needing to be updated. > > > > [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html > > (See Section 26.6.5.2) > > Well, your problem is that gptboot.c is including gpt.h not from your > source tree, but from /usr/include/sys/, which has an old version of > this header file. This can be easly fixed by extending CFLAGS in one of > the Makefiles (which is already done in HEAD), but I'm afraid this > procedure is incorrect (and never was correct). Apart from including > wrong files it also links to wrong libraries, etc. > > The proper way is to: > > # cd /usr/src > # make buildenv > # cd sys/boot > # make clean && make && make install Thanks for the tip -- the CFLAGS change in a Makefile sounds like the solution, since the latter (re: "proper way") didn't work (exact same problem). The Makefile adjustment you mention for HEAD is here: http://freshbsd.org/2010/10/08/10/27/52 But there's no mention of an MFC date in the commit message. Can this be MFC'd? For now, "make buildworld" works as a workaround (pull the bootstrap binaries needed out of /usr/obj). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 09:47:19 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0CB8106564A; Wed, 27 Oct 2010 09:47:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D83258FC14; Wed, 27 Oct 2010 09:47:18 +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 MAA19108; Wed, 27 Oct 2010 12:47:12 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CC7F520.10300@icyb.net.ua> Date: Wed, 27 Oct 2010 12:47:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Jeremy Chadwick References: <20101027074401.GA18014@icarus.home.lan> <20101027080817.GC1848@garage.freebsd.pl> <20101027091727.GA44893@icarus.home.lan> In-Reply-To: <20101027091727.GA44893@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Pawel Jakub Dawidek , freebsd-arch@FreeBSD.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 09:47:19 -0000 on 27/10/2010 12:17 Jeremy Chadwick said the following: > On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote: >> The proper way is to: >> >> # cd /usr/src >> # make buildenv >> # cd sys/boot >> # make clean && make && make install > > Thanks for the tip -- the CFLAGS change in a Makefile sounds like the > solution, since the latter (re: "proper way") didn't work (exact same > problem). The above will work if you already have the toolchain built - that's the only way to ensure that you don't depend on anything in the currently installed world. See build(7). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 13:28:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8473F1065758; Wed, 27 Oct 2010 13:28:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 52F7A8FC1B; Wed, 27 Oct 2010 13:28:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EE48D46B09; Wed, 27 Oct 2010 09:28:01 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D2B418A027; Wed, 27 Oct 2010 09:28:00 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 27 Oct 2010 09:27:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101027074401.GA18014@icarus.home.lan> In-Reply-To: <20101027074401.GA18014@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010270927.04145.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Oct 2010 09:28:00 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: pjd@freebsd.org, Jeremy Chadwick , freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:28:02 -0000 On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > The below commit has broken the ability to build system boot blocks > (including pxeldr) the "historic way"[1]: > > http://freshbsd.org/2010/10/17/20/10/00 > > The breakage on RELENG_8 (dated as of a few minutes ago): > > ======================================== > # rm -fr /usr/obj/* > # cd /sys/boot > # make clean This only works if your source tree is in sync with your installed world. Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested will work for the case that your source tree does not match your installed world. Maybe you could add text to the handbook to say this, but it is already implicitly assumed in the handbook section you are referring to since it assumes you can safely compile a new kernel, etc. The handbook section is meant as more of a tutorial on how to enable a serial console on a fresh box. Once you are experienced enough to start using buildworld, etc. I don't think it is unreasonable to require users to understand that having a source tree different from the installed world requires extra steps. If we were to document those every time it would clutter documentation making it harder for someone who is new to FreeBSD to simply setup a serial console on a box that they just installed. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 13:49:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86F281065696 for ; Wed, 27 Oct 2010 13:49:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3242E8FC26 for ; Wed, 27 Oct 2010 13:49:00 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id PnmL1f0061c6gX85Bpp1UZ; Wed, 27 Oct 2010 13:49:01 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta23.westchester.pa.mail.comcast.net with comcast id Ppoz1f00G3LrwQ23jpp0rQ; Wed, 27 Oct 2010 13:49:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 62AD79B425; Wed, 27 Oct 2010 06:48:58 -0700 (PDT) Date: Wed, 27 Oct 2010 06:48:58 -0700 From: Jeremy Chadwick To: John Baldwin Message-ID: <20101027134858.GA14454@icarus.home.lan> References: <20101027074401.GA18014@icarus.home.lan> <201010270927.04145.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010270927.04145.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pjd@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:49:01 -0000 On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: > On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > > The below commit has broken the ability to build system boot blocks > > (including pxeldr) the "historic way"[1]: > > > > http://freshbsd.org/2010/10/17/20/10/00 > > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > > > ======================================== > > # rm -fr /usr/obj/* > > # cd /sys/boot > > # make clean > > This only works if your source tree is in sync with your installed world. > Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested > will work for the case that your source tree does not match your installed > world. But this doesn't appear to be the case here: $ uname -a FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 PDT 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 $ sudo -i icarus# rm -fr /usr/obj/* rm: No match. icarus# cd /usr/src icarus# make buildenv Entering world for amd64:amd64 # make clean && make [...] cc -DBOOTPROG=\"gptboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. # ls -l /usr/src/sys/boot/i386/gptboot/../../common/gpt.c -rw-r--r-- 1 root wheel 10927 Oct 17 13:10 /usr/src/sys/boot/i386/gptboot/../../common/gpt.c Any ideas? > Maybe you could add text to the handbook to say this, but it is already > implicitly assumed in the handbook section you are referring to since it > assumes you can safely compile a new kernel, etc. The handbook section is > meant as more of a tutorial on how to enable a serial console on a fresh box. > Once you are experienced enough to start using buildworld, etc. I don't think > it is unreasonable to require users to understand that having a source tree > different from the installed world requires extra steps. I don't think it's unreasonable either, it's just not well-documented or well-established. For example, this is the first time I've heard of "buildenv", not to mention the other pieces mentioned in build(7). That doesn't mean FreeBSD is at fault, it just means there's been changes to things which are hard to keep up to date on. > If we were to document those every time it would clutter documentation > making it harder for someone who is new to FreeBSD to simply setup a > serial console on a box that they just installed. Understood. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 13:58:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6132C106566B; Wed, 27 Oct 2010 13:58:35 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 081128FC20; Wed, 27 Oct 2010 13:58:34 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D10EB45C98; Wed, 27 Oct 2010 15:58:32 +0200 (CEST) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0947C45683; Wed, 27 Oct 2010 15:58:27 +0200 (CEST) Date: Wed, 27 Oct 2010 15:57:53 +0200 From: Pawel Jakub Dawidek To: Jeremy Chadwick Message-ID: <20101027135753.GB2038@garage.freebsd.pl> References: <20101027074401.GA18014@icarus.home.lan> <201010270927.04145.jhb@freebsd.org> <20101027134858.GA14454@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: <20101027134858.GA14454@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org, John Baldwin , freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:58:37 -0000 --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 06:48:58AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: > > On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: > > > The below commit has broken the ability to build system boot blocks > > > (including pxeldr) the "historic way"[1]: > > >=20 > > > http://freshbsd.org/2010/10/17/20/10/00 > > >=20 > > > The breakage on RELENG_8 (dated as of a few minutes ago): > > >=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > # rm -fr /usr/obj/* > > > # cd /sys/boot > > > # make clean > >=20 > > This only works if your source tree is in sync with your installed worl= d. =20 > > Adding a hack to the Makefile is wrong. The buildenv approach pjd@ sug= gested=20 > > will work for the case that your source tree does not match your instal= led=20 > > world. >=20 > But this doesn't appear to be the case here: [...] Because you don't have toolchain built. Once you buildworld you can do that. All in all, the safest and most recommended way is to just use buildworld/buildkernel. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzIL+EACgkQForvXbEpPzTX3wCdHbpr7NRw1naIUBrVhbnUVvYh okwAoKYdSg5Cew8OGUfQgMMI37H94R/6 =P3Qy -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 18:25:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91F651065675; Wed, 27 Oct 2010 18:25:22 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4DCEF8FC0C; Wed, 27 Oct 2010 18:25:22 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 474091FFC5B; Wed, 27 Oct 2010 18:25:21 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2060084507; Wed, 27 Oct 2010 20:25:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jeremy Chadwick References: <20101027074401.GA18014@icarus.home.lan> <201010270927.04145.jhb@freebsd.org> <20101027134858.GA14454@icarus.home.lan> Date: Wed, 27 Oct 2010 20:25:21 +0200 In-Reply-To: <20101027134858.GA14454@icarus.home.lan> (Jeremy Chadwick's message of "Wed, 27 Oct 2010 06:48:58 -0700") Message-ID: <86tyk7xzla.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, pjd@freebsd.org, John Baldwin , freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:25:22 -0000 Jeremy Chadwick writes: > $ uname -a > FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:1= 0:54 PDT 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_= amd64 amd64 > $ sudo -i > icarus# rm -fr /usr/obj/* > rm: No match. > icarus# cd /usr/src icarus# make toolchain > icarus# make buildenv > Entering world for amd64:amd64 > # make clean && make > [...] FTFY. HTH, HAND! DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 19:05:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DA9C106564A; Wed, 27 Oct 2010 19:05:29 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 60C328FC15; Wed, 27 Oct 2010 19:05:27 +0000 (UTC) Received: by fxm17 with SMTP id 17so1084387fxm.13 for ; Wed, 27 Oct 2010 12:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=ed0T6D1gzKSh9p+SWKemgMI9kSpJ8aYVzOeKLKnnuQ4=; b=SYZtw0fUsYAmnWq3+Xn8Zh8RTcj61AeLYChwGIQdwwfw0Mc8ZUQYWy5b/ME4TZKJM+ yByYeqndkyOTM5wR21ckLTqkqQLStfqGwBh2y3OLw5WFksWHq7t+4r+naqbNe1YQTLPl YGfVGRaD/xtP/bM+y1KuZo1qCYvZXrtQhWri8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=VLcUJ0KbHX18r3VeEiaQxmqmVmsMfry54RnhPmqNGURpEkE6bui015mINLpNrmx9sM z+26rcA5yEkBW+Illhlsk4exnwAcmOx+9Oi3PfGYVLBz5KwpvEfwIuMDa43qufsqFRvM Dd43gkDFNfeEe2wf+bERD16PltgQt4GqyJWmY= Received: by 10.223.96.15 with SMTP id f15mr2735354fan.10.1288206327129; Wed, 27 Oct 2010 12:05:27 -0700 (PDT) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id b15sm69563fah.4.2010.10.27.12.05.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 12:05:25 -0700 (PDT) From: Mikolaj Golub To: Pete French References: X-Comment-To: Pete French Date: Wed, 27 Oct 2010 22:05:20 +0300 In-Reply-To: (Pete French's message of "Tue, 26 Oct 2010 17:01:01 +0100") Message-ID: <86wrp3wj67.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pawel Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:05:29 -0000 On Tue, 26 Oct 2010 17:01:01 +0100 Pete French wrote: PF> Actually, I just llooked I dmesg on the secondary - it is full PF> of messages thus: PF> Oct 26 15:44:59 serpentine-passive hastd[10394]: [serp0] (secondary) Unable to receive request header: RPC version wrong. PF> Oct 26 15:45:00 serpentine-passive hastd[782]: [serp0] (secondary) Worker process exited ungracefully (pid=10394, exitcode=75). PF> Oct 26 15:46:59 serpentine-passive hastd[10421]: [serp0] (secondary) Unable to receive request header: RPC version wrong. PF> Oct 26 15:47:04 serpentine-passive hastd[782]: [serp0] (secondary) Worker process exited ungracefully (pid=10421, exitcode=75). I saw this too but only sporadic messages so I forgot and did not investigate then this :-). Now running synchronization I see them too (but again only sporadic). Setting the assertion and looking at the received header: (gdb) list 309 goto fail; 310 311 if (hdr.version != HAST_PROTO_VERSION) { 312 assert(0); 313 errno = ERPCMISMATCH; 314 goto fail; 315 } 316 317 hdr.size = le32toh(hdr.size); 318 (gdb) p/x hdr $2 = {version = 0x9, size = 0x65657266} So it looks like garbage. In hast_proto_send() we send header and then data. Couldn't it be that remote_send and sync threads interfere and their packets are mixed? May be some synchronization is needed here? I set sleep(1) in hast_proto_send() between proto_send(header) and proto_send(data). The error started to occur frequently. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 19:47:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE4B0106566C for ; Wed, 27 Oct 2010 19:47:01 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id B4B2A8FC15 for ; Wed, 27 Oct 2010 19:47:01 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBBxc-000HDz-VT for stable@freebsd.org; Wed, 27 Oct 2010 19:47:01 +0000 Date: Thu, 28 Oct 2010 04:47:00 +0900 Message-ID: From: Randy Bush To: stable User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: beastiality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:47:01 -0000 on the serial console, i am seeing twirlies doubled, as in // and the beastie is very tortured +-----------------------------------------++=BF=C4-=C4-=C4-=C4-=C4-=C4-=C4= -=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4|=C4-=C4 = ||=B3 ||=B3 ||=B3 , , = ,, ||=B3 ,, ||=B3 /( = )` //(( ||=B3 Welcome to FreeBSD!oo FFrreeee|BSSDD!! = \ \___ / | \\ \\___||=B3 // || ||=B3= /- _ `-/ ' //-- __ ||=B3``--// '' = ||=B3 (/\/ \ \ /\((//\\// \||=B31. Boot FreeBSD [default]B= SSDD [[ddeef|aauulltt]] / / | ` \/ // ||=B32. Boot FreeBSD wit= h ACPI enabledwiitth| AACCPPII eennaab) / |/ |||=B33. Boot Free= BSD in Safe ModeDD iinn S|a `-^--'`< '`--^^----'||=B34. Bo= ot FreeBSD in single user moden s|i (_.) _ ) /ddee)) _||= =B35. Boot FreeBSD with verbose loggingtth| `.___/` / = ____/||=B36. Escape to loader promptllooaaddeerr |p `-----' / = ``-----||=B37. Rebootebboooott || <----. __ / = __ \ ____ // _||=B3 \\ || <----|=3D= =3D=3D=3DO)))=3D=3D) \) /=3D=3D=3D=3D|)))=3D=3D=3D=3D)||=B3\\)) //=3D=3D= =3D=3D=3D=3D=3D=3D|| || <----' `--' `.__,' \`----'' = ``.||=B3__,,'' \\ || | | = || ||=B3 || || \ = / /\ ||=B3Select option, [Enter] for defaultEnntt|e _= _____( (_ / \______/_(( ||=B3or [Space] to pause timer H--11 ussee| = ,' ,-----' | ,,---------+-----------------------------------------+= + `--{__________) -=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4_____)) =20 Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-STABLE #1: Sun Sep 5 12:04:21 GMT 2010 root@test.psg.com:/usr/obj/usr/src/sys/SPARE i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.67-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf27 Family =3D f Model =3D 2 Stepp= ing =3D 7 Features=3D0xbfebfbff Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 204B6106566B for ; Wed, 27 Oct 2010 20:03:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id D34308FC08 for ; Wed, 27 Oct 2010 20:03:11 +0000 (UTC) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta08.westchester.pa.mail.comcast.net with comcast id Pqfs1f0040QuhwU58w3CJN; Wed, 27 Oct 2010 20:03:12 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.westchester.pa.mail.comcast.net with comcast id Pw361f00Y3LrwQ23Nw37XU; Wed, 27 Oct 2010 20:03:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 50E439B425; Wed, 27 Oct 2010 13:03:05 -0700 (PDT) Date: Wed, 27 Oct 2010 13:03:05 -0700 From: Jeremy Chadwick To: Randy Bush Message-ID: <20101027200305.GA35927@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable Subject: Re: beastiality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:03:12 -0000 On Thu, Oct 28, 2010 at 04:47:00AM +0900, Randy Bush wrote: > on the serial console, i am seeing twirlies doubled, as in >=20 > // >=20 > and the beastie is very tortured >=20 > +-----------------------------------------++=BF=C4-=C4-=C4-=C4-=C4-=C4-= =C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4|=C4-=C4 = ||=B3 > ||=B3 ||=B3 , ,= ,, ||=B3 ,, ||=B3 /(= )` //(( ||=B3 Welcome to FreeBSD!oo FFrreeee|BSSDD!! = \ \___ / | \\ \\___||=B3 // || ||= =B3 /- _ `-/ ' //-- __ ||=B3``--// '' = ||=B3 (/\/ \ \ /\((//\\// \||=B31. Boot FreeBSD [defaul= t]BSSDD [[ddeef|aauulltt]] / / | ` \/ // ||=B32. Boot FreeBSD = with ACPI enabledwiitth| AACCPPII eennaab) / |/ |||=B33. Boot F= reeBSD in Safe ModeDD iinn S|a `-^--'`< '`--^^----'||=B34.= Boot FreeBSD in single user moden s|i (_.) _ ) /ddee)) _= ||=B35. Boot FreeBSD with verbose loggingtth| `.___/` / = ____/||=B36. Escape to loader promptllooaaddeerr |p `-----' = / ``-----||=B37. Rebootebboooott || <----. __ = / __ \ ____ // _||=B3 \\ || <----|= =3D=3D=3D=3DO)))=3D=3D) \) /=3D=3D=3D=3D|)))=3D=3D=3D=3D)||=B3\\)) //=3D= =3D=3D=3D=3D=3D=3D=3D|| || <----' `--' `.__,' \`----= '' ``.||=B3__,,'' \\ || | = | || ||=B3 || || = \ / /\ ||=B3Select option, [Enter] for defaultEnntt|e = ______( (_ / \______/_(( ||=B3or [Space] to pause timer H--11 ussee| = ,' ,-----' | ,,---------+---------------------------------------= --++ `--{__________) -=C4-=C4-=C4-=C4-=C4-=C4-=C4-=C4_____)) =20 > > [...] > spare.psg.com:/root# cat /boot/loader.conf.local > loader_logo=3Dbeastie > # > console=3D"comconsole vidconsole" > comconsole_speed=3D"9600" > # > ipfw_load=3DYES This is often caused by a combination of two things being enabled simultaneously: BIOS-level serial console redirection after POST, and FreeBSD's serial console support. Effectively, the system BIOS is "redirecting" VGA output to the serial port, while simultaneously FreeBSD is doing serial console. But I've seen different behaviour on different hardware over the years when the first option is enabled. - "Doubling of characters" like the above (but sometimes not doubled) - System hard locking (reset/power cycle required) the instant the boot loader tries to do serial (some of my Yahoo! colleagues can confirm this one, even when using RedHat) - System boots/runs fine but no serial output is visible past loader I have some older Supermicro systems which do even weirder things when the option is enabled, like lock up after loader. I've also see different behaviour on RELENG_7 than I do RELENG_8. Back to Supermicro systems -- the aforementioned feature is usually labelled as "Continue C.R. After POST" (C.R. stands for Console Redirection). This is not the same thing as disabling BIOS-level serial console entirely, just that the "Agent" (some sort of interrupt tie-in) isn't retained after POST. If your system offers the BIOS option, you can try turning it off and see if things improve. Be aware that you will lose the ability to access things like Option ROMs (SCSI BIOSes, Intel NIC PXE boot information, etc.). If your system doesn't offer that BIOS option, then possibly just leaving console as its default will suffice. --=20 | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 20:09:52 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25FF6106566C for ; Wed, 27 Oct 2010 20:09:52 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 0FFF88FC1B for ; Wed, 27 Oct 2010 20:09:52 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBCJj-000HHb-IO; Wed, 27 Oct 2010 20:09:51 +0000 Date: Thu, 28 Oct 2010 05:09:50 +0900 Message-ID: From: Randy Bush To: Jeremy Chadwick In-Reply-To: <20101027200305.GA35927@icarus.home.lan> References: <20101027200305.GA35927@icarus.home.lan> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: stable Subject: Re: beastiality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:09:52 -0000 > This is often caused by a combination of two things being enabled > simultaneously: BIOS-level serial console redirection after POST, and > FreeBSD's serial console support. bingo! thanks randy From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 20:51:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0C59106564A for ; Wed, 27 Oct 2010 20:51:32 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [95.108.130.120]) by mx1.freebsd.org (Postfix) with ESMTP id 6336E8FC16 for ; Wed, 27 Oct 2010 20:51:32 +0000 (UTC) Received: from web127.yandex.ru (web127.yandex.ru [95.108.130.105]) by forward13.mail.yandex.net (Yandex) with ESMTP id A6E4F1081564 for ; Thu, 28 Oct 2010 00:51:30 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1288212690; bh=UuP8VuC/UNPmk+rKIXvTJhtcRZfnxUKp7hGWzncJucM=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=XEPAC3sttmReUecDBOZgu97/kc+diMRxmWTghlqPZMOzGK969dfjeqNJCPvVRcFOa nbhkxEpPepEpNEaAaPbUKiztg6cJ1Da6dxy9+9K+MbwVZNxgVWolpKGfxTR0l8hVN6 qllWSpR5cGFkJNCyk3aPICP6cjFj46NABguch+MQ= Received: from localhost (localhost.localdomain [127.0.0.1]) by web127.yandex.ru (Yandex) with ESMTP id A03634D300A2 for ; Thu, 28 Oct 2010 00:51:30 +0400 (MSD) X-Yandex-Spam: 0 X-Yandex-Front: web127.yandex.ru X-Yandex-TimeMark: 1288212690 Received: from [188.134.22.116] ([188.134.22.116]) by mail.yandex.ru with HTTP; Thu, 28 Oct 2010 00:51:30 +0400 From: S.N.Grigoriev To: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-Id: <398231288212690@web127.yandex.ru> Date: Thu, 28 Oct 2010 00:51:30 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Subject: ZFS write speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:51:32 -0000 Hi list, I've got very low write speed using ZFS on a SATA disk. My HDD configuration is: ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s ad6: 78532MB at ata3-master UDMA100 SATA 1.5Gb/s ad8: 1430799MB at ata4-master UDMA100 SATA 3Gb/s ad4 and ad6 are single-slice disks (UFS2 with soft updates) ZFS configuration is following: zpool create Z ad8 zfs create Z/music zfs create Z/video All ZFS parameters are default. kern.maxvnodes = 1000000 To test my configuration I recursively copied from ad6 to ad8 two directories. The first one contains MP3 files (average size = 10MB). The second one contains AVI files (average size = 1GB). To compare performance I repeated above tests with ad8 using UFS2 with soft updates. 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. Any tips? -- Regards, Serguey. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 21:08:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F2E71065672 for ; Wed, 27 Oct 2010 21:08:52 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 085868FC1B for ; Wed, 27 Oct 2010 21:08:51 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PBDEo-0003og-F7 for freebsd-stable@freebsd.org; Wed, 27 Oct 2010 14:08:50 -0700 Message-ID: <30071221.post@talk.nabble.com> Date: Wed, 27 Oct 2010 14:08:50 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <29978939.post@talk.nabble.com> <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> <30056250.post@talk.nabble.com> Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 21:08:52 -0000 Sean C. Farley-2 wrote: > > For me, the solution appeared to be setting the grace time to three > seconds to avoid the slowdown of the drive: gracetime=3 > At least, the disc worked on subsequent burns this way. Jakub, you may > try to see if this setting helps. > No, gracetime doesn't help. Maybe Alexander Motin could shed some light on (ahci?) problem? thanks for assistance, Jakub Lach -- View this message in context: http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30071221.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 21:54:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0DB106564A for ; Wed, 27 Oct 2010 21:54:36 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 130408FC0A for ; Wed, 27 Oct 2010 21:54:36 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A366B8F19B; Wed, 27 Oct 2010 23:54:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <398231288212690@web127.yandex.ru> Date: Wed, 27 Oct 2010 23:54:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7FF9CDFF-3FA0-45EA-85F5-A236AEFC03C7@lassitu.de> References: <398231288212690@web127.yandex.ru> To: S.N.Grigoriev X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS write speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 21:54:36 -0000 Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: > Hi list, >=20 > I've got very low write speed using ZFS on a SATA disk. > My HDD configuration is: > ad4: 70911MB at ata2-master UDMA100 = SATA 3Gb/s > ad6: 78532MB at ata3-master UDMA100 = SATA 1.5Gb/s > ad8: 1430799MB at ata4-master UDMA100 = SATA 3Gb/s The EARS has 4k sectors, if I'm not mistaken. I don't recall the = eventual outcome, but there was a long thread on stable or hackers on = how to ensure proper alignment and (minimun) 4k-sized writes to make = sure the disk doesn't have to do a read-modify-write cycle, so try and = search the archives. > ad4 and ad6 are single-slice disks (UFS2 with soft updates) >=20 > ZFS configuration is following: > zpool create Z ad8 > zfs create Z/music > zfs create Z/video > All ZFS parameters are default. > kern.maxvnodes =3D 1000000 >=20 > To test my configuration I recursively copied from ad6 to ad8 two = directories. > The first one contains MP3 files (average size =3D 10MB). > The second one contains AVI files (average size =3D 1GB).=20 >=20 > To compare performance I repeated above tests with ad8 using UFS2 with = soft updates. >=20 > 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy = to ZFS. > 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy = to ZFS. >=20 > I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is = 6GB. >=20 > Any tips? >=20 > --=20 > Regards, > Serguey. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Wed Oct 27 23:22:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DC7C1065694 for ; Wed, 27 Oct 2010 23:22:37 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 1E83F8FC14 for ; Wed, 27 Oct 2010 23:22:36 +0000 (UTC) Received: by qyk7 with SMTP id 7so4177297qyk.13 for ; Wed, 27 Oct 2010 16:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=lERw/v1JPSEGVxe54atP9P8LIcUuz49HrVMqRmQbk2c=; b=I2IicXBspRncz8cbBWPmjId4pOK0L59jOYJNC3ose6ZRhrNJtmf025ZqKl6W6l6uKm 494zspjJq13lKlb9iG/qHkotpSIUoDcxqzLF8vG8ncZyEewzEJg7p+NYZhbS3vQHcEBz 7ajtf0y149sld14YvEb0irCpJHnxadUHa/pV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XttX34OCLaQupA2PrgeRrBitiV9QptknHPfz3qjZygkKxVcxMRPx2s1wXHpYgZCDRl nO7JEU7sYGF91C/tebwIdPMFti1Xxdg19q8sAMTHYwZbbHOb3QkqoT6v/H2ceKlZ3Efb woJtJ0cYyFngy6GuDFoVfVI9nOhyjN8yq69a4= MIME-Version: 1.0 Received: by 10.229.225.199 with SMTP id it7mr6579774qcb.33.1288221756022; Wed, 27 Oct 2010 16:22:36 -0700 (PDT) Received: by 10.229.89.138 with HTTP; Wed, 27 Oct 2010 16:22:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Oct 2010 16:22:35 -0700 Message-ID: From: Rumen Telbizov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 23:22:37 -0000 No ideas whatsoever? On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov wrote: > Hello everyone, > > After a few days of struggle with my degraded zpool on a backup server I > decided to ask for > help here or at least get some clues as to what might be wrong with it. > Here's the current state of the zpool: > > # zpool status > > pool: tank > state: DEGRADED > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank DEGRADED 0 0 0 > raidz1 DEGRADED 0 0 0 > spare DEGRADED 0 0 0 > replacing DEGRADED 0 0 0 > 17307041822177798519 UNAVAIL 0 299 0 was > /dev/gpt/disk-e1:s2 > gpt/newdisk-e1:s2 ONLINE 0 0 0 > gpt/disk-e2:s10 ONLINE 0 0 0 > gpt/disk-e1:s3 ONLINE 30 0 0 > gpt/disk-e1:s4 ONLINE 0 0 0 > gpt/disk-e1:s5 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e1:s6 ONLINE 0 0 0 > gpt/disk-e1:s7 ONLINE 0 0 0 > gpt/disk-e1:s8 ONLINE 0 0 0 > gpt/disk-e1:s9 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e1:s10 ONLINE 0 0 0 > gpt/disk-e1:s11 ONLINE 0 0 0 > gpt/disk-e1:s12 ONLINE 0 0 0 > gpt/disk-e1:s13 ONLINE 0 0 0 > raidz1 DEGRADED 0 0 0 > gpt/disk-e1:s14 ONLINE 0 0 0 > gpt/disk-e1:s15 ONLINE 0 0 0 > gpt/disk-e1:s16 ONLINE 0 0 0 > spare DEGRADED 0 0 0 > replacing DEGRADED 0 0 0 > 15258738282880603331 UNAVAIL 0 48 0 was > /dev/gpt/disk-e1:s17 > gpt/newdisk-e1:s17 ONLINE 0 0 0 > gpt/disk-e2:s11 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e1:s18 ONLINE 0 0 0 > gpt/disk-e1:s19 ONLINE 0 0 0 > gpt/disk-e1:s20 ONLINE 0 0 0 > gpt/disk-e1:s21 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e1:s22 ONLINE 0 0 0 > gpt/disk-e1:s23 ONLINE 0 0 0 > gpt/disk-e2:s0 ONLINE 0 0 0 > gpt/disk-e2:s1 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e2:s2 ONLINE 0 0 0 > gpt/disk-e2:s3 ONLINE 0 0 0 > gpt/disk-e2:s4 ONLINE 0 0 0 > gpt/disk-e2:s5 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk-e2:s6 ONLINE 0 0 0 > gpt/disk-e2:s7 ONLINE 0 0 0 > gpt/disk-e2:s8 ONLINE 0 0 0 > gpt/disk-e2:s9 ONLINE 0 0 0 > spares > gpt/disk-e2:s10 INUSE currently in use > gpt/disk-e2:s11 INUSE currently in use > gpt/disk-e1:s2 UNAVAIL cannot open > gpt/newdisk-e1:s17 INUSE currently in use > > errors: 4 data errors, use '-v' for a list > > > The problem is: after replacing the bad drives and resilvering the old/bad > drives cannot be detached. > The replace command didn't remove it automatically and manual detach fails. > Here are some examples: > > # zpool detach tank 15258738282880603331 > cannot detach 15258738282880603331: no valid replicas > # zpool detach tank gpt/disk-e2:s11 > cannot detach gpt/disk-e2:s11: no valid replicas > # zpool detach tank gpt/newdisk-e1:s17 > cannot detach gpt/newdisk-e1:s17: no valid replicas > # zpool detach tank gpt/disk-e1:s17 > cannot detach gpt/disk-e1:s17: no valid replicas > > > Here's more information and history of events. > This is a 36 disk SuperMicro 847 machine with 2T WD RE4 disks organized in > raidz1 groups as > depicted above. zpool deals only with partitions like those: > > => 34 3904294845 mfid30 GPT (1.8T) > 34 3903897600 1 disk-e2:s9 (1.8T) > 3903897634 397245 - free - (194M) > > mfidXX devices are disks connected to a SuperMicro/LSI controller and > presented as jbods. JBODs in this adapter > are actually constructed as raid0 array of 1 disk but this should be > irrelevant in this case. > > This machine was working fine since September 6th but two of the disks (in > different raidz1 vdevs) were going > pretty bad and accumulated quite a bit of errors until eventually they > died. This is how they looked like: > > raidz1 DEGRADED 0 0 0 > gpt/disk-e1:s2 UNAVAIL 44 59.5K 0 experienced I/O > failures > gpt/disk-e1:s3 ONLINE 0 0 0 > gpt/disk-e1:s4 ONLINE 0 0 0 > gpt/disk-e1:s5 ONLINE 0 0 0 > > raidz1 DEGRADED 0 0 0 > gpt/disk-e1:s14 ONLINE 0 0 0 > gpt/disk-e1:s15 ONLINE 0 0 0 > gpt/disk-e1:s16 ONLINE 0 0 0 > gpt/disk-e1:s17 UNAVAIL 1.56K 49.0K 0 experienced I/O > failures > > > I did have two spare disks ready to replace them. So after they died here's > what I executed: > > # zpool replace tank gpt/disk-e1:s2 gpt/disk-e2:s10 > # zpool replace tank gpt/disk-e1:s17 gpt/disk-e2:s11 > > Resilvering started. While in the middle of it though the kernel paniced > and I had to reboot the machine. > After reboot I waited until the resilvering is complete. Now that it was > complete I expected to see the old/bad > device removed from the vdev but it was still there. Trying detach was > complaining with no valid replicas. > I sent colo technician to replace both those defective drives with brand > new ones. Once I had them inserted > I recreated them exactly the same way as the ones that I had before - jbod > and gpart labeled partition with the > same name! Then I added them as spares: > > # zpool add tank spare gpt/disk-e1:s2 > # zpool add tank spare gpt/disk-e1:s17 > > That actually made it worse I think since now I had the same device name > both as a 'previous' failed device > inside the raidz1 group and as a hot spare spare device. I couldn't do > anything with it. > What I did was to export the pool fail the disk on the controller, import > the pool and check that zfs could open > it anymore (as a part of the hot spares). Then I recreated that > disk/partition with a new label 'newdisk-XXX' > and tried to replace the device that originally failed (and was only > presented with a number). So I did this: > > # zpool replace tank gpt/disk-e1:s17 gpt/newdisk-e1:s17 > # zpool replace tank gpt/disk-e1:s2 gpt/newdisk-e1:s2 > > Resilvering completed after 17 hours or so and I expected for the > 'replacing' operation to disappear and the > replaced device to go away. But it didn't! Instead I have the state of the > pool as shown in the beginning of > the email. > As for the 'errors: 4 data errors, use '-v' for a list' I suspect that > it's due another failing > device (gpt/disk-e1:s3) inside the first (currently degraded) raidz1 vdev. > Those 4 corrupted files actually > could be read sometimes so that tells me that the disk has trouble reading > *sometimes* those bad blocks. > > Here's the output of zdb -l tank > > version=14 > name='tank' > state=0 > txg=200225 > pool_guid=13504509992978610301 > hostid=409325918 > hostname='XXXX' > vdev_tree > type='root' > id=0 > guid=13504509992978610301 > children[0] > type='raidz' > id=0 > guid=3740854890192825394 > nparity=1 > metaslab_array=33 > metaslab_shift=36 > ashift=9 > asize=7995163410432 > is_log=0 > children[0] > type='spare' > id=0 > guid=16171901098004278313 > whole_disk=0 > children[0] > type='replacing' > id=0 > guid=2754550310390861576 > whole_disk=0 > children[0] > type='disk' > id=0 > guid=17307041822177798519 > path='/dev/gpt/disk-e1:s2' > whole_disk=0 > not_present=1 > DTL=246 > children[1] > type='disk' > id=1 > guid=1641394056824955485 > path='/dev/gpt/newdisk-e1:s2' > whole_disk=0 > DTL=55 > children[1] > type='disk' > id=1 > guid=13150356781300468512 > path='/dev/gpt/disk-e2:s10' > whole_disk=0 > is_spare=1 > DTL=1289 > children[1] > type='disk' > id=1 > guid=6047192237176807561 > path='/dev/gpt/disk-e1:s3' > whole_disk=0 > DTL=250 > children[2] > type='disk' > id=2 > guid=9178318500891071208 > path='/dev/gpt/disk-e1:s4' > whole_disk=0 > DTL=249 > children[3] > type='disk' > id=3 > guid=2567999855746767831 > path='/dev/gpt/disk-e1:s5' > whole_disk=0 > DTL=248 > children[1] > type='raidz' > id=1 > guid=17097047310177793733 > nparity=1 > metaslab_array=31 > metaslab_shift=36 > ashift=9 > asize=7995163410432 > is_log=0 > children[0] > type='disk' > id=0 > guid=14513380297393196654 > path='/dev/gpt/disk-e1:s6' > whole_disk=0 > DTL=266 > children[1] > type='disk' > id=1 > guid=7673391645329839273 > path='/dev/gpt/disk-e1:s7' > whole_disk=0 > DTL=265 > children[2] > type='disk' > id=2 > guid=15189132305590412134 > path='/dev/gpt/disk-e1:s8' > whole_disk=0 > DTL=264 > children[3] > type='disk' > id=3 > guid=17171875527714022076 > path='/dev/gpt/disk-e1:s9' > whole_disk=0 > DTL=263 > children[2] > type='raidz' > id=2 > guid=4551002265962803186 > nparity=1 > metaslab_array=30 > metaslab_shift=36 > ashift=9 > asize=7995163410432 > is_log=0 > children[0] > type='disk' > id=0 > guid=12104241519484712161 > path='/dev/gpt/disk-e1:s10' > whole_disk=0 > DTL=262 > children[1] > type='disk' > id=1 > guid=3950210349623142325 > path='/dev/gpt/disk-e1:s11' > whole_disk=0 > DTL=261 > children[2] > type='disk' > id=2 > guid=14559903955698640085 > path='/dev/gpt/disk-e1:s12' > whole_disk=0 > DTL=260 > children[3] > type='disk' > id=3 > guid=12364155114844220066 > path='/dev/gpt/disk-e1:s13' > whole_disk=0 > DTL=259 > children[3] > type='raidz' > id=3 > guid=12517231224568010294 > nparity=1 > metaslab_array=29 > metaslab_shift=36 > ashift=9 > asize=7995163410432 > is_log=0 > children[0] > type='disk' > id=0 > guid=7655789038925330983 > path='/dev/gpt/disk-e1:s14' > whole_disk=0 > DTL=258 > children[1] > type='disk' > id=1 > guid=17815755378968233141 > path='/dev/gpt/disk-e1:s15' > whole_disk=0 > DTL=257 > children[2] > type='disk' > id=2 > guid=9590421681925673767 > path='/dev/gpt/disk-e1:s16' > whole_disk=0 > DTL=256 > children[3] > type='spare' > id=3 > guid=4015417100051235398 > whole_disk=0 > children[0] > type='replacing' > id=0 > guid=11653429697330193176 > whole_disk=0 > children[0] > type='disk' > id=0 > guid=15258738282880603331 > path='/dev/gpt/disk-e1:s17' > whole_disk=0 > not_present=1 > DTL=255 > children[1] > type='disk' > id=1 > guid=908651380690954833 > path='/dev/gpt/newdisk-e1:s17' > whole_disk=0 > is_spare=1 > DTL=52 > children[1] > type='disk' > id=1 > guid=7250934196571906160 > path='/dev/gpt/disk-e2:s11' > whole_disk=0 > is_spare=1 > DTL=1292 > children[4] > type='raidz' > id=4 > guid=7622366288306613136 > nparity=1 > metaslab_array=28 > metaslab_shift=36 > ashift=9 > asize=7995163410432 > is_log=0 > children[0] > type='disk' > id=0 > guid=11283483106921343963 > path='/dev/gpt/disk-e1:s18' > whole_disk=0 > DTL=254 > children[1] > type='disk' > id=1 > guid=14900597968455968576 > path='/dev/gpt/disk-e1:s19' > whole_disk=0 > DTL=253 > children[2] > type='disk' > id=2 > guid=4140592611852504513 > path='/dev/gpt/disk-e1:s20' > whole_disk=0 > DTL=252 > children[3] > type='disk' > id=3 > guid=2794215380207576975 > path='/dev/gpt/disk-e1:s21' > whole_disk=0 > DTL=251 > children[5] > type='raidz' > id=5 > guid=17655293908271300889 > nparity=1 > metaslab_array=27 > metaslab_shift=36 > ashift=9 > asize=7995163410432 > is_log=0 > children[0] > type='disk' > id=0 > guid=5274146379037055039 > path='/dev/gpt/disk-e1:s22' > whole_disk=0 > DTL=278 > children[1] > type='disk' > id=1 > guid=8651755019404873686 > path='/dev/gpt/disk-e1:s23' > whole_disk=0 > DTL=277 > children[2] > type='disk' > id=2 > guid=16827379661759988976 > path='/dev/gpt/disk-e2:s0' > whole_disk=0 > DTL=276 > children[3] > type='disk' > id=3 > guid=2524967151333933972 > path='/dev/gpt/disk-e2:s1' > whole_disk=0 > DTL=275 > children[6] > type='raidz' > id=6 > guid=2413519694016115220 > nparity=1 > metaslab_array=26 > metaslab_shift=36 > ashift=9 > asize=7995163410432 > is_log=0 > children[0] > type='disk' > id=0 > guid=16361968944335143412 > path='/dev/gpt/disk-e2:s2' > whole_disk=0 > DTL=274 > children[1] > type='disk' > id=1 > guid=10054650477559530937 > path='/dev/gpt/disk-e2:s3' > whole_disk=0 > DTL=273 > children[2] > type='disk' > id=2 > guid=17105959045159531558 > path='/dev/gpt/disk-e2:s4' > whole_disk=0 > DTL=272 > children[3] > type='disk' > id=3 > guid=17370453969371497663 > path='/dev/gpt/disk-e2:s5' > whole_disk=0 > DTL=271 > children[7] > type='raidz' > id=7 > guid=4614010953103453823 > nparity=1 > metaslab_array=24 > metaslab_shift=36 > ashift=9 > asize=7995163410432 > is_log=0 > children[0] > type='disk' > id=0 > guid=10090128057592036175 > path='/dev/gpt/disk-e2:s6' > whole_disk=0 > DTL=270 > children[1] > type='disk' > id=1 > guid=16676544025008223925 > path='/dev/gpt/disk-e2:s7' > whole_disk=0 > DTL=269 > children[2] > type='disk' > id=2 > guid=11777789246954957292 > path='/dev/gpt/disk-e2:s8' > whole_disk=0 > DTL=268 > children[3] > type='disk' > id=3 > guid=3406600121427522915 > path='/dev/gpt/disk-e2:s9' > whole_disk=0 > DTL=267 > > OS: > 8.1-STABLE FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 amd64 > > Hardware: > Chassis: SuperMicro 847E1 (two backplanes 24 disks front and 12 > disks in the back) > Motherboard: X8SIL > CPU: 1 x X3430 @ 2.40GHz > RAM: 16G > HDD Controller: SuperMicro / LSI 9260 (pciconf -lv SAS1078 PCI-X > Fusion-MPT SAS) : 2 ports > Disks: 36 x 2T Western Digital RE4 > > > > Any help would be appreciated. Let me know what additional information I > should provide. > Thank you in advance, > -- > Rumen Telbizov > > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 00:22:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05896106566C for ; Thu, 28 Oct 2010 00:22:15 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2218FC16 for ; Thu, 28 Oct 2010 00:22:14 +0000 (UTC) Received: by qyk7 with SMTP id 7so4226127qyk.13 for ; Wed, 27 Oct 2010 17:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=yNS0G4ZvAwmm92xRBvnoaUAsa5lGivsRGt0jLIphwI4=; b=sZM9RJIE0gEPrnu+KUn4o+hkq9MsFFdL7ggSDk2kj4px83GkmWwH5JGa+v8ElxVwsS q7tykXjU1MByO1T/oo0g3gbXA3r14ZebbFq6O6qKX88C8lzU+ylI1qr+Lsq5riV4G7d/ JA/2GR2JMbqMUusx8uaUpw7baGmnxFnVq9a0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=x/EIbs2JVo5nqbybwnxGEAYIUxRo8z7kfwVsbE5VAB6vhdKbuiOuYD/c0x9OJoG93C CKcwYQmlYrZtayYB4QGnSEiRR25kB1K48zruyXYzYDAUjiPF0GrFRaIlw0jANiaT6DH6 HNmS0qEyPYcTIP/oYzrg0sTrxHIPp4/bI+Tq4= MIME-Version: 1.0 Received: by 10.229.75.77 with SMTP id x13mr9873197qcj.58.1288225333210; Wed, 27 Oct 2010 17:22:13 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.187.200 with HTTP; Wed, 27 Oct 2010 17:22:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Oct 2010 17:22:13 -0700 X-Google-Sender-Auth: gjo4RVwDm_8Al8U2vENQ1wGpeqs Message-ID: From: Artem Belevich To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 00:22:15 -0000 QXJlIHlvdSBpbnRlcmVzdGVkIGluIHdoYXQncyB3cm9uZyBvciBpbiBob3cgdG8gZml4IGl0PwoK SWYgZml4aW5nIGlzIHRoZSBwcmlvcml0eSwgSSdkIGJvb3QgZnJvbSBPcGVuU29sYXJpcyBsaXZl IENEIGFuZCB3b3VsZAp0cnkgaW1wb3J0aW5nIHRoZSBhcnJheSB0aGVyZS4gSnVzdCBtYWtlIHN1 cmUgeW91IGRvbid0IHVwZ3JhZGUgWkZTIHRvCmEgdmVyc2lvbiB0aGF0IGlzIG5ld2VyIHRoYW4g dGhlIG9uZSBGcmVlQlNEIHN1cHBvcnRzLgoKT3BlbnNvbGFyaXMgbWF5IGJlIGFibGUgdG8gZml4 IHRoZSBhcnJheS4gT25jZSBpdCdzIGRvbmUsIGV4cG9ydCBpdCwKYm9vdCBiYWNrIHRvIEZyZWVC U0QgYW5kIHJlLWltcG9ydCBpdC4KCi0tQXJ0ZW0KCgoKT24gV2VkLCBPY3QgMjcsIDIwMTAgYXQg NDoyMiBQTSwgUnVtZW4gVGVsYml6b3YgPHRlbGJpem92QGdtYWlsLmNvbT4gd3JvdGU6Cj4gTm8g aWRlYXMgd2hhdHNvZXZlcj8KPgo+IE9uIFR1ZSwgT2N0IDI2LCAyMDEwIGF0IDE6MDQgUE0sIFJ1 bWVuIFRlbGJpem92IDx0ZWxiaXpvdkBnbWFpbC5jb20+IHdyb3RlOgo+Cj4+IEhlbGxvIGV2ZXJ5 b25lLAo+Pgo+PiBBZnRlciBhIGZldyBkYXlzIG9mIHN0cnVnZ2xlIHdpdGggbXkgZGVncmFkZWQg enBvb2wgb24gYSBiYWNrdXAgc2VydmVyIEkKPj4gZGVjaWRlZCB0byBhc2sgZm9yCj4+IGhlbHAg aGVyZSBvciBhdCBsZWFzdCBnZXQgc29tZSBjbHVlcyBhcyB0byB3aGF0IG1pZ2h0IGJlIHdyb25n IHdpdGggaXQuCj4+IEhlcmUncyB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgenBvb2w6Cj4+Cj4+ ICMgenBvb2wgc3RhdHVzCj4+Cj4+IKAgcG9vbDogdGFuawo+PiCgc3RhdGU6IERFR1JBREVECj4+ IHN0YXR1czogT25lIG9yIG1vcmUgZGV2aWNlcyBoYXMgZXhwZXJpZW5jZWQgYW4gZXJyb3IgcmVz dWx0aW5nIGluIGRhdGEKPj4goCCgIKAgoCBjb3JydXB0aW9uLiCgQXBwbGljYXRpb25zIG1heSBi ZSBhZmZlY3RlZC4KPj4gYWN0aW9uOiBSZXN0b3JlIHRoZSBmaWxlIGluIHF1ZXN0aW9uIGlmIHBv c3NpYmxlLiCgT3RoZXJ3aXNlIHJlc3RvcmUgdGhlCj4+IKAgoCCgIKAgZW50aXJlIHBvb2wgZnJv bSBiYWNrdXAuCj4+IKAgoHNlZTogaHR0cDovL3d3dy5zdW4uY29tL21zZy9aRlMtODAwMC04QQo+ PiCgc2NydWI6IG5vbmUgcmVxdWVzdGVkCj4+IGNvbmZpZzoKPj4KPj4goCCgIKAgoCBOQU1FIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBTVEFURSCgIKAgUkVBRCBXUklURSBDS1NVTQo+PiCgIKAg oCCgIHRhbmsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoERFR1JBREVEIKAgoCAwIKAgoCAwIKAg oCAwCj4+IKAgoCCgIKAgoCByYWlkejEgoCCgIKAgoCCgIKAgoCCgIKAgoCCgREVHUkFERUQgoCCg IDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgc3BhcmUgoCCgIKAgoCCgIKAgoCCgIKAgoCBE RUdSQURFRCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCCgIHJlcGxhY2luZyCgIKAg oCCgIKAgoCCgIERFR1JBREVEIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCgIKAgoCAx NzMwNzA0MTgyMjE3Nzc5ODUxOSCgVU5BVkFJTCCgIKAgoDAgoCAyOTkgoCCgIDAgoHdhcwo+PiAv ZGV2L2dwdC9kaXNrLWUxOnMyCj4+IKAgoCCgIKAgoCCgIKAgoCBncHQvbmV3ZGlzay1lMTpzMiCg IKAgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgoCBncHQvZGlzay1l MjpzMTAgoCCgIKAgoCBPTkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCBn cHQvZGlzay1lMTpzMyCgIKAgoCCgIKAgoE9OTElORSCgIKAgoDMwIKAgoCAwIKAgoCAwCj4+IKAg oCCgIKAgoCCgIGdwdC9kaXNrLWUxOnM0IKAgoCCgIKAgoCCgT05MSU5FIKAgoCCgIDAgoCCgIDAg oCCgIDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTE6czUgoCCgIKAgoCCgIKBPTkxJTkUgoCCg IKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgcmFpZHoxIKAgoCCgIKAgoCCgIKAgoCCgIKAg oE9OTElORSCgIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCgIGdwdC9kaXNrLWUxOnM2 IKAgoCCgIKAgoCCgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgZ3B0 L2Rpc2stZTE6czcgoCCgIKAgoCCgIKBPTkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAg oCCgIKAgoCBncHQvZGlzay1lMTpzOCCgIKAgoCCgIKAgoE9OTElORSCgIKAgoCAwIKAgoCAwIKAg oCAwCj4+IKAgoCCgIKAgoCCgIGdwdC9kaXNrLWUxOnM5IKAgoCCgIKAgoCCgT05MSU5FIKAgoCCg IDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIHJhaWR6MSCgIKAgoCCgIKAgoCCgIKAgoCCgIKBP TkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCBncHQvZGlzay1lMTpzMTAg oCCgIKAgoCCgIE9OTElORSCgIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCgIGdwdC9k aXNrLWUxOnMxMSCgIKAgoCCgIKAgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAg oCCgIKAgZ3B0L2Rpc2stZTE6czEyIKAgoCCgIKAgoCBPTkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAg MAo+PiCgIKAgoCCgIKAgoCBncHQvZGlzay1lMTpzMTMgoCCgIKAgoCCgIE9OTElORSCgIKAgoCAw IKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCByYWlkejEgoCCgIKAgoCCgIKAgoCCgIKAgoCCgREVH UkFERUQgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTE6czE0IKAg oCCgIKAgoCBPTkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCBncHQvZGlz ay1lMTpzMTUgoCCgIKAgoCCgIE9OTElORSCgIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAg oCCgIGdwdC9kaXNrLWUxOnMxNiCgIKAgoCCgIKAgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCgIDAK Pj4goCCgIKAgoCCgIKAgc3BhcmUgoCCgIKAgoCCgIKAgoCCgIKAgoCBERUdSQURFRCCgIKAgMCCg IKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCCgIHJlcGxhY2luZyCgIKAgoCCgIKAgoCCgIERFR1JB REVEIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCgIKAgoCAxNTI1ODczODI4Mjg4MDYw MzMzMSCgVU5BVkFJTCCgIKAgoDAgoCCgNDggoCCgIDAgoHdhcwo+PiAvZGV2L2dwdC9kaXNrLWUx OnMxNwo+PiCgIKAgoCCgIKAgoCCgIKAgZ3B0L25ld2Rpc2stZTE6czE3IKAgoE9OTElORSCgIKAg oCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTI6czExIKAgoCCgIKAg T05MSU5FIKAgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIHJhaWR6MSCgIKAgoCCgIKAg oCCgIKAgoCCgIKBPTkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCBncHQv ZGlzay1lMTpzMTggoCCgIKAgoCCgIE9OTElORSCgIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCg IKAgoCCgIGdwdC9kaXNrLWUxOnMxOSCgIKAgoCCgIKAgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCg IDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTE6czIwIKAgoCCgIKAgoCBPTkxJTkUgoCCgIKAg MCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCBncHQvZGlzay1lMTpzMjEgoCCgIKAgoCCgIE9O TElORSCgIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCByYWlkejEgoCCgIKAgoCCgIKAg oCCgIKAgoCCgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rp c2stZTE6czIyIKAgoCCgIKAgoCBPTkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCg IKAgoCBncHQvZGlzay1lMTpzMjMgoCCgIKAgoCCgIE9OTElORSCgIKAgoCAwIKAgoCAwIKAgoCAw Cj4+IKAgoCCgIKAgoCCgIGdwdC9kaXNrLWUyOnMwIKAgoCCgIKAgoCCgT05MSU5FIKAgoCCgIDAg oCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTI6czEgoCCgIKAgoCCgIKBPTkxJ TkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgcmFpZHoxIKAgoCCgIKAgoCCgIKAg oCCgIKAgoE9OTElORSCgIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCgIGdwdC9kaXNr LWUyOnMyIKAgoCCgIKAgoCCgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCg IKAgZ3B0L2Rpc2stZTI6czMgoCCgIKAgoCCgIKBPTkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+ PiCgIKAgoCCgIKAgoCBncHQvZGlzay1lMjpzNCCgIKAgoCCgIKAgoE9OTElORSCgIKAgoCAwIKAg oCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCgIGdwdC9kaXNrLWUyOnM1IKAgoCCgIKAgoCCgT05MSU5F IKAgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIHJhaWR6MSCgIKAgoCCgIKAgoCCgIKAg oCCgIKBPTkxJTkUgoCCgIKAgMCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCBncHQvZGlzay1l MjpzNiCgIKAgoCCgIKAgoE9OTElORSCgIKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCg IGdwdC9kaXNrLWUyOnM3IKAgoCCgIKAgoCCgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCgIDAKPj4g oCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTI6czggoCCgIKAgoCCgIKBPTkxJTkUgoCCgIKAgMCCgIKAg MCCgIKAgMAo+PiCgIKAgoCCgIKAgoCBncHQvZGlzay1lMjpzOSCgIKAgoCCgIKAgoE9OTElORSCg IKAgoCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgc3BhcmVzCj4+IKAgoCCgIKAgoCBncHQvZGlz ay1lMjpzMTAgoCCgIKAgoCCgIKAgSU5VU0UgoCCgIGN1cnJlbnRseSBpbiB1c2UKPj4goCCgIKAg oCCgIGdwdC9kaXNrLWUyOnMxMSCgIKAgoCCgIKAgoCBJTlVTRSCgIKAgY3VycmVudGx5IGluIHVz ZQo+PiCgIKAgoCCgIKAgZ3B0L2Rpc2stZTE6czIgoCCgIKAgoCCgIKAgoFVOQVZBSUwgoCBjYW5u b3Qgb3Blbgo+PiCgIKAgoCCgIKAgZ3B0L25ld2Rpc2stZTE6czE3IKAgoCCgIKAgoElOVVNFIKAg oCBjdXJyZW50bHkgaW4gdXNlCj4+Cj4+IGVycm9yczogNCBkYXRhIGVycm9ycywgdXNlICctdicg Zm9yIGEgbGlzdAo+Pgo+Pgo+PiBUaGUgcHJvYmxlbSBpczogYWZ0ZXIgcmVwbGFjaW5nIHRoZSBi YWQgZHJpdmVzIGFuZCByZXNpbHZlcmluZyB0aGUgb2xkL2JhZAo+PiBkcml2ZXMgY2Fubm90IGJl IGRldGFjaGVkLgo+PiBUaGUgcmVwbGFjZSBjb21tYW5kIGRpZG4ndCByZW1vdmUgaXQgYXV0b21h dGljYWxseSBhbmQgbWFudWFsIGRldGFjaCBmYWlscy4KPj4gSGVyZSBhcmUgc29tZSBleGFtcGxl czoKPj4KPj4gIyB6cG9vbCBkZXRhY2ggdGFuayAxNTI1ODczODI4Mjg4MDYwMzMzMQo+PiBjYW5u b3QgZGV0YWNoIDE1MjU4NzM4MjgyODgwNjAzMzMxOiBubyB2YWxpZCByZXBsaWNhcwo+PiAjIHpw b29sIGRldGFjaCB0YW5rIGdwdC9kaXNrLWUyOnMxMQo+PiBjYW5ub3QgZGV0YWNoIGdwdC9kaXNr LWUyOnMxMTogbm8gdmFsaWQgcmVwbGljYXMKPj4gIyB6cG9vbCBkZXRhY2ggdGFuayBncHQvbmV3 ZGlzay1lMTpzMTcKPj4gY2Fubm90IGRldGFjaCBncHQvbmV3ZGlzay1lMTpzMTc6IG5vIHZhbGlk IHJlcGxpY2FzCj4+ICMgenBvb2wgZGV0YWNoIHRhbmsgZ3B0L2Rpc2stZTE6czE3Cj4+IGNhbm5v dCBkZXRhY2ggZ3B0L2Rpc2stZTE6czE3OiBubyB2YWxpZCByZXBsaWNhcwo+Pgo+Pgo+PiBIZXJl J3MgbW9yZSBpbmZvcm1hdGlvbiBhbmQgaGlzdG9yeSBvZiBldmVudHMuCj4+IFRoaXMgaXMgYSAz NiBkaXNrIFN1cGVyTWljcm8gODQ3IG1hY2hpbmUgd2l0aCAyVCBXRCBSRTQgZGlza3Mgb3JnYW5p emVkIGluCj4+IHJhaWR6MSBncm91cHMgYXMKPj4gZGVwaWN0ZWQgYWJvdmUuIHpwb29sIGRlYWxz IG9ubHkgd2l0aCBwYXJ0aXRpb25zIGxpa2UgdGhvc2U6Cj4+Cj4+ID0+IKAgoCCgIKAzNCCgMzkw NDI5NDg0NSCgbWZpZDMwIKBHUFQgoCgxLjhUKQo+PiCgIKAgoCCgIKAgMzQgoDM5MDM4OTc2MDAg oCCgIKAgMSCgZGlzay1lMjpzOSCgKDEuOFQpCj4+IKAgMzkwMzg5NzYzNCCgIKAgoDM5NzI0NSCg IKAgoCCgIKAtIGZyZWUgLSCgKDE5NE0pCj4+Cj4+IG1maWRYWCBkZXZpY2VzIGFyZSBkaXNrcyBj b25uZWN0ZWQgdG8gYSBTdXBlck1pY3JvL0xTSSBjb250cm9sbGVyIGFuZAo+PiBwcmVzZW50ZWQg YXMgamJvZHMuIEpCT0RzIGluIHRoaXMgYWRhcHRlcgo+PiBhcmUgYWN0dWFsbHkgY29uc3RydWN0 ZWQgYXMgcmFpZDAgYXJyYXkgb2YgMSBkaXNrIGJ1dCB0aGlzIHNob3VsZCBiZQo+PiBpcnJlbGV2 YW50IGluIHRoaXMgY2FzZS4KPj4KPj4gVGhpcyBtYWNoaW5lIHdhcyB3b3JraW5nIGZpbmUgc2lu Y2UgU2VwdGVtYmVyIDZ0aCBidXQgdHdvIG9mIHRoZSBkaXNrcyAoaW4KPj4gZGlmZmVyZW50IHJh aWR6MSB2ZGV2cykgd2VyZSBnb2luZwo+PiBwcmV0dHkgYmFkIGFuZCBhY2N1bXVsYXRlZCBxdWl0 ZSBhIGJpdCBvZiBlcnJvcnMgdW50aWwgZXZlbnR1YWxseSB0aGV5Cj4+IGRpZWQuIFRoaXMgaXMg aG93IHRoZXkgbG9va2VkIGxpa2U6Cj4+Cj4+IKAgoCCgIKAgoCByYWlkejEgoCCgIKAgoCCgIKAg REVHUkFERUQgoCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTE6czIg oCBVTkFWQUlMIKAgoCA0NCA1OS41SyCgIKAgMCCgZXhwZXJpZW5jZWQgSS9PCj4+IGZhaWx1cmVz Cj4+IKAgoCCgIKAgoCCgIGdwdC9kaXNrLWUxOnMzIKAgT05MSU5FIKAgoCCgIDAgoCCgIDAgoCCg IDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTE6czQgoCBPTkxJTkUgoCCgIKAgMCCgIKAgMCCg IKAgMAo+PiCgIKAgoCCgIKAgoCBncHQvZGlzay1lMTpzNSCgIE9OTElORSCgIKAgoCAwIKAgoCAw IKAgoCAwCj4+Cj4+IKAgoCCgIKAgoCByYWlkejEgoCCgIKAgoCCgIKAgREVHUkFERUQgoCCgIDAg oCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTE6czE0IKBPTkxJTkUgoCCgIKAg MCCgIKAgMCCgIKAgMAo+PiCgIKAgoCCgIKAgoCBncHQvZGlzay1lMTpzMTUgoE9OTElORSCgIKAg oCAwIKAgoCAwIKAgoCAwCj4+IKAgoCCgIKAgoCCgIGdwdC9kaXNrLWUxOnMxNiCgT05MSU5FIKAg oCCgIDAgoCCgIDAgoCCgIDAKPj4goCCgIKAgoCCgIKAgZ3B0L2Rpc2stZTE6czE3IKBVTkFWQUlM IKAxLjU2SyA0OS4wSyCgIKAgMCCgZXhwZXJpZW5jZWQgSS9PCj4+IGZhaWx1cmVzCj4+Cj4+Cj4+ IEkgZGlkIGhhdmUgdHdvIHNwYXJlIGRpc2tzIHJlYWR5IHRvIHJlcGxhY2UgdGhlbS4gU28gYWZ0 ZXIgdGhleSBkaWVkIGhlcmUncwo+PiB3aGF0IEkgZXhlY3V0ZWQ6Cj4+Cj4+ICMgenBvb2wgcmVw bGFjZSB0YW5rIGdwdC9kaXNrLWUxOnMyIGdwdC9kaXNrLWUyOnMxMAo+PiAjIHpwb29sIHJlcGxh Y2UgdGFuayBncHQvZGlzay1lMTpzMTcgZ3B0L2Rpc2stZTI6czExCj4+Cj4+IFJlc2lsdmVyaW5n IHN0YXJ0ZWQuIFdoaWxlIGluIHRoZSBtaWRkbGUgb2YgaXQgdGhvdWdoIHRoZSBrZXJuZWwgcGFu aWNlZAo+PiBhbmQgSSBoYWQgdG8gcmVib290IHRoZSBtYWNoaW5lLgo+PiBBZnRlciByZWJvb3Qg SSB3YWl0ZWQgdW50aWwgdGhlIHJlc2lsdmVyaW5nIGlzIGNvbXBsZXRlLiBOb3cgdGhhdCBpdCB3 YXMKPj4gY29tcGxldGUgSSBleHBlY3RlZCB0byBzZWUgdGhlIG9sZC9iYWQKPj4gZGV2aWNlIHJl bW92ZWQgZnJvbSB0aGUgdmRldiBidXQgaXQgd2FzIHN0aWxsIHRoZXJlLiBUcnlpbmcgZGV0YWNo IHdhcwo+PiBjb21wbGFpbmluZyB3aXRoIG5vIHZhbGlkIHJlcGxpY2FzLgo+PiBJIHNlbnQgY29s byB0ZWNobmljaWFuIHRvIHJlcGxhY2UgYm90aCB0aG9zZSBkZWZlY3RpdmUgZHJpdmVzIHdpdGgg YnJhbmQKPj4gbmV3IG9uZXMuIE9uY2UgSSBoYWQgdGhlbSBpbnNlcnRlZAo+PiBJIHJlY3JlYXRl ZCB0aGVtIGV4YWN0bHkgdGhlIHNhbWUgd2F5IGFzIHRoZSBvbmVzIHRoYXQgSSBoYWQgYmVmb3Jl IC0gamJvZAo+PiBhbmQgZ3BhcnQgbGFiZWxlZCBwYXJ0aXRpb24gd2l0aCB0aGUKPj4gc2FtZSBu YW1lISBUaGVuIEkgYWRkZWQgdGhlbSBhcyBzcGFyZXM6Cj4+Cj4+ICMgenBvb2wgYWRkIHRhbmsg c3BhcmUgZ3B0L2Rpc2stZTE6czIKPj4gIyB6cG9vbCBhZGQgdGFuayBzcGFyZSBncHQvZGlzay1l MTpzMTcKPj4KPj4gVGhhdCBhY3R1YWxseSBtYWRlIGl0IHdvcnNlIEkgdGhpbmsgc2luY2Ugbm93 IEkgaGFkIHRoZSBzYW1lIGRldmljZSBuYW1lCj4+IGJvdGggYXMgYSAncHJldmlvdXMnIGZhaWxl ZCBkZXZpY2UKPj4gaW5zaWRlIHRoZSByYWlkejEgZ3JvdXAgYW5kIGFzIGEgaG90IHNwYXJlIHNw YXJlIGRldmljZS4gSSBjb3VsZG4ndCBkbwo+PiBhbnl0aGluZyB3aXRoIGl0Lgo+PiBXaGF0IEkg ZGlkIHdhcyB0byBleHBvcnQgdGhlIHBvb2wgZmFpbCB0aGUgZGlzayBvbiB0aGUgY29udHJvbGxl ciwgaW1wb3J0Cj4+IHRoZSBwb29sIGFuZCBjaGVjayB0aGF0IHpmcyBjb3VsZCBvcGVuCj4+IGl0 IGFueW1vcmUgKGFzIGEgcGFydCBvZiB0aGUgaG90IHNwYXJlcykuIFRoZW4gSSByZWNyZWF0ZWQg dGhhdAo+PiBkaXNrL3BhcnRpdGlvbiB3aXRoIGEgbmV3IGxhYmVsICduZXdkaXNrLVhYWCcKPj4g YW5kIHRyaWVkIHRvIHJlcGxhY2UgdGhlIGRldmljZSB0aGF0IG9yaWdpbmFsbHkgZmFpbGVkIChh bmQgd2FzIG9ubHkKPj4gcHJlc2VudGVkIHdpdGggYSBudW1iZXIpLiBTbyBJIGRpZCB0aGlzOgo+ Pgo+PiAjIHpwb29sIHJlcGxhY2UgdGFuayBncHQvZGlzay1lMTpzMTcgZ3B0L25ld2Rpc2stZTE6 czE3Cj4+ICMgenBvb2wgcmVwbGFjZSB0YW5rIGdwdC9kaXNrLWUxOnMyIGdwdC9uZXdkaXNrLWUx OnMyCj4+Cj4+IFJlc2lsdmVyaW5nIGNvbXBsZXRlZCBhZnRlciAxNyBob3VycyBvciBzbyBhbmQg SSBleHBlY3RlZCBmb3IgdGhlCj4+ICdyZXBsYWNpbmcnIG9wZXJhdGlvbiB0byBkaXNhcHBlYXIg YW5kIHRoZQo+PiByZXBsYWNlZCBkZXZpY2UgdG8gZ28gYXdheS4gQnV0IGl0IGRpZG4ndCEgSW5z dGVhZCBJIGhhdmUgdGhlIHN0YXRlIG9mIHRoZQo+PiBwb29sIGFzIHNob3duIGluIHRoZSBiZWdp bm5pbmcgb2YKPj4gdGhlIGVtYWlsLgo+PiBBcyBmb3IgdGhlICdlcnJvcnM6IDQgZGF0YSBlcnJv cnMsIHVzZSAnLXYnIGZvciBhIGxpc3QnIEkgc3VzcGVjdCB0aGF0Cj4+IGl0J3MgZHVlIGFub3Ro ZXIgZmFpbGluZwo+PiBkZXZpY2UgKGdwdC9kaXNrLWUxOnMzKSBpbnNpZGUgdGhlIGZpcnN0IChj dXJyZW50bHkgZGVncmFkZWQpIHJhaWR6MSB2ZGV2Lgo+PiBUaG9zZSA0IGNvcnJ1cHRlZCBmaWxl cyBhY3R1YWxseQo+PiBjb3VsZCBiZSByZWFkIHNvbWV0aW1lcyBzbyB0aGF0IHRlbGxzIG1lIHRo YXQgdGhlIGRpc2sgaGFzIHRyb3VibGUgcmVhZGluZwo+PiAqc29tZXRpbWVzKiB0aG9zZSBiYWQg YmxvY2tzLgo+Pgo+PiBIZXJlJ3MgdGhlIG91dHB1dCBvZiB6ZGIgLWwgdGFuawo+Pgo+PiCgIKAg dmVyc2lvbj0xNAo+PiCgIKAgbmFtZT0ndGFuaycKPj4goCCgIHN0YXRlPTAKPj4goCCgIHR4Zz0y MDAyMjUKPj4goCCgIHBvb2xfZ3VpZD0xMzUwNDUwOTk5Mjk3ODYxMDMwMQo+PiCgIKAgaG9zdGlk PTQwOTMyNTkxOAo+PiCgIKAgaG9zdG5hbWU9J1hYWFgnCj4+IKAgoCB2ZGV2X3RyZWUKPj4goCCg IKAgoCB0eXBlPSdyb290Jwo+PiCgIKAgoCCgIGlkPTAKPj4goCCgIKAgoCBndWlkPTEzNTA0NTA5 OTkyOTc4NjEwMzAxCj4+IKAgoCCgIKAgY2hpbGRyZW5bMF0KPj4goCCgIKAgoCCgIKAgoCCgIHR5 cGU9J3JhaWR6Jwo+PiCgIKAgoCCgIKAgoCCgIKAgaWQ9MAo+PiCgIKAgoCCgIKAgoCCgIKAgZ3Vp ZD0zNzQwODU0ODkwMTkyODI1Mzk0Cj4+IKAgoCCgIKAgoCCgIKAgoCBucGFyaXR5PTEKPj4goCCg IKAgoCCgIKAgoCCgIG1ldGFzbGFiX2FycmF5PTMzCj4+IKAgoCCgIKAgoCCgIKAgoCBtZXRhc2xh Yl9zaGlmdD0zNgo+PiCgIKAgoCCgIKAgoCCgIKAgYXNoaWZ0PTkKPj4goCCgIKAgoCCgIKAgoCCg IGFzaXplPTc5OTUxNjM0MTA0MzIKPj4goCCgIKAgoCCgIKAgoCCgIGlzX2xvZz0wCj4+IKAgoCCg IKAgoCCgIKAgoCBjaGlsZHJlblswXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdz cGFyZScKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9MAo+PiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBndWlkPTE2MTcxOTAxMDk4MDA0Mjc4MzEzCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJlblswXQo+ PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5cGU9J3JlcGxhY2luZycKPj4goCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgZ3VpZD0yNzU0NTUwMzEwMzkwODYxNTc2Cj4+IKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgd2hvbGVfZGlzaz0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgY2hpbGRyZW5bMF0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHR5cGU9J2Rpc2snCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCBpZD0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBndWlkPTE3 MzA3MDQxODIyMTc3Nzk4NTE5Cj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCBwYXRoPScvZGV2L2dwdC9kaXNrLWUxOnMyJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgd2hvbGVfZGlzaz0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCBub3RfcHJlc2VudD0xCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCBEVEw9MjQ2Cj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgY2hpbGRyZW5bMV0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IHR5cGU9J2Rpc2snCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBp ZD0xCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBndWlkPTE2NDEz OTQwNTY4MjQ5NTU0ODUKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IHBhdGg9Jy9kZXYvZ3B0L25ld2Rpc2stZTE6czInCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIERUTD01NQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJl blsxXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5cGU9J2Rpc2snCj4+IKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9MQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIGd1aWQ9MTMxNTAzNTY3ODEzMDA0Njg1MTIKPj4goCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCBwYXRoPScvZGV2L2dwdC9kaXNrLWUyOnMxMCcKPj4goCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCBpc19zcGFyZT0xCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgRFRMPTEyODkKPj4goCCgIKAgoCCgIKAgoCCgIGNoaWxkcmVuWzFdCj4+IKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIHR5cGU9J2Rpc2snCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGlkPTEK Pj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZ3VpZD02MDQ3MTkyMjM3MTc2ODA3NTYxCj4+IKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTE6czMnCj4+IKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCBEVEw9MjUwCj4+IKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJlblsyXQo+PiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0yCj4+ IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1aWQ9OTE3ODMxODUwMDg5MTA3MTIwOAo+PiCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCBwYXRoPScvZGV2L2dwdC9kaXNrLWUxOnM0Jwo+PiCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg RFRMPTI0OQo+PiCgIKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5bM10KPj4goCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgdHlwZT0nZGlzaycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9Mwo+PiCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBndWlkPTI1Njc5OTk4NTU3NDY3Njc4MzEKPj4goCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgcGF0aD0nL2Rldi9ncHQvZGlzay1lMTpzNScKPj4goCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgd2hvbGVfZGlzaz0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIERU TD0yNDgKPj4goCCgIKAgoCBjaGlsZHJlblsxXQo+PiCgIKAgoCCgIKAgoCCgIKAgdHlwZT0ncmFp ZHonCj4+IKAgoCCgIKAgoCCgIKAgoCBpZD0xCj4+IKAgoCCgIKAgoCCgIKAgoCBndWlkPTE3MDk3 MDQ3MzEwMTc3NzkzNzMzCj4+IKAgoCCgIKAgoCCgIKAgoCBucGFyaXR5PTEKPj4goCCgIKAgoCCg IKAgoCCgIG1ldGFzbGFiX2FycmF5PTMxCj4+IKAgoCCgIKAgoCCgIKAgoCBtZXRhc2xhYl9zaGlm dD0zNgo+PiCgIKAgoCCgIKAgoCCgIKAgYXNoaWZ0PTkKPj4goCCgIKAgoCCgIKAgoCCgIGFzaXpl PTc5OTUxNjM0MTA0MzIKPj4goCCgIKAgoCCgIKAgoCCgIGlzX2xvZz0wCj4+IKAgoCCgIKAgoCCg IKAgoCBjaGlsZHJlblswXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+ PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IGd1aWQ9MTQ1MTMzODAyOTczOTMxOTY2NTQKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcGF0 aD0nL2Rldi9ncHQvZGlzay1lMTpzNicKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgd2hvbGVf ZGlzaz0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIERUTD0yNjYKPj4goCCgIKAgoCCgIKAg oCCgIGNoaWxkcmVuWzFdCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5cGU9J2Rpc2snCj4+ IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGlkPTEKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg Z3VpZD03NjczMzkxNjQ1MzI5ODM5MjczCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHBhdGg9 Jy9kZXYvZ3B0L2Rpc2stZTE6czcnCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdob2xlX2Rp c2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBEVEw9MjY1Cj4+IKAgoCCgIKAgoCCgIKAg oCBjaGlsZHJlblsyXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+PiCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0yCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1 aWQ9MTUxODkxMzIzMDU1OTA0MTIxMzQKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcGF0aD0n L2Rldi9ncHQvZGlzay1lMTpzOCcKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgd2hvbGVfZGlz az0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIERUTD0yNjQKPj4goCCgIKAgoCCgIKAgoCCg IGNoaWxkcmVuWzNdCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5cGU9J2Rpc2snCj4+IKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIGlkPTMKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZ3Vp ZD0xNzE3MTg3NTUyNzcxNDAyMjA3Ngo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBwYXRoPScv ZGV2L2dwdC9kaXNrLWUxOnM5Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNr PTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgRFRMPTI2Mwo+PiCgIKAgoCCgIGNoaWxkcmVu WzJdCj4+IKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdyYWlkeicKPj4goCCgIKAgoCCgIKAgoCCgIGlk PTIKPj4goCCgIKAgoCCgIKAgoCCgIGd1aWQ9NDU1MTAwMjI2NTk2MjgwMzE4Ngo+PiCgIKAgoCCg IKAgoCCgIKAgbnBhcml0eT0xCj4+IKAgoCCgIKAgoCCgIKAgoCBtZXRhc2xhYl9hcnJheT0zMAo+ PiCgIKAgoCCgIKAgoCCgIKAgbWV0YXNsYWJfc2hpZnQ9MzYKPj4goCCgIKAgoCCgIKAgoCCgIGFz aGlmdD05Cj4+IKAgoCCgIKAgoCCgIKAgoCBhc2l6ZT03OTk1MTYzNDEwNDMyCj4+IKAgoCCgIKAg oCCgIKAgoCBpc19sb2c9MAo+PiCgIKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5bMF0KPj4goCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgdHlwZT0nZGlzaycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg aWQ9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBndWlkPTEyMTA0MjQxNTE5NDg0NzEyMTYx Cj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTE6czEwJwo+ PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgRFRMPTI2Mgo+PiCgIKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5bMV0KPj4goCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgdHlwZT0nZGlzaycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg aWQ9MQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBndWlkPTM5NTAyMTAzNDk2MjMxNDIzMjUK Pj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcGF0aD0nL2Rldi9ncHQvZGlzay1lMTpzMTEnCj4+ IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBEVEw9MjYxCj4+IKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJlblsyXQo+PiCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBp ZD0yCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1aWQ9MTQ1NTk5MDM5NTU2OTg2NDAwODUK Pj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcGF0aD0nL2Rldi9ncHQvZGlzay1lMTpzMTInCj4+ IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBEVEw9MjYwCj4+IKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJlblszXQo+PiCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBp ZD0zCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1aWQ9MTIzNjQxNTUxMTQ4NDQyMjAwNjYK Pj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcGF0aD0nL2Rldi9ncHQvZGlzay1lMTpzMTMnCj4+ IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBEVEw9MjU5Cj4+IKAgoCCgIKAgY2hpbGRyZW5bM10KPj4goCCgIKAgoCCgIKAgoCCg IHR5cGU9J3JhaWR6Jwo+PiCgIKAgoCCgIKAgoCCgIKAgaWQ9Mwo+PiCgIKAgoCCgIKAgoCCgIKAg Z3VpZD0xMjUxNzIzMTIyNDU2ODAxMDI5NAo+PiCgIKAgoCCgIKAgoCCgIKAgbnBhcml0eT0xCj4+ IKAgoCCgIKAgoCCgIKAgoCBtZXRhc2xhYl9hcnJheT0yOQo+PiCgIKAgoCCgIKAgoCCgIKAgbWV0 YXNsYWJfc2hpZnQ9MzYKPj4goCCgIKAgoCCgIKAgoCCgIGFzaGlmdD05Cj4+IKAgoCCgIKAgoCCg IKAgoCBhc2l6ZT03OTk1MTYzNDEwNDMyCj4+IKAgoCCgIKAgoCCgIKAgoCBpc19sb2c9MAo+PiCg IKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5bMF0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHlw ZT0nZGlzaycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9MAo+PiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCBndWlkPTc2NTU3ODkwMzg5MjUzMzA5ODMKPj4goCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgcGF0aD0nL2Rldi9ncHQvZGlzay1lMTpzMTQnCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBEVEw9MjU4Cj4+IKAg oCCgIKAgoCCgIKAgoCBjaGlsZHJlblsxXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBl PSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0xCj4+IKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIGd1aWQ9MTc4MTU3NTUzNzg5NjgyMzMxNDEKPj4goCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgcGF0aD0nL2Rldi9ncHQvZGlzay1lMTpzMTUnCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBEVEw9MjU3Cj4+IKAg oCCgIKAgoCCgIKAgoCBjaGlsZHJlblsyXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBl PSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0yCj4+IKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIGd1aWQ9OTU5MDQyMTY4MTkyNTY3Mzc2Nwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCBwYXRoPScvZGV2L2dwdC9kaXNrLWUxOnMxNicKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgd2hvbGVfZGlzaz0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIERUTD0yNTYKPj4goCCg IKAgoCCgIKAgoCCgIGNoaWxkcmVuWzNdCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5cGU9 J3NwYXJlJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0zCj4+IKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIGd1aWQ9NDAxNTQxNzEwMDA1MTIzNTM5OAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5bMF0K Pj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdyZXBsYWNpbmcnCj4+IKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIGd1aWQ9MTE2NTM0Mjk2OTczMzAxOTMxNzYKPj4goCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBjaGlsZHJlblswXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgdHlwZT0nZGlzaycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIGlkPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1aWQ9 MTUyNTg3MzgyODI4ODA2MDMzMzEKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTE6czE3Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgd2hvbGVfZGlzaz0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCBub3RfcHJlc2VudD0xCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCBEVEw9MjU1Cj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgY2hpbGRyZW5bMV0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHR5cGU9J2Rpc2snCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCBpZD0xCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBndWlkPTkw ODY1MTM4MDY5MDk1NDgzMwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgcGF0aD0nL2Rldi9ncHQvbmV3ZGlzay1lMTpzMTcnCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIGlzX3NwYXJlPTEKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIERUTD01Mgo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJl blsxXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5cGU9J2Rpc2snCj4+IKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9MQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIGd1aWQ9NzI1MDkzNDE5NjU3MTkwNjE2MAo+PiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTI6czExJwo+PiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIGlzX3NwYXJlPTEKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCBEVEw9MTI5Mgo+PiCgIKAgoCCgIGNoaWxkcmVuWzRdCj4+IKAgoCCgIKAgoCCgIKAgoCB0eXBl PSdyYWlkeicKPj4goCCgIKAgoCCgIKAgoCCgIGlkPTQKPj4goCCgIKAgoCCgIKAgoCCgIGd1aWQ9 NzYyMjM2NjI4ODMwNjYxMzEzNgo+PiCgIKAgoCCgIKAgoCCgIKAgbnBhcml0eT0xCj4+IKAgoCCg IKAgoCCgIKAgoCBtZXRhc2xhYl9hcnJheT0yOAo+PiCgIKAgoCCgIKAgoCCgIKAgbWV0YXNsYWJf c2hpZnQ9MzYKPj4goCCgIKAgoCCgIKAgoCCgIGFzaGlmdD05Cj4+IKAgoCCgIKAgoCCgIKAgoCBh c2l6ZT03OTk1MTYzNDEwNDMyCj4+IKAgoCCgIKAgoCCgIKAgoCBpc19sb2c9MAo+PiCgIKAgoCCg IKAgoCCgIKAgY2hpbGRyZW5bMF0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHlwZT0nZGlz aycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCBndWlkPTExMjgzNDgzMTA2OTIxMzQzOTYzCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTE6czE4Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3 aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgRFRMPTI1NAo+PiCgIKAgoCCg IKAgoCCgIKAgY2hpbGRyZW5bMV0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHlwZT0nZGlz aycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9MQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCBndWlkPTE0OTAwNTk3OTY4NDU1OTY4NTc2Cj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTE6czE5Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3 aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgRFRMPTI1Mwo+PiCgIKAgoCCg IKAgoCCgIKAgY2hpbGRyZW5bMl0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHlwZT0nZGlz aycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9Mgo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCBndWlkPTQxNDA1OTI2MTE4NTI1MDQ1MTMKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg cGF0aD0nL2Rldi9ncHQvZGlzay1lMTpzMjAnCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdo b2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBEVEw9MjUyCj4+IKAgoCCgIKAg oCCgIKAgoCBjaGlsZHJlblszXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNr Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0zCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIGd1aWQ9Mjc5NDIxNTM4MDIwNzU3Njk3NQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBw YXRoPScvZGV2L2dwdC9kaXNrLWUxOnMyMScKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgd2hv bGVfZGlzaz0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIERUTD0yNTEKPj4goCCgIKAgoCBj aGlsZHJlbls1XQo+PiCgIKAgoCCgIKAgoCCgIKAgdHlwZT0ncmFpZHonCj4+IKAgoCCgIKAgoCCg IKAgoCBpZD01Cj4+IKAgoCCgIKAgoCCgIKAgoCBndWlkPTE3NjU1MjkzOTA4MjcxMzAwODg5Cj4+ IKAgoCCgIKAgoCCgIKAgoCBucGFyaXR5PTEKPj4goCCgIKAgoCCgIKAgoCCgIG1ldGFzbGFiX2Fy cmF5PTI3Cj4+IKAgoCCgIKAgoCCgIKAgoCBtZXRhc2xhYl9zaGlmdD0zNgo+PiCgIKAgoCCgIKAg oCCgIKAgYXNoaWZ0PTkKPj4goCCgIKAgoCCgIKAgoCCgIGFzaXplPTc5OTUxNjM0MTA0MzIKPj4g oCCgIKAgoCCgIKAgoCCgIGlzX2xvZz0wCj4+IKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJlblswXQo+ PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBpZD0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1aWQ9NTI3NDE0NjM3OTAz NzA1NTAzOQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBwYXRoPScvZGV2L2dwdC9kaXNrLWUx OnMyMicKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgd2hvbGVfZGlzaz0wCj4+IKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIERUTD0yNzgKPj4goCCgIKAgoCCgIKAgoCCgIGNoaWxkcmVuWzFdCj4+ IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5cGU9J2Rpc2snCj4+IKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIGlkPTEKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZ3VpZD04NjUxNzU1MDE5NDA0 ODczNjg2Cj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTE6 czIzJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgRFRMPTI3Nwo+PiCgIKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5bMl0KPj4g oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHlwZT0nZGlzaycKPj4goCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgaWQ9Mgo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBndWlkPTE2ODI3Mzc5NjYxNzU5 OTg4OTc2Cj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTI6 czAnCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCBEVEw9Mjc2Cj4+IKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJlblszXQo+PiCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCBpZD0zCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1aWQ9MjUyNDk2NzE1MTMzMzkz Mzk3Mgo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBwYXRoPScvZGV2L2dwdC9kaXNrLWUyOnMx Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgRFRMPTI3NQo+PiCgIKAgoCCgIGNoaWxkcmVuWzZdCj4+IKAgoCCgIKAgoCCg IKAgoCB0eXBlPSdyYWlkeicKPj4goCCgIKAgoCCgIKAgoCCgIGlkPTYKPj4goCCgIKAgoCCgIKAg oCCgIGd1aWQ9MjQxMzUxOTY5NDAxNjExNTIyMAo+PiCgIKAgoCCgIKAgoCCgIKAgbnBhcml0eT0x Cj4+IKAgoCCgIKAgoCCgIKAgoCBtZXRhc2xhYl9hcnJheT0yNgo+PiCgIKAgoCCgIKAgoCCgIKAg bWV0YXNsYWJfc2hpZnQ9MzYKPj4goCCgIKAgoCCgIKAgoCCgIGFzaGlmdD05Cj4+IKAgoCCgIKAg oCCgIKAgoCBhc2l6ZT03OTk1MTYzNDEwNDMyCj4+IKAgoCCgIKAgoCCgIKAgoCBpc19sb2c9MAo+ PiCgIKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5bMF0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg dHlwZT0nZGlzaycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9MAo+PiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCBndWlkPTE2MzYxOTY4OTQ0MzM1MTQzNDEyCj4+IKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTI6czInCj4+IKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBEVEw9Mjc0Cj4+ IKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJlblsxXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0 eXBlPSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpZD0xCj4+IKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIGd1aWQ9MTAwNTQ2NTA0Nzc1NTk1MzA5MzcKPj4goCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgcGF0aD0nL2Rldi9ncHQvZGlzay1lMjpzMycKPj4goCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgd2hvbGVfZGlzaz0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIERUTD0yNzMKPj4g oCCgIKAgoCCgIKAgoCCgIGNoaWxkcmVuWzJdCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5 cGU9J2Rpc2snCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGlkPTIKPj4goCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgZ3VpZD0xNzEwNTk1OTA0NTE1OTUzMTU1OAo+PiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCBwYXRoPScvZGV2L2dwdC9kaXNrLWUyOnM0Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgRFRMPTI3Mgo+PiCg IKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5bM10KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHlw ZT0nZGlzaycKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgaWQ9Mwo+PiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCBndWlkPTE3MzcwNDUzOTY5MzcxNDk3NjYzCj4+IKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rpc2stZTI6czUnCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBEVEw9MjcxCj4+IKAg oCCgIKAgY2hpbGRyZW5bN10KPj4goCCgIKAgoCCgIKAgoCCgIHR5cGU9J3JhaWR6Jwo+PiCgIKAg oCCgIKAgoCCgIKAgaWQ9Nwo+PiCgIKAgoCCgIKAgoCCgIKAgZ3VpZD00NjE0MDEwOTUzMTAzNDUz ODIzCj4+IKAgoCCgIKAgoCCgIKAgoCBucGFyaXR5PTEKPj4goCCgIKAgoCCgIKAgoCCgIG1ldGFz bGFiX2FycmF5PTI0Cj4+IKAgoCCgIKAgoCCgIKAgoCBtZXRhc2xhYl9zaGlmdD0zNgo+PiCgIKAg oCCgIKAgoCCgIKAgYXNoaWZ0PTkKPj4goCCgIKAgoCCgIKAgoCCgIGFzaXplPTc5OTUxNjM0MTA0 MzIKPj4goCCgIKAgoCCgIKAgoCCgIGlzX2xvZz0wCj4+IKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJl blswXQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+PiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCBpZD0wCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1aWQ9MTAwOTAx MjgwNTc1OTIwMzYxNzUKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcGF0aD0nL2Rldi9ncHQv ZGlzay1lMjpzNicKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgd2hvbGVfZGlzaz0wCj4+IKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIERUTD0yNzAKPj4goCCgIKAgoCCgIKAgoCCgIGNoaWxkcmVu WzFdCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHR5cGU9J2Rpc2snCj4+IKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIGlkPTEKPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZ3VpZD0xNjY3NjU0 NDAyNTAwODIyMzkyNQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBwYXRoPScvZGV2L2dwdC9k aXNrLWUyOnM3Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgRFRMPTI2OQo+PiCgIKAgoCCgIKAgoCCgIKAgY2hpbGRyZW5b Ml0KPj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgdHlwZT0nZGlzaycKPj4goCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgaWQ9Mgo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBndWlkPTExNzc3Nzg5 MjQ2OTU0OTU3MjkyCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHBhdGg9Jy9kZXYvZ3B0L2Rp c2stZTI6czgnCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHdob2xlX2Rpc2s9MAo+PiCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCBEVEw9MjY4Cj4+IKAgoCCgIKAgoCCgIKAgoCBjaGlsZHJlblsz XQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB0eXBlPSdkaXNrJwo+PiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCBpZD0zCj4+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGd1aWQ9MzQwNjYwMDEy MTQyNzUyMjkxNQo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBwYXRoPScvZGV2L2dwdC9kaXNr LWUyOnM5Jwo+PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB3aG9sZV9kaXNrPTAKPj4goCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgRFRMPTI2Nwo+Pgo+PiBPUzoKPj4gOC4xLVNUQUJMRSBGcmVlQlNE IDguMS1TVEFCTEUgIzA6IFN1biBTZXAgoDUgMDA6MjI6NDUgUERUIDIwMTAgYW1kNjQKPj4KPj4g SGFyZHdhcmU6Cj4+IENoYXNzaXM6IKAgoCCgIKBTdXBlck1pY3JvIDg0N0UxICh0d28gYmFja3Bs YW5lcyAyNCBkaXNrcyBmcm9udCBhbmQgMTIKPj4gZGlza3MgaW4gdGhlIGJhY2spCj4+IE1vdGhl cmJvYXJkOiCgIKBYOFNJTAo+PiBDUFU6IKAgoCCgIKAgoCCgMSB4IFgzNDMwIKBAIDIuNDBHSHoK Pj4gUkFNOiCgIKAgoCCgIKAgoDE2Rwo+PiBIREQgQ29udHJvbGxlcjogU3VwZXJNaWNybyAvIExT SSA5MjYwIChwY2ljb25mIC1sdiCgU0FTMTA3OCBQQ0ktWAo+PiBGdXNpb24tTVBUIFNBUykgOiAy IHBvcnRzCj4+IERpc2tzOiCgIKAgoCCgIKAzNiB4IDJUIFdlc3Rlcm4gRGlnaXRhbCBSRTQKPj4K Pj4KPj4KPj4gQW55IGhlbHAgd291bGQgYmUgYXBwcmVjaWF0ZWQuIExldCBtZSBrbm93IHdoYXQg YWRkaXRpb25hbCBpbmZvcm1hdGlvbiBJCj4+IHNob3VsZCBwcm92aWRlLgo+PiBUaGFuayB5b3Ug aW4gYWR2YW5jZSwKPj4gLS0KPj4gUnVtZW4gVGVsYml6b3YKPj4KPj4KPgo+Cj4gLS0KPiBSdW1l biBUZWxiaXpvdgo+IGh0dHA6Ly90ZWxiaXpvdi5jb20KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+IGZyZWVic2Qtc3RhYmxlQGZyZWVic2Qub3JnIG1h aWxpbmcgbGlzdAo+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Zy ZWVic2Qtc3RhYmxlCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2Qt c3RhYmxlLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIgo+Cg== From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 01:05:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA50106564A for ; Thu, 28 Oct 2010 01:05:06 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 16FB58FC15 for ; Thu, 28 Oct 2010 01:05:05 +0000 (UTC) Received: by qwe4 with SMTP id 4so1323831qwe.13 for ; Wed, 27 Oct 2010 18:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=h5RtQdoqiH64RP5DXyfQ+dUqlLdK6mOF5rHnHNjrqyI=; b=Jj3H3EnfdHjQAum4lCbn8KSF2szalPm4nGFgWxhjFeK8fJfa2bfRIf2mo1UECE7esW jvd8qcC2/KpwSdHcSdYJ6MIjqel3w2giJcr6PPAGZu93yDXAOtLtPikirCPc/VnaP2Gq 332iUquJqCPLDyi+0qYydREPkI6Lw0PXo58o0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f/GE8/jP2iHCqiVmF+HIigjIfvVBVwmYK4IziEouYOT+/UjzqD5qXo33y5l9aLGcpQ L6x2K84UJo7Xkg/bQbavqazjUjEjKOHoxs6ScIJzNAEublTGGSten9S3EKLFsolmBx6x MpS12BNK49JquPe94h84HYMzNhtxU6dnrUnOE= MIME-Version: 1.0 Received: by 10.224.130.218 with SMTP id u26mr3136474qas.286.1288227905062; Wed, 27 Oct 2010 18:05:05 -0700 (PDT) Received: by 10.229.89.138 with HTTP; Wed, 27 Oct 2010 18:05:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Oct 2010 18:05:04 -0700 Message-ID: From: Rumen Telbizov To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 01:05:06 -0000 Thanks Artem, I am mainly concerned about fixing this immediate problem first and then if I can provide more information for the developers so that they look into this problem I'd be happy to. I'll try OpenSolaris live CD and see how it goes. Either way I'll report back here. Cheers, Rumen Telbizov On Wed, Oct 27, 2010 at 5:22 PM, Artem Belevich wrote: > Are you interested in what's wrong or in how to fix it? > > If fixing is the priority, I'd boot from OpenSolaris live CD and would > try importing the array there. Just make sure you don't upgrade ZFS to > a version that is newer than the one FreeBSD supports. > > Opensolaris may be able to fix the array. Once it's done, export it, > boot back to FreeBSD and re-import it. > > --Artem > > > > On Wed, Oct 27, 2010 at 4:22 PM, Rumen Telbizov > wrote: > > No ideas whatsoever? > > > > On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov > wrote: > > > >> Hello everyone, > >> > >> After a few days of struggle with my degraded zpool on a backup server I > >> decided to ask for > >> help here or at least get some clues as to what might be wrong with it. > >> Here's the current state of the zpool: > >> > >> # zpool status > >> > >> pool: tank > >> state: DEGRADED > >> status: One or more devices has experienced an error resulting in data > >> corruption. Applications may be affected. > >> action: Restore the file in question if possible. Otherwise restore the > >> entire pool from backup. > >> see: http://www.sun.com/msg/ZFS-8000-8A > >> scrub: none requested > >> config: > >> > >> NAME STATE READ WRITE CKSUM > >> tank DEGRADED 0 0 0 > >> raidz1 DEGRADED 0 0 0 > >> spare DEGRADED 0 0 0 > >> replacing DEGRADED 0 0 0 > >> 17307041822177798519 UNAVAIL 0 299 0 was > >> /dev/gpt/disk-e1:s2 > >> gpt/newdisk-e1:s2 ONLINE 0 0 0 > >> gpt/disk-e2:s10 ONLINE 0 0 0 > >> gpt/disk-e1:s3 ONLINE 30 0 0 > >> gpt/disk-e1:s4 ONLINE 0 0 0 > >> gpt/disk-e1:s5 ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e1:s6 ONLINE 0 0 0 > >> gpt/disk-e1:s7 ONLINE 0 0 0 > >> gpt/disk-e1:s8 ONLINE 0 0 0 > >> gpt/disk-e1:s9 ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e1:s10 ONLINE 0 0 0 > >> gpt/disk-e1:s11 ONLINE 0 0 0 > >> gpt/disk-e1:s12 ONLINE 0 0 0 > >> gpt/disk-e1:s13 ONLINE 0 0 0 > >> raidz1 DEGRADED 0 0 0 > >> gpt/disk-e1:s14 ONLINE 0 0 0 > >> gpt/disk-e1:s15 ONLINE 0 0 0 > >> gpt/disk-e1:s16 ONLINE 0 0 0 > >> spare DEGRADED 0 0 0 > >> replacing DEGRADED 0 0 0 > >> 15258738282880603331 UNAVAIL 0 48 0 was > >> /dev/gpt/disk-e1:s17 > >> gpt/newdisk-e1:s17 ONLINE 0 0 0 > >> gpt/disk-e2:s11 ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e1:s18 ONLINE 0 0 0 > >> gpt/disk-e1:s19 ONLINE 0 0 0 > >> gpt/disk-e1:s20 ONLINE 0 0 0 > >> gpt/disk-e1:s21 ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e1:s22 ONLINE 0 0 0 > >> gpt/disk-e1:s23 ONLINE 0 0 0 > >> gpt/disk-e2:s0 ONLINE 0 0 0 > >> gpt/disk-e2:s1 ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e2:s2 ONLINE 0 0 0 > >> gpt/disk-e2:s3 ONLINE 0 0 0 > >> gpt/disk-e2:s4 ONLINE 0 0 0 > >> gpt/disk-e2:s5 ONLINE 0 0 0 > >> raidz1 ONLINE 0 0 0 > >> gpt/disk-e2:s6 ONLINE 0 0 0 > >> gpt/disk-e2:s7 ONLINE 0 0 0 > >> gpt/disk-e2:s8 ONLINE 0 0 0 > >> gpt/disk-e2:s9 ONLINE 0 0 0 > >> spares > >> gpt/disk-e2:s10 INUSE currently in use > >> gpt/disk-e2:s11 INUSE currently in use > >> gpt/disk-e1:s2 UNAVAIL cannot open > >> gpt/newdisk-e1:s17 INUSE currently in use > >> > >> errors: 4 data errors, use '-v' for a list > >> > >> > >> The problem is: after replacing the bad drives and resilvering the > old/bad > >> drives cannot be detached. > >> The replace command didn't remove it automatically and manual detach > fails. > >> Here are some examples: > >> > >> # zpool detach tank 15258738282880603331 > >> cannot detach 15258738282880603331: no valid replicas > >> # zpool detach tank gpt/disk-e2:s11 > >> cannot detach gpt/disk-e2:s11: no valid replicas > >> # zpool detach tank gpt/newdisk-e1:s17 > >> cannot detach gpt/newdisk-e1:s17: no valid replicas > >> # zpool detach tank gpt/disk-e1:s17 > >> cannot detach gpt/disk-e1:s17: no valid replicas > >> > >> > >> Here's more information and history of events. > >> This is a 36 disk SuperMicro 847 machine with 2T WD RE4 disks organized > in > >> raidz1 groups as > >> depicted above. zpool deals only with partitions like those: > >> > >> => 34 3904294845 mfid30 GPT (1.8T) > >> 34 3903897600 1 disk-e2:s9 (1.8T) > >> 3903897634 397245 - free - (194M) > >> > >> mfidXX devices are disks connected to a SuperMicro/LSI controller and > >> presented as jbods. JBODs in this adapter > >> are actually constructed as raid0 array of 1 disk but this should be > >> irrelevant in this case. > >> > >> This machine was working fine since September 6th but two of the disks > (in > >> different raidz1 vdevs) were going > >> pretty bad and accumulated quite a bit of errors until eventually they > >> died. This is how they looked like: > >> > >> raidz1 DEGRADED 0 0 0 > >> gpt/disk-e1:s2 UNAVAIL 44 59.5K 0 experienced I/O > >> failures > >> gpt/disk-e1:s3 ONLINE 0 0 0 > >> gpt/disk-e1:s4 ONLINE 0 0 0 > >> gpt/disk-e1:s5 ONLINE 0 0 0 > >> > >> raidz1 DEGRADED 0 0 0 > >> gpt/disk-e1:s14 ONLINE 0 0 0 > >> gpt/disk-e1:s15 ONLINE 0 0 0 > >> gpt/disk-e1:s16 ONLINE 0 0 0 > >> gpt/disk-e1:s17 UNAVAIL 1.56K 49.0K 0 experienced I/O > >> failures > >> > >> > >> I did have two spare disks ready to replace them. So after they died > here's > >> what I executed: > >> > >> # zpool replace tank gpt/disk-e1:s2 gpt/disk-e2:s10 > >> # zpool replace tank gpt/disk-e1:s17 gpt/disk-e2:s11 > >> > >> Resilvering started. While in the middle of it though the kernel paniced > >> and I had to reboot the machine. > >> After reboot I waited until the resilvering is complete. Now that it was > >> complete I expected to see the old/bad > >> device removed from the vdev but it was still there. Trying detach was > >> complaining with no valid replicas. > >> I sent colo technician to replace both those defective drives with brand > >> new ones. Once I had them inserted > >> I recreated them exactly the same way as the ones that I had before - > jbod > >> and gpart labeled partition with the > >> same name! Then I added them as spares: > >> > >> # zpool add tank spare gpt/disk-e1:s2 > >> # zpool add tank spare gpt/disk-e1:s17 > >> > >> That actually made it worse I think since now I had the same device name > >> both as a 'previous' failed device > >> inside the raidz1 group and as a hot spare spare device. I couldn't do > >> anything with it. > >> What I did was to export the pool fail the disk on the controller, > import > >> the pool and check that zfs could open > >> it anymore (as a part of the hot spares). Then I recreated that > >> disk/partition with a new label 'newdisk-XXX' > >> and tried to replace the device that originally failed (and was only > >> presented with a number). So I did this: > >> > >> # zpool replace tank gpt/disk-e1:s17 gpt/newdisk-e1:s17 > >> # zpool replace tank gpt/disk-e1:s2 gpt/newdisk-e1:s2 > >> > >> Resilvering completed after 17 hours or so and I expected for the > >> 'replacing' operation to disappear and the > >> replaced device to go away. But it didn't! Instead I have the state of > the > >> pool as shown in the beginning of > >> the email. > >> As for the 'errors: 4 data errors, use '-v' for a list' I suspect that > >> it's due another failing > >> device (gpt/disk-e1:s3) inside the first (currently degraded) raidz1 > vdev. > >> Those 4 corrupted files actually > >> could be read sometimes so that tells me that the disk has trouble > reading > >> *sometimes* those bad blocks. > >> > >> Here's the output of zdb -l tank > >> > >> version=14 > >> name='tank' > >> state=0 > >> txg=200225 > >> pool_guid=13504509992978610301 > >> hostid=409325918 > >> hostname='XXXX' > >> vdev_tree > >> type='root' > >> id=0 > >> guid=13504509992978610301 > >> children[0] > >> type='raidz' > >> id=0 > >> guid=3740854890192825394 > >> nparity=1 > >> metaslab_array=33 > >> metaslab_shift=36 > >> ashift=9 > >> asize=7995163410432 > >> is_log=0 > >> children[0] > >> type='spare' > >> id=0 > >> guid=16171901098004278313 > >> whole_disk=0 > >> children[0] > >> type='replacing' > >> id=0 > >> guid=2754550310390861576 > >> whole_disk=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=17307041822177798519 > >> path='/dev/gpt/disk-e1:s2' > >> whole_disk=0 > >> not_present=1 > >> DTL=246 > >> children[1] > >> type='disk' > >> id=1 > >> guid=1641394056824955485 > >> path='/dev/gpt/newdisk-e1:s2' > >> whole_disk=0 > >> DTL=55 > >> children[1] > >> type='disk' > >> id=1 > >> guid=13150356781300468512 > >> path='/dev/gpt/disk-e2:s10' > >> whole_disk=0 > >> is_spare=1 > >> DTL=1289 > >> children[1] > >> type='disk' > >> id=1 > >> guid=6047192237176807561 > >> path='/dev/gpt/disk-e1:s3' > >> whole_disk=0 > >> DTL=250 > >> children[2] > >> type='disk' > >> id=2 > >> guid=9178318500891071208 > >> path='/dev/gpt/disk-e1:s4' > >> whole_disk=0 > >> DTL=249 > >> children[3] > >> type='disk' > >> id=3 > >> guid=2567999855746767831 > >> path='/dev/gpt/disk-e1:s5' > >> whole_disk=0 > >> DTL=248 > >> children[1] > >> type='raidz' > >> id=1 > >> guid=17097047310177793733 > >> nparity=1 > >> metaslab_array=31 > >> metaslab_shift=36 > >> ashift=9 > >> asize=7995163410432 > >> is_log=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=14513380297393196654 > >> path='/dev/gpt/disk-e1:s6' > >> whole_disk=0 > >> DTL=266 > >> children[1] > >> type='disk' > >> id=1 > >> guid=7673391645329839273 > >> path='/dev/gpt/disk-e1:s7' > >> whole_disk=0 > >> DTL=265 > >> children[2] > >> type='disk' > >> id=2 > >> guid=15189132305590412134 > >> path='/dev/gpt/disk-e1:s8' > >> whole_disk=0 > >> DTL=264 > >> children[3] > >> type='disk' > >> id=3 > >> guid=17171875527714022076 > >> path='/dev/gpt/disk-e1:s9' > >> whole_disk=0 > >> DTL=263 > >> children[2] > >> type='raidz' > >> id=2 > >> guid=4551002265962803186 > >> nparity=1 > >> metaslab_array=30 > >> metaslab_shift=36 > >> ashift=9 > >> asize=7995163410432 > >> is_log=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=12104241519484712161 > >> path='/dev/gpt/disk-e1:s10' > >> whole_disk=0 > >> DTL=262 > >> children[1] > >> type='disk' > >> id=1 > >> guid=3950210349623142325 > >> path='/dev/gpt/disk-e1:s11' > >> whole_disk=0 > >> DTL=261 > >> children[2] > >> type='disk' > >> id=2 > >> guid=14559903955698640085 > >> path='/dev/gpt/disk-e1:s12' > >> whole_disk=0 > >> DTL=260 > >> children[3] > >> type='disk' > >> id=3 > >> guid=12364155114844220066 > >> path='/dev/gpt/disk-e1:s13' > >> whole_disk=0 > >> DTL=259 > >> children[3] > >> type='raidz' > >> id=3 > >> guid=12517231224568010294 > >> nparity=1 > >> metaslab_array=29 > >> metaslab_shift=36 > >> ashift=9 > >> asize=7995163410432 > >> is_log=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=7655789038925330983 > >> path='/dev/gpt/disk-e1:s14' > >> whole_disk=0 > >> DTL=258 > >> children[1] > >> type='disk' > >> id=1 > >> guid=17815755378968233141 > >> path='/dev/gpt/disk-e1:s15' > >> whole_disk=0 > >> DTL=257 > >> children[2] > >> type='disk' > >> id=2 > >> guid=9590421681925673767 > >> path='/dev/gpt/disk-e1:s16' > >> whole_disk=0 > >> DTL=256 > >> children[3] > >> type='spare' > >> id=3 > >> guid=4015417100051235398 > >> whole_disk=0 > >> children[0] > >> type='replacing' > >> id=0 > >> guid=11653429697330193176 > >> whole_disk=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=15258738282880603331 > >> path='/dev/gpt/disk-e1:s17' > >> whole_disk=0 > >> not_present=1 > >> DTL=255 > >> children[1] > >> type='disk' > >> id=1 > >> guid=908651380690954833 > >> path='/dev/gpt/newdisk-e1:s17' > >> whole_disk=0 > >> is_spare=1 > >> DTL=52 > >> children[1] > >> type='disk' > >> id=1 > >> guid=7250934196571906160 > >> path='/dev/gpt/disk-e2:s11' > >> whole_disk=0 > >> is_spare=1 > >> DTL=1292 > >> children[4] > >> type='raidz' > >> id=4 > >> guid=7622366288306613136 > >> nparity=1 > >> metaslab_array=28 > >> metaslab_shift=36 > >> ashift=9 > >> asize=7995163410432 > >> is_log=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=11283483106921343963 > >> path='/dev/gpt/disk-e1:s18' > >> whole_disk=0 > >> DTL=254 > >> children[1] > >> type='disk' > >> id=1 > >> guid=14900597968455968576 > >> path='/dev/gpt/disk-e1:s19' > >> whole_disk=0 > >> DTL=253 > >> children[2] > >> type='disk' > >> id=2 > >> guid=4140592611852504513 > >> path='/dev/gpt/disk-e1:s20' > >> whole_disk=0 > >> DTL=252 > >> children[3] > >> type='disk' > >> id=3 > >> guid=2794215380207576975 > >> path='/dev/gpt/disk-e1:s21' > >> whole_disk=0 > >> DTL=251 > >> children[5] > >> type='raidz' > >> id=5 > >> guid=17655293908271300889 > >> nparity=1 > >> metaslab_array=27 > >> metaslab_shift=36 > >> ashift=9 > >> asize=7995163410432 > >> is_log=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=5274146379037055039 > >> path='/dev/gpt/disk-e1:s22' > >> whole_disk=0 > >> DTL=278 > >> children[1] > >> type='disk' > >> id=1 > >> guid=8651755019404873686 > >> path='/dev/gpt/disk-e1:s23' > >> whole_disk=0 > >> DTL=277 > >> children[2] > >> type='disk' > >> id=2 > >> guid=16827379661759988976 > >> path='/dev/gpt/disk-e2:s0' > >> whole_disk=0 > >> DTL=276 > >> children[3] > >> type='disk' > >> id=3 > >> guid=2524967151333933972 > >> path='/dev/gpt/disk-e2:s1' > >> whole_disk=0 > >> DTL=275 > >> children[6] > >> type='raidz' > >> id=6 > >> guid=2413519694016115220 > >> nparity=1 > >> metaslab_array=26 > >> metaslab_shift=36 > >> ashift=9 > >> asize=7995163410432 > >> is_log=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=16361968944335143412 > >> path='/dev/gpt/disk-e2:s2' > >> whole_disk=0 > >> DTL=274 > >> children[1] > >> type='disk' > >> id=1 > >> guid=10054650477559530937 > >> path='/dev/gpt/disk-e2:s3' > >> whole_disk=0 > >> DTL=273 > >> children[2] > >> type='disk' > >> id=2 > >> guid=17105959045159531558 > >> path='/dev/gpt/disk-e2:s4' > >> whole_disk=0 > >> DTL=272 > >> children[3] > >> type='disk' > >> id=3 > >> guid=17370453969371497663 > >> path='/dev/gpt/disk-e2:s5' > >> whole_disk=0 > >> DTL=271 > >> children[7] > >> type='raidz' > >> id=7 > >> guid=4614010953103453823 > >> nparity=1 > >> metaslab_array=24 > >> metaslab_shift=36 > >> ashift=9 > >> asize=7995163410432 > >> is_log=0 > >> children[0] > >> type='disk' > >> id=0 > >> guid=10090128057592036175 > >> path='/dev/gpt/disk-e2:s6' > >> whole_disk=0 > >> DTL=270 > >> children[1] > >> type='disk' > >> id=1 > >> guid=16676544025008223925 > >> path='/dev/gpt/disk-e2:s7' > >> whole_disk=0 > >> DTL=269 > >> children[2] > >> type='disk' > >> id=2 > >> guid=11777789246954957292 > >> path='/dev/gpt/disk-e2:s8' > >> whole_disk=0 > >> DTL=268 > >> children[3] > >> type='disk' > >> id=3 > >> guid=3406600121427522915 > >> path='/dev/gpt/disk-e2:s9' > >> whole_disk=0 > >> DTL=267 > >> > >> OS: > >> 8.1-STABLE FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 amd64 > >> > >> Hardware: > >> Chassis: SuperMicro 847E1 (two backplanes 24 disks front and 12 > >> disks in the back) > >> Motherboard: X8SIL > >> CPU: 1 x X3430 @ 2.40GHz > >> RAM: 16G > >> HDD Controller: SuperMicro / LSI 9260 (pciconf -lv SAS1078 PCI-X > >> Fusion-MPT SAS) : 2 ports > >> Disks: 36 x 2T Western Digital RE4 > >> > >> > >> > >> Any help would be appreciated. Let me know what additional information I > >> should provide. > >> Thank you in advance, > >> -- > >> Rumen Telbizov > >> > >> > > > > > > -- > > Rumen Telbizov > > http://telbizov.com > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > > > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 06:16:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E2B4106564A; Thu, 28 Oct 2010 06:16:59 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 07C588FC13; Thu, 28 Oct 2010 06:16:58 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBLUI-000Ekh-E8; Thu, 28 Oct 2010 09:57:26 +0400 From: "Alexander Zagrebin" To: , Date: Thu, 28 Oct 2010 09:57:22 +0400 Message-ID: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Act2ZPxUz6rRUJtETk+Jz39oDL6cGA== Cc: Subject: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 06:16:59 -0000 Hi! I've noticed that ZFS on 8.1-STABLE still has problems with sendfile. When accessing a file at first time the transfer speed is too low, but on following attempts the transfer speed is normal. How to repeat: $ dd if=/dev/random of=/tmp/test bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec) $ sudo env LC_ALL=C /usr/libexec/ftpd -D The first attempt to fetch file: $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 1% of 100 MB 118 kBps 14m07s^C fetch: transfer interrupted The transfer rate is too low (approx. 120 kBps), but any subsequent attempts are success: $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 100% of 100 MB 42 MBps $ fetch -o /dev/null ftp://localhost/tmp/test /dev/null 100% of 100 MB 47 MBps ... To repeat it is enough to copy a file and to try again: $ cp /tmp/test /tmp/test1 $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 2% of 100 MB 119 kBps 13m50s^C fetch: transfer interrupted $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null ftp://localhost/tmp/test1 /dev/null 100% of 100 MB 47 MBps ...and again: $ cp /tmp/test1 /tmp/test2 $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 1% of 100 MB 118 kBps 14m07s^C fetch: transfer interrupted $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null ftp://localhost/tmp/test2 /dev/null 100% of 100 MB 47 MBps I've tried ftpd and nginx with "sendfile on". The behavior is the same. After disabling using sendfile in nginx ("sendfile off") the problem has gone. -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 07:30:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72BBA10656A3 for ; Thu, 28 Oct 2010 07:30:06 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1D37D8FC21 for ; Thu, 28 Oct 2010 07:30:05 +0000 (UTC) Received: from web49.yandex.ru (web49.yandex.ru [77.88.47.155]) by forward2.mail.yandex.net (Yandex) with ESMTP id 1C93C38A9B89; Thu, 28 Oct 2010 11:30:04 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1288251004; bh=3+lu+DxRUST62HYp6Lt4n6NJPw58e52ANquQId5cpno=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=WHdpS6vcX6hMXjyPzQAX0ocp4zoyk05BZqMlE/ZgmAouDlbx4wmvC3GMA5U4sZzOf IiYqt3qM4xpGSjU19X9N6JEQd777ahm+LZYgHhCdIeRglkk1gZgbkpXJGcQVgeY/jg eEaZR4JgpUmrHDGvgNh29z+ZLuLRpDdYUwXX8p+0= Received: from localhost (localhost.localdomain [127.0.0.1]) by web49.yandex.ru (Yandex) with ESMTP id 111D04E803D; Thu, 28 Oct 2010 11:30:04 +0400 (MSD) X-Yandex-Spam: 0 X-Yandex-Front: web49.yandex.ru X-Yandex-TimeMark: 1288251004 Received: from netman.spbcity.net (netman.spbcity.net [77.244.18.5]) by mail.yandex.ru with HTTP; Thu, 28 Oct 2010 11:30:01 +0400 From: S.N.Grigoriev To: Stefan Bethke In-Reply-To: <7FF9CDFF-3FA0-45EA-85F5-A236AEFC03C7@lassitu.de> References: <398231288212690@web127.yandex.ru> <7FF9CDFF-3FA0-45EA-85F5-A236AEFC03C7@lassitu.de> MIME-Version: 1.0 Message-Id: <313981288251001@web49.yandex.ru> Date: Thu, 28 Oct 2010 11:30:01 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-stable@freebsd.org Subject: Re: ZFS write speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 07:30:06 -0000 28.10.10, 01:54, "Stefan Bethke" : > Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: > > > Hi list, > > > > I've got very low write speed using ZFS on a SATA disk. > > My HDD configuration is: > > ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s > > ad6: 78532MB at ata3-master UDMA100 SATA 1.5Gb/s > > ad8: 1430799MB at ata4-master UDMA100 SATA 3Gb/s > > The EARS has 4k sectors, if I'm not mistaken. I don't recall the eventual > outcome, but there was a long thread on stable or hackers on how to ensure > proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't > have to do a read-modify-write cycle, so try and search the archives. Stefan, thank you for your response. I'll try to find the topic you pointed. > > ad4 and ad6 are single-slice disks (UFS2 with soft updates) > > > > ZFS configuration is following: > > zpool create Z ad8 > > zfs create Z/music > > zfs create Z/video > > All ZFS parameters are default. > > kern.maxvnodes = 1000000 > > > > To test my configuration I recursively copied from ad6 to ad8 two directories. > > The first one contains MP3 files (average size = 10MB). > > The second one contains AVI files (average size = 1GB). > > > > To compare performance I repeated above tests with ad8 using UFS2 with soft updates. > > > > 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. > > 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. > > > > I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. > > > > Any tips? > > > > -- -- Regards, Serguey. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 10:09:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 642A31065672; Thu, 28 Oct 2010 10:09:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4445C8FC16; Thu, 28 Oct 2010 10:09:09 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 7477E56027; Thu, 28 Oct 2010 09:50:21 +0000 (UTC) Date: Thu, 28 Oct 2010 09:50:21 +0000 From: Mark Linimon To: John Baldwin Message-ID: <20101028095021.GB393@lonesome.com> References: <20101027074401.GA18014@icarus.home.lan> <201010270927.04145.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010270927.04145.jhb@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: pjd@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick , freebsd-arch@freebsd.org Subject: Re: Can't build boot blocks after new GPT attributes added X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 10:09:09 -0000 On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: > Maybe you could add text to the handbook to say this, but it is already > implicitly assumed in the handbook section you are referring to since it > assumes you can safely compile a new kernel, etc. [...] If we were to > document those every time it would clutter documentation making it harder for > someone who is new to FreeBSD to simply setup a serial console on a box that > they just installed. It sounds like what we need is a tutorial, and (somewhere else?) the extended version. People seem to trip over things like this fairly often; at least this way we could refer them to a standard text. No, I don't have the backgroud, or cycles, to write it :-) mcl From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 12:15:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCCC4106564A for ; Thu, 28 Oct 2010 12:15:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3032F8FC1E for ; Thu, 28 Oct 2010 12:15:15 +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 PAA13848; Thu, 28 Oct 2010 15:15:11 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CC9694E.9020204@icyb.net.ua> Date: Thu, 28 Oct 2010 15:15:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Jakub Lach References: <29978939.post@talk.nabble.com> <4cc69e5f.gNWjuvNN/eQJQ0Qi%Joerg.Schilling@fokus.fraunhofer.de> <30056250.post@talk.nabble.com> <30071221.post@talk.nabble.com> In-Reply-To: <30071221.post@talk.nabble.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 12:15:16 -0000 on 28/10/2010 00:08 Jakub Lach said the following: > > > Sean C. Farley-2 wrote: >> >> For me, the solution appeared to be setting the grace time to three >> seconds to avoid the slowdown of the drive: gracetime=3 >> At least, the disc worked on subsequent burns this way. Jakub, you may >> try to see if this setting helps. >> > > No, gracetime doesn't help. Maybe Alexander Motin could > shed some light on (ahci?) problem? So maybe it's worth while getting in contact with him? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 12:49:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 789B3106564A for ; Thu, 28 Oct 2010 12:49:00 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 33D428FC1A for ; Thu, 28 Oct 2010 12:48:59 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id DF1659416C; Thu, 28 Oct 2010 14:48:57 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 5D9AC9418C; Thu, 28 Oct 2010 14:48:56 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o9SCmutm010601; Thu, 28 Oct 2010 14:48:56 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Oct 2010 14:48:56 +0200 Date: Thu, 28 Oct 2010 14:48:56 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: freebsd-stable@freebsd.org, jakub_lach@mailplus.pl Message-ID: <4cc97138.Wgb2gWzIsaEluoVM%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Oct 2010 12:48:56.0186 (UTC) FILETIME=[7BAA4DA0:01CB769E] Cc: Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 12:49:00 -0000 Hi, your problem: >Track 01: 0 of 2858 MB written.cdrecord: Input/output error. write_g1: >scsi sendcmd: retryable error >CDB: 2A 00 00 00 00 00 00 00 20 00 >status: 0x2 (CHECK CONDITION) >Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00 00 00 00 >Sense Key: 0xFFFFFFFF [], Segment 0 >Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 >Sense flags: Blk 0 (not valid)=20 >cmd finished after 23.946s timeout 200s is caused by a bug in a driver in the kernel. Status byte == 2 (Check Condition) together with empty sense data and unset sense key is impossible. Cdrecord can only behave in a useful way if SCSI error messages are correctly returned by the kernel. I recommend you to run "scgcheck" in order to find whether the driver yiu are using always behaves incorectly or whether this may be a result os a situation the autor of the driver did not expect. If you don't know how to run scgcheck, you may start with "scgcheck -auto". Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 15:20:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E6710656AE for ; Thu, 28 Oct 2010 15:20:40 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE048FC17 for ; Thu, 28 Oct 2010 15:20:37 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PBUHM-00083z-AH for freebsd-stable@freebsd.org; Thu, 28 Oct 2010 08:20:36 -0700 Message-ID: <30077727.post@talk.nabble.com> Date: Thu, 28 Oct 2010 08:20:36 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: <4cc97138.Wgb2gWzIsaEluoVM%Joerg.Schilling@fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: jakub_lach@mailplus.pl References: <29978939.post@talk.nabble.com> <4cc97138.Wgb2gWzIsaEluoVM%Joerg.Schilling@fokus.fraunhofer.de> Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:20:40 -0000 > So maybe it's worth while getting in contact with him? I wanted to confirm problem is related to ahci before=20 bugging him directly.=20 I'm long time ahci user and would like to retain it, it would be nice If somebody with working cdrecord=20 would load ahci for a test (by default it's not used in=20 GENERIC) + run scgcheck. Scgcheck 3.00 (amd64-unknown-freebsd8.1) SCSI user level transport library ABI checker. Copyright (C) 1998-2008 J=C3=B6rg Schilling **********> Checking whether your implementation supports to scan the SCSI bus. Trying to open device: '(NULL POINTER)'. Using libscg version 'schily-0.9' Max DMA buffer size: 65536 scsibus0: 0,0,0 0) '' '' '' NON CCS Disk 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) 'HL-DT-ST' 'DVDRAM GSA-U20N ' 'HX11' Removable CD-ROM 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * ----------> SCSI scan bus test PASSED For the next test we need to open a single SCSI device. Best results will be obtained if you specify a modern CD-ROM drive. No target specified, trying to find one... Using dev=3D1,0,0. Enter SCSI device name [1,0,0]:=20 Trying to open device: '1,0,0'. Using libscg version 'schily-0.9' Max DMA buffer size: 65536 Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities :=20 Vendor_info : 'HL-DT-ST' Identifikation : 'DVDRAM GSA-U20N ' Revision : 'HX11' Ready to start test for second SCSI open? Enter to continue:=20 First SCSI open OK - device usable **********> Checking for second SCSI open. Second SCSI open for same device succeeded, 1 additional file descriptor(s) used. Second SCSI open is usable Closing second SCSI. Checking first SCSI. First SCSI open is still usable ----------> Second SCSI open test PASSED. First SCSI open is still usable Ready to start test for succeeded command? Enter to continue:=20 **********> Checking for succeeded SCSI command. Executing 'inquiry' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cmd finished after 0.001s timeout 40s Inquiry Data : 05 80 00 32 5B 00 00 00 48 4C 2D 44 54 2D 53 54 44 56 44 5= 2 41 4D 20 47 53 41 2D 55 32 30 4E 20 48 58 31 31 ----------> SCSI succeeded command test PASSED Ready to start test for failing command? Enter to continue:=20 **********> Testing for failed SCSI command. scgcheck: Input/output error. inquiry: scsi sendcmd: retryable error CDB: 12 00 00 FF 24 00 status: 0x0 (GOOD STATUS) cmd finished after 0.013s timeout 40s ----------> SCSI Transport return !=3D SCG_NO_ERROR (1) ----------> SCSI status byte set to 0 (0x0) ----------> SCSI failed command test FAILED Ready to start test for sense data count? Enter to continue:=20 **********> Testing for SCSI sense data count. **********> Testing if at least CCS_SENSE_LEN (18) is supported... Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------> Method 0x00: expected: 18 reported: 32 max found: 0 Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------> Method 0xFF: expected: 18 reported: 32 max found: 18 ----------> Wanted 18 sense bytes, got it. ----------> Libscg says 32 sense bytes but got (18) **********> Testing for 32 bytes of sense data... Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------> Method 0x00: expected: 32 reported: 32 max found: 0 Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------> Method 0xFF: expected: 32 reported: 32 max found: 32 ----------> Wanted 32 sense bytes, got it. ----------> Got a maximum of 32 sense bytes ----------> SCSI sense count test FAILED Ready to start test for working DMA residual count? Enter to continue:= =20 **********> Testing for working DMA residual count. **********> Testing for working DMA residual count =3D=3D 0. CDB cnt: 36 DMA cnt: 36 got really: 36 (System says: RDMA cnt: 36 resid 0) CDB cnt: 36 DMA cnt: 36 got really: 36 (System says: RDMA cnt: 36 resid 0) ----------> Wanted 36 bytes, got it. ----------> SCSI DMA residual count =3D=3D 0 test PASSED Ready to start test for working DMA residual count =3D=3D DMA count? Enter = to continue:=20 CDB cnt: 0 DMA cnt: 36 got really: 0 (System says: RDMA cnt: 36 resid 0) CDB cnt: 0 DMA cnt: 36 got really: 0 (System says: RDMA cnt: 36 resid 0) ----------> Wanted 0 bytes, got it. ----------> Libscg says 36 bytes but got (0) ----------> SCSI DMA residual count =3D=3D DMA count test FAILED ----------> SCSI DMA residual count not working - no further tests ----------> SCSI transport code test NOT YET READY regards,=20 - Jakub Lach --=20 View this message in context: http://old.nabble.com/cdrtools--devel-and-wod= im-broken-tp29978939p30077727.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 15:24:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2C08106566C; Thu, 28 Oct 2010 15:24:53 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 697888FC1D; Thu, 28 Oct 2010 15:24:53 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PBULT-0003Ra-CD; Thu, 28 Oct 2010 16:24:51 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBULT-000NAu-BN; Thu, 28 Oct 2010 16:24:51 +0100 Date: Thu, 28 Oct 2010 16:24:51 +0100 Message-Id: To: to.my.trociny@gmail.com In-Reply-To: <86wrp3wj67.fsf@kopusha.home.net> From: Pete French Cc: pjd@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:24:53 -0000 > In hast_proto_send() we send header and then data. Couldn't it be that > remote_send and sync threads interfere and their packets are mixed? May be > some synchronization is needed here? Interesting - I haven't looked very closely at the code, but I didn't realise that more than one thread was in communication with the remote end. If that's true then theres always a possibility for mixed data if you are sending it in chunks surely ? > I set sleep(1) in hast_proto_send() between proto_send(header) and > proto_send(data). The error started to occur frequently. Where is the potential other write occuring ? I might try wrapping some locking round the calls to see what happens. -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 16:31:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A660A1065693 for ; Thu, 28 Oct 2010 16:31:21 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 450A48FC28 for ; Thu, 28 Oct 2010 16:31:20 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E095A45CAC; Thu, 28 Oct 2010 18:31:18 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C1A1F45685; Thu, 28 Oct 2010 18:31:12 +0200 (CEST) Date: Thu, 28 Oct 2010 18:30:36 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101028163036.GA2347@garage.freebsd.pl> References: <86wrp3wj67.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <86wrp3wj67.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 16:31:21 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 10:05:20PM +0300, Mikolaj Golub wrote: > In hast_proto_send() we send header and then data. Couldn't it be that > remote_send and sync threads interfere and their packets are mixed? May b= e some > synchronization is needed here? >=20 > I set sleep(1) in hast_proto_send() between proto_send(header) and > proto_send(data). The error started to occur frequently. Synchronization requests are sent through the remote thread just like regular I/O requests, exactly because of races that can occur. I looked at the code and the keepalive packets arbe sent from another thread. Could you try turning them off in primary.c and see if that helps? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzJpSwACgkQForvXbEpPzSqfwCdEOoi4BV1Iu0NiRrybQvnrdKG rU8AoLZfOONZqaiXOSBdUO5XP9bWEOMi =B6zi -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 17:25:10 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14AA21065673 for ; Thu, 28 Oct 2010 17:25:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 92EB38FC12 for ; Thu, 28 Oct 2010 17:25:09 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D973341C7B1; Thu, 28 Oct 2010 19:25:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id qP2yrWqLyANr; Thu, 28 Oct 2010 19:25:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id CA41341C75B; Thu, 28 Oct 2010 19:25:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id CD1D94448F3; Thu, 28 Oct 2010 17:23:48 +0000 (UTC) Date: Thu, 28 Oct 2010 17:23:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mike Tancsa In-Reply-To: <201010221425.o9MEPcWC094867@lava.sentex.ca> Message-ID: <20101028172230.O66242@maildrop.int.zabbadoz.net> References: <201010221416.o9MEGSa0094817@lava.sentex.ca> <201010221425.o9MEPcWC094867@lava.sentex.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , stable Subject: Re: repeating crashes with 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:25:10 -0000 On Fri, 22 Oct 2010, Mike Tancsa wrote: Hi Randy, Mike, > At 10:18 AM 10/22/2010, Randy Bush wrote: >> > Do you know how this panic is triggered ? Are you able to >> > create it on demand ? >> >> no i do not. bring server up and it'll happen in half an hour. >> >> and the server was happy for two months. so i am thinking hardware. > > Perhaps. The reason I ask is that I had a box go down last night with the > same set of errors. The box has a number of ipv6 routes, but its next hop > was down and the problems started soon after. So I wonder if it has something > to do with that. Do you have ipv6 on this box and are all the next hop > addresses correct / reachable ? > > Oct 22 02:06:02 i4 kernel: em1: discard frame w/o packet header > Oct 22 02:06:10 i4 kernel: em2: discard frame w/o packet header > Oct 22 02:06:21 i4 kernel: em1: discard frame w/o packet header Just a shot in the dark, as I got another private report just now on this one; is any of you by chance running VLANs on the systems you see this happening? /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 17:31:19 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B57E1065674 for ; Thu, 28 Oct 2010 17:31:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 91A3B8FC1F for ; Thu, 28 Oct 2010 17:31:18 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o9SHVGZa071753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Oct 2010 13:31:16 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.4) with ESMTP id o9SHVF50055238; Thu, 28 Oct 2010 13:31:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201010281731.o9SHVF50055238@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Oct 2010 13:31:11 -0400 To: "Bjoern A. Zeeb" From: Mike Tancsa In-Reply-To: <20101028172230.O66242@maildrop.int.zabbadoz.net> References: <201010221416.o9MEGSa0094817@lava.sentex.ca> <201010221425.o9MEPcWC094867@lava.sentex.ca> <20101028172230.O66242@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Randy Bush , stable Subject: Re: repeating crashes with 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:31:19 -0000 At 01:23 PM 10/28/2010, Bjoern A. Zeeb wrote: >On Fri, 22 Oct 2010, Mike Tancsa wrote: > >Hi Randy, Mike, > >>At 10:18 AM 10/22/2010, Randy Bush wrote: >>> > Do you know how this panic is triggered ? Are you able to >>> > create it on demand ? >>>no i do not. bring server up and it'll happen in half an hour. >>>and the server was happy for two months. so i am thinking hardware. >> >>Perhaps. The reason I ask is that I had a box go down last night >>with the same set of errors. The box has a number of ipv6 routes, >>but its next hop was down and the problems started soon after. So I >>wonder if it has something to do with that. Do you have ipv6 on >>this box and are all the next hop addresses correct / reachable ? >> >>Oct 22 02:06:02 i4 kernel: em1: discard frame w/o packet header >>Oct 22 02:06:10 i4 kernel: em2: discard frame w/o packet header >>Oct 22 02:06:21 i4 kernel: em1: discard frame w/o packet header > >Just a shot in the dark, as I got another private report just now >on this one; is any of you by chance running VLANs on the systems >you see this happening? Hi Bjoern, On the machine that original crashed for me ? yes there are vlans on it, but the path in question was going across a native interface. But when zoo crashed, there were no vlans defined on the box at all. ---Mike From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 17:44:13 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 141C3106564A for ; Thu, 28 Oct 2010 17:44:13 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id EE2068FC0A for ; Thu, 28 Oct 2010 17:44:12 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBWWD-000LHC-4h; Thu, 28 Oct 2010 17:44:05 +0000 Date: Fri, 29 Oct 2010 02:44:03 +0900 Message-ID: From: Randy Bush To: "Bjoern A. Zeeb" In-Reply-To: <20101028172230.O66242@maildrop.int.zabbadoz.net> References: <201010221416.o9MEGSa0094817@lava.sentex.ca> <201010221425.o9MEPcWC094867@lava.sentex.ca> <20101028172230.O66242@maildrop.int.zabbadoz.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: stable Subject: Re: repeating crashes with 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:44:13 -0000 > Just a shot in the dark, as I got another private report just now on > this one; is any of you by chance running VLANs on the systems you see > this happening? no vlans on the two affected systems here randy From owner-freebsd-stable@FreeBSD.ORG Thu Oct 28 19:09:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4647610656E6; Thu, 28 Oct 2010 19:09:03 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 592B68FC18; Thu, 28 Oct 2010 19:09:02 +0000 (UTC) Received: by fxm17 with SMTP id 17so2336702fxm.13 for ; Thu, 28 Oct 2010 12:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=NwwnU+vG+8HYiZTqzSe3OwHgfEAVFDR6xud94IXxuJI=; b=XezIxyxQ3duH6Vz4ZpHQ97PW+rCehD88c2m5PlLjr/v2SjGsM2LlwpktbLomVlhEoT IjW7o0kXv22dEnHbF5uKTtwL5N/3LcBi12he9y6A9kBs6/nG/GMhDbxOuLEYxWOvWAh+ shXOfunVdz2558+V4UeoB65EQXOE/43K8InFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=qj+MOIsEFExWqJ3RKplqJcruSHXp7XdeGHThZlVnct2KbTtDzq2OeBtESjMnbRbpNA Byp7aYOHKqnXV+sPVUxnZEXBghZpnrm1riUSEvI21Trav4vuH5a676Iy4wSb/4ZxfWlW kXooRg6+5FiU7Q5ICMUDizY0kdJSy1BYb/XGs= Received: by 10.223.89.136 with SMTP id e8mr4420474fam.139.1288292940677; Thu, 28 Oct 2010 12:09:00 -0700 (PDT) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id b15sm662279fah.28.2010.10.28.12.08.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 12:08:59 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek References: <86wrp3wj67.fsf@kopusha.home.net> <20101028163036.GA2347@garage.freebsd.pl> X-Comment-To: Pawel Jakub Dawidek Date: Thu, 28 Oct 2010 22:08:54 +0300 In-Reply-To: <20101028163036.GA2347@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Thu, 28 Oct 2010 18:30:36 +0200") Message-ID: <86lj5i3zjt.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org, Mikolaj Golub , Pete French Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 19:09:03 -0000 On Thu, 28 Oct 2010 18:30:36 +0200 Pawel Jakub Dawidek wrote: PJD> On Wed, Oct 27, 2010 at 10:05:20PM +0300, Mikolaj Golub wrote: >> In hast_proto_send() we send header and then data. Couldn't it be that >> remote_send and sync threads interfere and their packets are mixed? May be some >> synchronization is needed here? >> >> I set sleep(1) in hast_proto_send() between proto_send(header) and >> proto_send(data). The error started to occur frequently. PJD> Synchronization requests are sent through the remote thread just like PJD> regular I/O requests, exactly because of races that can occur. PJD> I looked at the code and the keepalive packets arbe sent from another PJD> thread. Could you try turning them off in primary.c and see if that PJD> helps? At first I set RETRY_SLEEP to 1 sec to have more keepalive packets. The errors started to observe frequently: Oct 28 21:35:53 bolek hastd[1709]: [storage] (secondary) Unable to receive request header: RPC version wrong. Oct 28 21:35:54 bolek hastd[1632]: [storage] (secondary) Worker process exited ungracefully (pid=1709, exitcode=75). Oct 28 21:36:12 bolek hastd[1722]: [storage] (secondary) Unable to receive request header: RPC version wrong. Oct 28 21:36:12 bolek hastd[1632]: [storage] (secondary) Worker process exited ungracefully (pid=1722, exitcode=75). ... Now I have been running synchronization for more then a half an hour with keepalive_send disabled and have not seen any error. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 02:15:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22066106564A for ; Fri, 29 Oct 2010 02:15:20 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1CA8FC0C for ; Fri, 29 Oct 2010 02:15:19 +0000 (UTC) Received: by qwg8 with SMTP id 8so576291qwg.13 for ; Thu, 28 Oct 2010 19:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WgSvEvUqvuinFeTDp2XQWSWQRuwSpo1Mq2xzfJO8PAo=; b=m+bDPhHfl1VtOLZQlbiAvnrY+iRlYaYqgSOA9qtlZCNfByRLnZzi/GXEgMB2qIYLoH UjdqG2Vn9eb6p6FwWz9h8RYsuR5SzvqPkPFxI6S+4ROfS4bdmY/78z3ysDEAfMlnDeTa kkVj9ZlcaMKxYb3hKCHPbQGdn6Yeq9d24/wEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Cx2NaLmFz6JRHeQdPE6f7t809vv7om1Y58fS2ewfowOGzN9aGg77KIeJLrXvqnwDsT u/gxEzFl4ODtqhk/dc081aUGvL308CLhSJjmSNSs1oEzbM3F904xX5Y7HxcejCflfK2C FWC0Es5SDYMyrBJ8lzI9KWdEYw1cbLRFBGRuA= MIME-Version: 1.0 Received: by 10.229.215.8 with SMTP id hc8mr4641716qcb.23.1288318518588; Thu, 28 Oct 2010 19:15:18 -0700 (PDT) Received: by 10.229.110.12 with HTTP; Thu, 28 Oct 2010 19:15:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Oct 2010 19:15:18 -0700 Message-ID: From: Rumen Telbizov To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 02:15:20 -0000 Hello Artem, everyone, Here's an update on my case. After following Artem's advice I downloaded OpenSolaris 2009 06 LiveCD and booted (over IPMI share) from it. Aliasing the proper disk driver I got access to all JBOD disks that I had before. They had different names (OpenSolaris style) but order and configuration seemed fine. I was in fact able to remove those old/nonexisting devices from OpenSolaris without a problem with the same commands that I was using under FreeBSD. The pool started resilvering which wasn't that important at that stage. So I exported the pool and rebooted back into FreeBSD. FreeBSD saw the pool and I managed to mount it fine. All the data was there and resilvering was initiated. There is a problem though. Initially I used gpt labeled partitions to construct the pool. They had names like /dev/gpt/disk-e1:s15 for example and represented a gpt partition on top of a mfidXX device underneat. Now before I import the pool I do see them in /dev/gpt just fine like that: # ls /dev/gpt disk-e1:s10 disk-e1:s11 disk-e1:s12 disk-e1:s13 disk-e1:s14 disk-e1:s15 disk-e1:s16 disk-e1:s18 disk-e1:s19 disk-e1:s20 disk-e1:s21 disk-e1:s22 disk-e1:s23 disk-e1:s3 disk-e1:s4 disk-e1:s5 disk-e1:s6 disk-e1:s7 disk-e1:s8 disk-e1:s9 disk-e2:s0 disk-e2:s1 disk-e2:s10 disk-e2:s11 disk-e2:s2 disk-e2:s3 disk-e2:s4 disk-e2:s5 disk-e2:s6 disk-e2:s7 disk-e2:s8 disk-e2:s9 newdisk-e1:s17 newdisk-e1:s2 But *after* zpool import tank I get a bunch of messages like those (after enabling kern.geom.label.debug) kernel: GEOM_LABEL[1]: Label gptid/a7fb11e8-dfc9-11df-8732-002590087f3a removed. kernel: GEOM_LABEL[1]: Label gpt/newdisk-e1:s2 removed. kernel: GEOM_LABEL[1]: Label gptid/7a36f6f3-b9fd-11df-8105-002590087f3a removed. kernel: GEOM_LABEL[1]: Label gpt/disk-e1:s3 removed. kernel: GEOM_LABEL[1]: Label gptid/7a92d827-b9fd-11df-8105-002590087f3a removed. kernel: GEOM_LABEL[1]: Label gpt/disk-e1:s4 removed. ... and pretty much all of the gpt labels are gone from /dev/gpt. What I have left there is: disk-e1:s10 disk-e1:s20 disk-e2:s0 So my zpool actually falls back somehow to using the mfidXXp1 partition directly instead of the gpt label. Here's how the pool looks like while imported: # zpool status pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h3m, 0.38% done, 16h35m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid33p1 ONLINE 0 0 0 4.18G resilvered mfid1p1 ONLINE 0 0 0 28.8M resilvered mfid2p1 ONLINE 0 0 0 28.0M resilvered mfid3p1 ONLINE 0 0 0 18.4M resilvered raidz1 ONLINE 0 0 0 mfid4p1 ONLINE 0 0 0 mfid5p1 ONLINE 0 0 0 mfid6p1 ONLINE 0 0 0 mfid7p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s10 ONLINE 0 0 0 mfid9p1 ONLINE 0 0 0 mfid10p1 ONLINE 0 0 0 mfid11p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid12p1 ONLINE 0 0 0 27.8M resilvered mfid13p1 ONLINE 0 0 0 27.8M resilvered mfid14p1 ONLINE 0 0 0 27.0M resilvered mfid34p1 ONLINE 0 0 0 4.14G resilvered raidz1 ONLINE 0 0 0 mfid15p1 ONLINE 0 0 0 mfid16p1 ONLINE 0 0 0 gpt/disk-e1:s20 ONLINE 0 0 0 mfid18p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid19p1 ONLINE 0 0 0 mfid20p1 ONLINE 0 0 0 gpt/disk-e2:s0 ONLINE 0 0 0 mfid22p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid23p1 ONLINE 0 0 0 mfid24p1 ONLINE 0 0 0 mfid25p1 ONLINE 0 0 0 mfid26p1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 mfid27p1 ONLINE 0 0 0 mfid28p1 ONLINE 0 0 0 mfid29p1 ONLINE 0 0 0 mfid30p1 ONLINE 0 0 0 spares mfid32p1 AVAIL mfid31p1 AVAIL Notice that 3 of the devices are actually still used as gpt/ labels. Also device numbers changed. If I zpool export tank my pool all the /dev/gpt/disk-XX devices come back. *While* having the pool imported I can still see that all the devices with gpart show: # gpart show -l => 34 3904294845 mfid1 GPT (1.8T) 34 3903897600 1 disk-e1:s3 (1.8T) 3903897634 397245 - free - (194M) => 34 3904294845 mfid2 GPT (1.8T) 34 3903897600 1 disk-e1:s4 (1.8T) 3903897634 397245 - free - (194M) => 34 3904294845 mfid3 GPT (1.8T) 34 3903897600 1 disk-e1:s5 (1.8T) 3903897634 397245 - free - (194M) => 34 3904294845 mfid4 GPT (1.8T) 34 3903897600 1 disk-e1:s6 (1.8T) 3903897634 397245 - free - (194M) ... snip snip all the disks are here snip snip ... => 34 3904294845 mfid33 GPT (1.8T) 34 3903897600 1 newdisk-e1:s2 (1.8T) 3903897634 397245 - free - (194M) => 34 3904294845 mfid34 GPT (1.8T) 34 3903897600 1 newdisk-e1:s17 (1.8T) 3903897634 397245 - free - (194M) but only those 3 devices in /dev/gpt and absolutely nothing in /dev/gptid/ So is there a way to bring all the gpt labeled partitions back into the pool instead of using the mfidXX devices? Any help is highly appreciated. I can provide any additional information you may need. Thank you, Rumen Telbizov On Wed, Oct 27, 2010 at 6:05 PM, Rumen Telbizov wrote: > Thanks Artem, > > I am mainly concerned about fixing this immediate problem first and then if > I > can provide more information for the developers so that they look into this > problem > I'd be happy to. > > I'll try OpenSolaris live CD and see how it goes. Either way I'll report > back here. > > Cheers, > Rumen Telbizov > > > On Wed, Oct 27, 2010 at 5:22 PM, Artem Belevich wrote: > >> Are you interested in what's wrong or in how to fix it? >> >> If fixing is the priority, I'd boot from OpenSolaris live CD and would >> try importing the array there. Just make sure you don't upgrade ZFS to >> a version that is newer than the one FreeBSD supports. >> >> Opensolaris may be able to fix the array. Once it's done, export it, >> boot back to FreeBSD and re-import it. >> >> --Artem >> >> >> >> On Wed, Oct 27, 2010 at 4:22 PM, Rumen Telbizov >> wrote: >> > No ideas whatsoever? >> > >> > On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov >> wrote: >> > >> >> Hello everyone, >> >> >> >> After a few days of struggle with my degraded zpool on a backup server >> I >> >> decided to ask for >> >> help here or at least get some clues as to what might be wrong with it. >> >> Here's the current state of the zpool: >> >> >> >> # zpool status >> >> >> >> pool: tank >> >> state: DEGRADED >> >> status: One or more devices has experienced an error resulting in data >> >> corruption. Applications may be affected. >> >> action: Restore the file in question if possible. Otherwise restore >> the >> >> entire pool from backup. >> >> see: http://www.sun.com/msg/ZFS-8000-8A >> >> scrub: none requested >> >> config: >> >> >> >> NAME STATE READ WRITE CKSUM >> >> tank DEGRADED 0 0 0 >> >> raidz1 DEGRADED 0 0 0 >> >> spare DEGRADED 0 0 0 >> >> replacing DEGRADED 0 0 0 >> >> 17307041822177798519 UNAVAIL 0 299 0 was >> >> /dev/gpt/disk-e1:s2 >> >> gpt/newdisk-e1:s2 ONLINE 0 0 0 >> >> gpt/disk-e2:s10 ONLINE 0 0 0 >> >> gpt/disk-e1:s3 ONLINE 30 0 0 >> >> gpt/disk-e1:s4 ONLINE 0 0 0 >> >> gpt/disk-e1:s5 ONLINE 0 0 0 >> >> raidz1 ONLINE 0 0 0 >> >> gpt/disk-e1:s6 ONLINE 0 0 0 >> >> gpt/disk-e1:s7 ONLINE 0 0 0 >> >> gpt/disk-e1:s8 ONLINE 0 0 0 >> >> gpt/disk-e1:s9 ONLINE 0 0 0 >> >> raidz1 ONLINE 0 0 0 >> >> gpt/disk-e1:s10 ONLINE 0 0 0 >> >> gpt/disk-e1:s11 ONLINE 0 0 0 >> >> gpt/disk-e1:s12 ONLINE 0 0 0 >> >> gpt/disk-e1:s13 ONLINE 0 0 0 >> >> raidz1 DEGRADED 0 0 0 >> >> gpt/disk-e1:s14 ONLINE 0 0 0 >> >> gpt/disk-e1:s15 ONLINE 0 0 0 >> >> gpt/disk-e1:s16 ONLINE 0 0 0 >> >> spare DEGRADED 0 0 0 >> >> replacing DEGRADED 0 0 0 >> >> 15258738282880603331 UNAVAIL 0 48 0 was >> >> /dev/gpt/disk-e1:s17 >> >> gpt/newdisk-e1:s17 ONLINE 0 0 0 >> >> gpt/disk-e2:s11 ONLINE 0 0 0 >> >> raidz1 ONLINE 0 0 0 >> >> gpt/disk-e1:s18 ONLINE 0 0 0 >> >> gpt/disk-e1:s19 ONLINE 0 0 0 >> >> gpt/disk-e1:s20 ONLINE 0 0 0 >> >> gpt/disk-e1:s21 ONLINE 0 0 0 >> >> raidz1 ONLINE 0 0 0 >> >> gpt/disk-e1:s22 ONLINE 0 0 0 >> >> gpt/disk-e1:s23 ONLINE 0 0 0 >> >> gpt/disk-e2:s0 ONLINE 0 0 0 >> >> gpt/disk-e2:s1 ONLINE 0 0 0 >> >> raidz1 ONLINE 0 0 0 >> >> gpt/disk-e2:s2 ONLINE 0 0 0 >> >> gpt/disk-e2:s3 ONLINE 0 0 0 >> >> gpt/disk-e2:s4 ONLINE 0 0 0 >> >> gpt/disk-e2:s5 ONLINE 0 0 0 >> >> raidz1 ONLINE 0 0 0 >> >> gpt/disk-e2:s6 ONLINE 0 0 0 >> >> gpt/disk-e2:s7 ONLINE 0 0 0 >> >> gpt/disk-e2:s8 ONLINE 0 0 0 >> >> gpt/disk-e2:s9 ONLINE 0 0 0 >> >> spares >> >> gpt/disk-e2:s10 INUSE currently in use >> >> gpt/disk-e2:s11 INUSE currently in use >> >> gpt/disk-e1:s2 UNAVAIL cannot open >> >> gpt/newdisk-e1:s17 INUSE currently in use >> >> >> >> errors: 4 data errors, use '-v' for a list >> >> >> >> >> >> The problem is: after replacing the bad drives and resilvering the >> old/bad >> >> drives cannot be detached. >> >> The replace command didn't remove it automatically and manual detach >> fails. >> >> Here are some examples: >> >> >> >> # zpool detach tank 15258738282880603331 >> >> cannot detach 15258738282880603331: no valid replicas >> >> # zpool detach tank gpt/disk-e2:s11 >> >> cannot detach gpt/disk-e2:s11: no valid replicas >> >> # zpool detach tank gpt/newdisk-e1:s17 >> >> cannot detach gpt/newdisk-e1:s17: no valid replicas >> >> # zpool detach tank gpt/disk-e1:s17 >> >> cannot detach gpt/disk-e1:s17: no valid replicas >> >> >> >> >> >> Here's more information and history of events. >> >> This is a 36 disk SuperMicro 847 machine with 2T WD RE4 disks organized >> in >> >> raidz1 groups as >> >> depicted above. zpool deals only with partitions like those: >> >> >> >> => 34 3904294845 mfid30 GPT (1.8T) >> >> 34 3903897600 1 disk-e2:s9 (1.8T) >> >> 3903897634 397245 - free - (194M) >> >> >> >> mfidXX devices are disks connected to a SuperMicro/LSI controller and >> >> presented as jbods. JBODs in this adapter >> >> are actually constructed as raid0 array of 1 disk but this should be >> >> irrelevant in this case. >> >> >> >> This machine was working fine since September 6th but two of the disks >> (in >> >> different raidz1 vdevs) were going >> >> pretty bad and accumulated quite a bit of errors until eventually they >> >> died. This is how they looked like: >> >> >> >> raidz1 DEGRADED 0 0 0 >> >> gpt/disk-e1:s2 UNAVAIL 44 59.5K 0 experienced >> I/O >> >> failures >> >> gpt/disk-e1:s3 ONLINE 0 0 0 >> >> gpt/disk-e1:s4 ONLINE 0 0 0 >> >> gpt/disk-e1:s5 ONLINE 0 0 0 >> >> >> >> raidz1 DEGRADED 0 0 0 >> >> gpt/disk-e1:s14 ONLINE 0 0 0 >> >> gpt/disk-e1:s15 ONLINE 0 0 0 >> >> gpt/disk-e1:s16 ONLINE 0 0 0 >> >> gpt/disk-e1:s17 UNAVAIL 1.56K 49.0K 0 experienced >> I/O >> >> failures >> >> >> >> >> >> I did have two spare disks ready to replace them. So after they died >> here's >> >> what I executed: >> >> >> >> # zpool replace tank gpt/disk-e1:s2 gpt/disk-e2:s10 >> >> # zpool replace tank gpt/disk-e1:s17 gpt/disk-e2:s11 >> >> >> >> Resilvering started. While in the middle of it though the kernel >> paniced >> >> and I had to reboot the machine. >> >> After reboot I waited until the resilvering is complete. Now that it >> was >> >> complete I expected to see the old/bad >> >> device removed from the vdev but it was still there. Trying detach was >> >> complaining with no valid replicas. >> >> I sent colo technician to replace both those defective drives with >> brand >> >> new ones. Once I had them inserted >> >> I recreated them exactly the same way as the ones that I had before - >> jbod >> >> and gpart labeled partition with the >> >> same name! Then I added them as spares: >> >> >> >> # zpool add tank spare gpt/disk-e1:s2 >> >> # zpool add tank spare gpt/disk-e1:s17 >> >> >> >> That actually made it worse I think since now I had the same device >> name >> >> both as a 'previous' failed device >> >> inside the raidz1 group and as a hot spare spare device. I couldn't do >> >> anything with it. >> >> What I did was to export the pool fail the disk on the controller, >> import >> >> the pool and check that zfs could open >> >> it anymore (as a part of the hot spares). Then I recreated that >> >> disk/partition with a new label 'newdisk-XXX' >> >> and tried to replace the device that originally failed (and was only >> >> presented with a number). So I did this: >> >> >> >> # zpool replace tank gpt/disk-e1:s17 gpt/newdisk-e1:s17 >> >> # zpool replace tank gpt/disk-e1:s2 gpt/newdisk-e1:s2 >> >> >> >> Resilvering completed after 17 hours or so and I expected for the >> >> 'replacing' operation to disappear and the >> >> replaced device to go away. But it didn't! Instead I have the state of >> the >> >> pool as shown in the beginning of >> >> the email. >> >> As for the 'errors: 4 data errors, use '-v' for a list' I suspect that >> >> it's due another failing >> >> device (gpt/disk-e1:s3) inside the first (currently degraded) raidz1 >> vdev. >> >> Those 4 corrupted files actually >> >> could be read sometimes so that tells me that the disk has trouble >> reading >> >> *sometimes* those bad blocks. >> >> >> >> Here's the output of zdb -l tank >> >> >> >> version=14 >> >> name='tank' >> >> state=0 >> >> txg=200225 >> >> pool_guid=13504509992978610301 >> >> hostid=409325918 >> >> hostname='XXXX' >> >> vdev_tree >> >> type='root' >> >> id=0 >> >> guid=13504509992978610301 >> >> children[0] >> >> type='raidz' >> >> id=0 >> >> guid=3740854890192825394 >> >> nparity=1 >> >> metaslab_array=33 >> >> metaslab_shift=36 >> >> ashift=9 >> >> asize=7995163410432 >> >> is_log=0 >> >> children[0] >> >> type='spare' >> >> id=0 >> >> guid=16171901098004278313 >> >> whole_disk=0 >> >> children[0] >> >> type='replacing' >> >> id=0 >> >> guid=2754550310390861576 >> >> whole_disk=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=17307041822177798519 >> >> path='/dev/gpt/disk-e1:s2' >> >> whole_disk=0 >> >> not_present=1 >> >> DTL=246 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=1641394056824955485 >> >> path='/dev/gpt/newdisk-e1:s2' >> >> whole_disk=0 >> >> DTL=55 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=13150356781300468512 >> >> path='/dev/gpt/disk-e2:s10' >> >> whole_disk=0 >> >> is_spare=1 >> >> DTL=1289 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=6047192237176807561 >> >> path='/dev/gpt/disk-e1:s3' >> >> whole_disk=0 >> >> DTL=250 >> >> children[2] >> >> type='disk' >> >> id=2 >> >> guid=9178318500891071208 >> >> path='/dev/gpt/disk-e1:s4' >> >> whole_disk=0 >> >> DTL=249 >> >> children[3] >> >> type='disk' >> >> id=3 >> >> guid=2567999855746767831 >> >> path='/dev/gpt/disk-e1:s5' >> >> whole_disk=0 >> >> DTL=248 >> >> children[1] >> >> type='raidz' >> >> id=1 >> >> guid=17097047310177793733 >> >> nparity=1 >> >> metaslab_array=31 >> >> metaslab_shift=36 >> >> ashift=9 >> >> asize=7995163410432 >> >> is_log=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=14513380297393196654 >> >> path='/dev/gpt/disk-e1:s6' >> >> whole_disk=0 >> >> DTL=266 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=7673391645329839273 >> >> path='/dev/gpt/disk-e1:s7' >> >> whole_disk=0 >> >> DTL=265 >> >> children[2] >> >> type='disk' >> >> id=2 >> >> guid=15189132305590412134 >> >> path='/dev/gpt/disk-e1:s8' >> >> whole_disk=0 >> >> DTL=264 >> >> children[3] >> >> type='disk' >> >> id=3 >> >> guid=17171875527714022076 >> >> path='/dev/gpt/disk-e1:s9' >> >> whole_disk=0 >> >> DTL=263 >> >> children[2] >> >> type='raidz' >> >> id=2 >> >> guid=4551002265962803186 >> >> nparity=1 >> >> metaslab_array=30 >> >> metaslab_shift=36 >> >> ashift=9 >> >> asize=7995163410432 >> >> is_log=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=12104241519484712161 >> >> path='/dev/gpt/disk-e1:s10' >> >> whole_disk=0 >> >> DTL=262 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=3950210349623142325 >> >> path='/dev/gpt/disk-e1:s11' >> >> whole_disk=0 >> >> DTL=261 >> >> children[2] >> >> type='disk' >> >> id=2 >> >> guid=14559903955698640085 >> >> path='/dev/gpt/disk-e1:s12' >> >> whole_disk=0 >> >> DTL=260 >> >> children[3] >> >> type='disk' >> >> id=3 >> >> guid=12364155114844220066 >> >> path='/dev/gpt/disk-e1:s13' >> >> whole_disk=0 >> >> DTL=259 >> >> children[3] >> >> type='raidz' >> >> id=3 >> >> guid=12517231224568010294 >> >> nparity=1 >> >> metaslab_array=29 >> >> metaslab_shift=36 >> >> ashift=9 >> >> asize=7995163410432 >> >> is_log=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=7655789038925330983 >> >> path='/dev/gpt/disk-e1:s14' >> >> whole_disk=0 >> >> DTL=258 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=17815755378968233141 >> >> path='/dev/gpt/disk-e1:s15' >> >> whole_disk=0 >> >> DTL=257 >> >> children[2] >> >> type='disk' >> >> id=2 >> >> guid=9590421681925673767 >> >> path='/dev/gpt/disk-e1:s16' >> >> whole_disk=0 >> >> DTL=256 >> >> children[3] >> >> type='spare' >> >> id=3 >> >> guid=4015417100051235398 >> >> whole_disk=0 >> >> children[0] >> >> type='replacing' >> >> id=0 >> >> guid=11653429697330193176 >> >> whole_disk=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=15258738282880603331 >> >> path='/dev/gpt/disk-e1:s17' >> >> whole_disk=0 >> >> not_present=1 >> >> DTL=255 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=908651380690954833 >> >> path='/dev/gpt/newdisk-e1:s17' >> >> whole_disk=0 >> >> is_spare=1 >> >> DTL=52 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=7250934196571906160 >> >> path='/dev/gpt/disk-e2:s11' >> >> whole_disk=0 >> >> is_spare=1 >> >> DTL=1292 >> >> children[4] >> >> type='raidz' >> >> id=4 >> >> guid=7622366288306613136 >> >> nparity=1 >> >> metaslab_array=28 >> >> metaslab_shift=36 >> >> ashift=9 >> >> asize=7995163410432 >> >> is_log=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=11283483106921343963 >> >> path='/dev/gpt/disk-e1:s18' >> >> whole_disk=0 >> >> DTL=254 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=14900597968455968576 >> >> path='/dev/gpt/disk-e1:s19' >> >> whole_disk=0 >> >> DTL=253 >> >> children[2] >> >> type='disk' >> >> id=2 >> >> guid=4140592611852504513 >> >> path='/dev/gpt/disk-e1:s20' >> >> whole_disk=0 >> >> DTL=252 >> >> children[3] >> >> type='disk' >> >> id=3 >> >> guid=2794215380207576975 >> >> path='/dev/gpt/disk-e1:s21' >> >> whole_disk=0 >> >> DTL=251 >> >> children[5] >> >> type='raidz' >> >> id=5 >> >> guid=17655293908271300889 >> >> nparity=1 >> >> metaslab_array=27 >> >> metaslab_shift=36 >> >> ashift=9 >> >> asize=7995163410432 >> >> is_log=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=5274146379037055039 >> >> path='/dev/gpt/disk-e1:s22' >> >> whole_disk=0 >> >> DTL=278 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=8651755019404873686 >> >> path='/dev/gpt/disk-e1:s23' >> >> whole_disk=0 >> >> DTL=277 >> >> children[2] >> >> type='disk' >> >> id=2 >> >> guid=16827379661759988976 >> >> path='/dev/gpt/disk-e2:s0' >> >> whole_disk=0 >> >> DTL=276 >> >> children[3] >> >> type='disk' >> >> id=3 >> >> guid=2524967151333933972 >> >> path='/dev/gpt/disk-e2:s1' >> >> whole_disk=0 >> >> DTL=275 >> >> children[6] >> >> type='raidz' >> >> id=6 >> >> guid=2413519694016115220 >> >> nparity=1 >> >> metaslab_array=26 >> >> metaslab_shift=36 >> >> ashift=9 >> >> asize=7995163410432 >> >> is_log=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=16361968944335143412 >> >> path='/dev/gpt/disk-e2:s2' >> >> whole_disk=0 >> >> DTL=274 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=10054650477559530937 >> >> path='/dev/gpt/disk-e2:s3' >> >> whole_disk=0 >> >> DTL=273 >> >> children[2] >> >> type='disk' >> >> id=2 >> >> guid=17105959045159531558 >> >> path='/dev/gpt/disk-e2:s4' >> >> whole_disk=0 >> >> DTL=272 >> >> children[3] >> >> type='disk' >> >> id=3 >> >> guid=17370453969371497663 >> >> path='/dev/gpt/disk-e2:s5' >> >> whole_disk=0 >> >> DTL=271 >> >> children[7] >> >> type='raidz' >> >> id=7 >> >> guid=4614010953103453823 >> >> nparity=1 >> >> metaslab_array=24 >> >> metaslab_shift=36 >> >> ashift=9 >> >> asize=7995163410432 >> >> is_log=0 >> >> children[0] >> >> type='disk' >> >> id=0 >> >> guid=10090128057592036175 >> >> path='/dev/gpt/disk-e2:s6' >> >> whole_disk=0 >> >> DTL=270 >> >> children[1] >> >> type='disk' >> >> id=1 >> >> guid=16676544025008223925 >> >> path='/dev/gpt/disk-e2:s7' >> >> whole_disk=0 >> >> DTL=269 >> >> children[2] >> >> type='disk' >> >> id=2 >> >> guid=11777789246954957292 >> >> path='/dev/gpt/disk-e2:s8' >> >> whole_disk=0 >> >> DTL=268 >> >> children[3] >> >> type='disk' >> >> id=3 >> >> guid=3406600121427522915 >> >> path='/dev/gpt/disk-e2:s9' >> >> whole_disk=0 >> >> DTL=267 >> >> >> >> OS: >> >> 8.1-STABLE FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 amd64 >> >> >> >> Hardware: >> >> Chassis: SuperMicro 847E1 (two backplanes 24 disks front and 12 >> >> disks in the back) >> >> Motherboard: X8SIL >> >> CPU: 1 x X3430 @ 2.40GHz >> >> RAM: 16G >> >> HDD Controller: SuperMicro / LSI 9260 (pciconf -lv SAS1078 PCI-X >> >> Fusion-MPT SAS) : 2 ports >> >> Disks: 36 x 2T Western Digital RE4 >> >> >> >> >> >> >> >> Any help would be appreciated. Let me know what additional information >> I >> >> should provide. >> >> Thank you in advance, >> >> -- >> >> Rumen Telbizov >> >> >> >> >> > >> > >> > -- >> > Rumen Telbizov >> > http://telbizov.com >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscribe@freebsd.org" >> > >> > > > > -- > Rumen Telbizov > http://telbizov.com > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 03:14:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FFAB106564A for ; Fri, 29 Oct 2010 03:14:32 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BDA58FC0A for ; Fri, 29 Oct 2010 03:14:31 +0000 (UTC) Received: by qyk2 with SMTP id 2so1614574qyk.13 for ; Thu, 28 Oct 2010 20:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=HloN1h9KRlfYld7CqqkbUmnCEMCmui1bhVk6niWbHbc=; b=Gsi2GwXg76g9fGyuEouF831RJYAo6pqMjWoWfFchiHVID26W3DcxT6haKagAaJu3m+ juBu8x00vpGKH5XDeS6cvElFyZittMLBsg2EtXJNOoWnIWL57nURryksEqj0FLGlJc2c y4lP5LbB6Qw0ijThKhRzY0fvwRJ8FdvgpS8Aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=CjNNQB2kBbrEDV4Vk/4sEf4SBOqDjZu5Q6hyjVinJNxtSlIUEZ8IDIZ2lGD//7dKnW 7GDvQWt66kNkEyxqmUNNo9tXApx2kzklsbvWYGRHq7HxlId1V2k5VNqAR1O5FF9kJaUs Ib0aKrzaJTf2GMvcfXYisNPRaRT3kOwK2zF1k= Received: by 10.229.224.81 with SMTP id in17mr6359004qcb.81.1288322071064; Thu, 28 Oct 2010 20:14:31 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-136-243.dsl.klmzmi.sbcglobal.net [99.181.136.243]) by mx.google.com with ESMTPS id s28sm1804112qcp.21.2010.10.28.20.14.27 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 20:14:29 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CCA3C11.4000609@DataIX.net> Date: Thu, 28 Oct 2010 23:14:25 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: "S.N.Grigoriev" References: <398231288212690@web127.yandex.ru> <7FF9CDFF-3FA0-45EA-85F5-A236AEFC03C7@lassitu.de> <313981288251001@web49.yandex.ru> In-Reply-To: <313981288251001@web49.yandex.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: ZFS write speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 03:14:32 -0000 On 10/28/2010 03:30, S.N.Grigoriev wrote: > > > 28.10.10, 01:54, "Stefan Bethke" : > >> Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: >> >> > Hi list, >> > >> > I've got very low write speed using ZFS on a SATA disk. >> > My HDD configuration is: >> > ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s >> > ad6: 78532MB at ata3-master UDMA100 SATA 1.5Gb/s >> > ad8: 1430799MB at ata4-master UDMA100 SATA 3Gb/s >> >> The EARS has 4k sectors, if I'm not mistaken. I don't recall the eventual >> outcome, but there was a long thread on stable or hackers on how to ensure >> proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't >> have to do a read-modify-write cycle, so try and search the archives. Though this might play a small part in your write performance with the EARS drives, this issue has more to do with the stat() calls and the ACL involvement with ZFS. This was sort of solved in 8.1-STABLE and from 3 cases that I know about and 1 being my own... write/read speeds have doubled from what can be seen to an effect of 8.1-RELEASE. You may want to either upgrade to stable/8 or use one of the snapshots from here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201010/ > > Stefan, > > thank you for your response. I'll try to find the topic you pointed. > >> > ad4 and ad6 are single-slice disks (UFS2 with soft updates) >> > >> > ZFS configuration is following: >> > zpool create Z ad8 >> > zfs create Z/music >> > zfs create Z/video >> > All ZFS parameters are default. >> > kern.maxvnodes = 1000000 >> > >> > To test my configuration I recursively copied from ad6 to ad8 two directories. >> > The first one contains MP3 files (average size = 10MB). >> > The second one contains AVI files (average size = 1GB). >> > >> > To compare performance I repeated above tests with ad8 using UFS2 with soft updates. >> > >> > 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. >> > 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. >> > >> > I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. >> > >> > Any tips? >> > >> > -- > -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 04:46:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9501C106564A for ; Fri, 29 Oct 2010 04:46:08 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 419788FC19 for ; Fri, 29 Oct 2010 04:46:07 +0000 (UTC) Received: by qyk7 with SMTP id 7so5606316qyk.13 for ; Thu, 28 Oct 2010 21:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=7kcGbcRT5XkMjJeTQjfIIAddd9uMhNWg3XgQFmDglYg=; b=NwFn/psXckFucXSzHvfJy5A8dW7WR+k3VRQJNgagL0g5VTCqj9WLSH2bKiKThuqeC9 70YDkeX3iZCUtTjAmbBIxFftXcIJXmHnjdilG8E0wId9Hfx/R2tHhBsKVDw+d9mJ8nri lUCQE0HovWalBWZT9elKK/wUbv5Q5p5ASjV34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=XKmukQGNH4/PJUVoZncY3e3evCcSE+5k9i3XuU2SS0nc1zzWgimFTA2pgt033BsIEK OaSvaPTiFWIDHlJTc/CZgHCoX36FFI8fmgGZbkPSqmHSA0BJhFHiPUVCHCU2HH+pMHlK Q3OXkN5u3iwuxlaESSxd/odDUgu4OQ2pN3kJ4= MIME-Version: 1.0 Received: by 10.224.188.134 with SMTP id da6mr5032938qab.368.1288327567102; Thu, 28 Oct 2010 21:46:07 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.180.2 with HTTP; Thu, 28 Oct 2010 21:46:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Oct 2010 21:46:07 -0700 X-Google-Sender-Auth: MngorfUTgS4KwvP_N2KydGAj21c Message-ID: From: Artem Belevich To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 04:46:08 -0000 > but only those 3 devices in /dev/gpt and absolutely nothing in /dev/gptid/ > So is there a way to bring all the gpt labeled partitions back into the pool > instead of using the mfidXX devices? Try re-importing the pool with "zpool import -d /dev/gpt". This will tell ZFS to use only devices found within that path and your pool should be using gpt labels again. --Artem From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 05:51:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29F20106564A for ; Fri, 29 Oct 2010 05:51:20 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id CEE9E8FC08 for ; Fri, 29 Oct 2010 05:51:19 +0000 (UTC) Received: by qyk7 with SMTP id 7so5644139qyk.13 for ; Thu, 28 Oct 2010 22:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JI9sCMA8KSnnt9yHtsw2autIG2sM7Zkybg8Ot7on0rQ=; b=NFT5UeF5atEfV5rDg9/WSk5wpu7JFUWY0t/UohIBuAd4Ner4vBFPor+RnSdlqk+Uib CAB0wclzKn4aDh6CRgmdvJ5OhxO09MKxSLqspBaUu0YZa4Yrs7HYZnOgeVUgTrk2KYC6 vSTa3be6mizNeTi0HHhZBqkZbuhnVn3uw+kAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UQMHhqaBpb+zpkgAER7A2PYIe0/p6D5MGLmPZa1p0hnfGY4bwqqzWlex4fyDU2Na3B oCt8PoIBsb0JKhQlFDG87I0cVqwf6n5Xor+gdO99otAPGuWUGa+97nXYyD0RJwfUQ2ar q0UWvAOknbNRxIT6bhe2UIIXRYyfEpBNiDZBE= MIME-Version: 1.0 Received: by 10.229.224.67 with SMTP id in3mr3550438qcb.236.1288331478300; Thu, 28 Oct 2010 22:51:18 -0700 (PDT) Received: by 10.229.110.12 with HTTP; Thu, 28 Oct 2010 22:51:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Oct 2010 22:51:18 -0700 Message-ID: From: Rumen Telbizov To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 05:51:20 -0000 Hi Artem, everyone, Thanks for your quick response. Unfortunately I already did try this approach. Applying -d /dev/gpt only limits the pool to the bare three remaining disks which turns pool completely unusable (no mfid devices). Maybe those labels are removed shortly they are being tried to be imported/accessed? What I don't understand is what exactly makes those gpt labels disappear when the pool is imported and otherwise are just fine?! Something to do with OpenSolaris ? On top of it all gpart show -l keeps showing all the labels right even while the pool is imported. Any other clues would be appreciated. Thank you, Rumen Telbizov On Thu, Oct 28, 2010 at 9:46 PM, Artem Belevich wrote: > > but only those 3 devices in /dev/gpt and absolutely nothing in > /dev/gptid/ > > So is there a way to bring all the gpt labeled partitions back into the > pool > > instead of using the mfidXX devices? > > Try re-importing the pool with "zpool import -d /dev/gpt". This will > tell ZFS to use only devices found within that path and your pool > should be using gpt labels again. > > --Artem > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 06:32:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AD33106566B for ; Fri, 29 Oct 2010 06:32:52 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id CAD928FC0A for ; Fri, 29 Oct 2010 06:32:51 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 0D9E5AEB3C; Fri, 29 Oct 2010 08:32:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Fri, 29 Oct 2010 08:32:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rumen Telbizov X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org, Artem Belevich Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 06:32:52 -0000 Am 29.10.2010 um 07:51 schrieb Rumen Telbizov: > Thanks for your quick response. Unfortunately I already did try this > approach. Applying -d /dev/gpt only limits the pool to the bare three = remaining disks > which turns pool completely unusable (no mfid devices). Maybe those = labels are removed > shortly they are being tried to be imported/accessed? >=20 > What I don't understand is what exactly makes those gpt labels = disappear > when the pool is imported and otherwise are just fine?! > Something to do with OpenSolaris ? On top of it all gpart show -l = keeps > showing all the labels right even while the pool is imported. >=20 > Any other clues would be appreciated. The labels are removed by glabel as soon as something opens the = underlying provider, i. e. the disk device, for writing. Since that = process could change the part of the disk that the label information is = extracted from, the label is removed. glabel will re-taste the provider = once the process closes it again. Since you're using gpt labels, I would expect them to continue to be = available, unless zpool import somehow opens the disk devices (instead = of the partition devices). Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 07:26:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67DD8106566B for ; Fri, 29 Oct 2010 07:26:57 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 12B8E8FC0C for ; Fri, 29 Oct 2010 07:26:56 +0000 (UTC) Received: by qyk7 with SMTP id 7so5711593qyk.13 for ; Fri, 29 Oct 2010 00:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=dEwZmtD0FozCJ4MphGUewgj/I6bJl28dwGAsZMzo/DI=; b=tm42dhfEQeNZYvwjRKn6wowdKNnhePlIvsLE+2cOO/IdK64FL/UH1B/Q/N4yjTnGIt Dij5xE1g0LDTQI0v9s425OXLdjTqOU//Ku1xYxd7XJG32ijxqHXl4PxnDsBNjEoKLVA/ bonxuAkCvpYpGV7CFwDGMDJ8oXTDPSApd1hBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=k3L7AzYNau0GdgYLLXUPtMHdrAKOyTgZbnRLoakZkbYqQGKAspeFYQ7xzRTsLXnwg2 zHQhyhb1VwRsfhDJ84EJXPgvjdCi52DI4DsOcQa5V3XmyAeIOGW2EZmdqtWXsUL/sK+q MzGqdB8VJ8E0b3OEzaFNEJ0YjQhkp+Uvm5sb4= MIME-Version: 1.0 Received: by 10.229.250.193 with SMTP id mp1mr11390903qcb.129.1288337216211; Fri, 29 Oct 2010 00:26:56 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.180.2 with HTTP; Fri, 29 Oct 2010 00:26:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 00:26:56 -0700 X-Google-Sender-Auth: uXqqmI6ZOxYqxlAid5uFL1lMTfk Message-ID: From: Artem Belevich To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 07:26:57 -0000 On Thu, Oct 28, 2010 at 10:51 PM, Rumen Telbizov wrote: > Hi Artem, everyone, > > Thanks for your quick response. Unfortunately I already did try this > approach. > Applying -d /dev/gpt only limits the pool to the bare three remaining disks > which turns > pool completely unusable (no mfid devices). Maybe those labels are removed > shortly > they are being tried to be imported/accessed? In one of the previous emails you've clearly listed many devices in /dev/gpt and said that they've disappeared after pool import. Did you do "zpool import -d /dev/gpt" while /dev/gpt entries were present? > What I don't understand is what exactly makes those gpt labels disappear > when the pool is imported and otherwise are just fine?! This is the way GEOM works. If something (ZFS in this case) uses raw device, derived GEOM entities disappear. Try exporting the pool. Your /dev/gpt entries should be back. Now try to import with -d option and see if it works. You may try bringing the labels back the hard way by detaching raw drive and then re-attaching it via the label, but resilvering one drive at a time will take a while. --Artem From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 08:59:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 370011065674 for ; Fri, 29 Oct 2010 08:59:33 +0000 (UTC) (envelope-from me@kmwhite.net) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by mx1.freebsd.org (Postfix) with SMTP id 0EDF48FC17 for ; Fri, 29 Oct 2010 08:59:32 +0000 (UTC) Received: (qmail 1798 invoked by uid 0); 29 Oct 2010 07:36:46 -0000 Received: from unknown (HELO box465.bluehost.com) (74.220.219.65) by oproxy1.bluehost.com.bluehost.com with SMTP; 29 Oct 2010 07:36:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kmwhite.net; h=Received:MIME-Version:Date:From:To:Subject:Message-ID:X-Sender:User-Agent:Content-Transfer-Encoding:Content-Type:X-Identified-User; b=hoABUFjVGDf5d0/IgP66+tr22UoV/UlPKhqcFoVxQBsXT9ZmePQYMHZSfGe1Y/NyECEQcNJC+VZHI/Fscfmx8xtNKiY9Jn4yqepG8RUTqcezi/9Sa2GhcA94IN306EMu; Received: from localhost ([127.0.0.1] helo=box465.bluehost.com) by box465.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PBkOK-0007UY-To for freebsd-stable@freebsd.org; Fri, 29 Oct 2010 02:32:52 -0600 MIME-Version: 1.0 Date: Fri, 29 Oct 2010 02:32:52 -0600 From: To: Message-ID: X-Sender: me@kmwhite.net User-Agent: RoundCube Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Identified-User: {1316:box465.bluehost.com:krypnosn:kmwhite.net} {sentby:smtp auth 127.0.0.1 authed with me@kmwhite.net} Subject: Intel PRO/Wireless 6050 in 8.1-RELEASE Problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 08:59:33 -0000 I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most hardware works just fine, but I'm having a hell of a time with the wifi. Everytime I try to associate with an access point, my terminal replies with: jarvis# wpa_supplicant -i iwn0 -c /etc/wpa_supplicant.conf ioctl[SIOCG80211, op 98, len 32]: Invalid argument Failed to initialize driver interface ELOOP: remaining socket: sock=4 eloop_data=0x28406140 user_data=0x2840d040 handler=0x8069f70 A check to /var/log/messages shows: Oct 29 03:29:44 jarvis wpa_supplicant[896]: Failed to initiate AP scan. Oct 29 03:29:45 jarvis wpa_supplicant[751]: Failed to initiate AP scan. Oct 29 03:29:54 jarvis wpa_supplicant[896]: Failed to initiate AP scan. Oct 29 03:29:55 jarvis wpa_supplicant[751]: Failed to initiate AP scan. Oct 29 03:30:00 jarvis wpa_supplicant[751]: Failed to disable WPA in the driver. Oct 29 03:30:00 jarvis wpa_supplicant[896]: Failed to disable WPA in the driver. Oct 29 03:30:01 jarvis kernel: iwn_fatal_intr: bad firmware error log address 0x00000000 Oct 29 03:30:02 jarvis kernel: iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35 Oct 29 03:30:02 jarvis kernel: iwn0: iwn_init_locked: could not initialize hardware, error 35 I know that my device is being detected, because I see: jarvis# dmesg | grep 'Wireless' iwn0: mem 0xe6e00000-0xe6e01fff irq 17 at device 0.0 on pci3 When looking at my interfaces, I see: jarvis# ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:23:15:46:b6:c8 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF txpower 0 bmiss 10 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 wme roaming MANUAL bintval 0 jarvis# ifconfig iwn0 iwn0: flags=8802 metric 0 mtu 2290 ether 00:23:15:46:b6:c8 media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated My wpa_supplicant works on other boxes without problem. Additional useful file contents: jarvis# cat /etc/rc.conf # -- sysinstall generated deltas -- # Sun Oct 24 18:04:25 2010 # Created: Sun Oct 24 18:04:25 2010 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. hostname="jarvis.localdomain" ifconfig_em0="DHCP" moused_enable="YES" sshd_enable="YES" linux_enable="YES" nvidia_enable="YES" wlans_iwn0="wlan0" ifconfig_wlan0="WPA DHCP" vboxnet_enable="YES" vboxguest_enable="YES" slim_enable="YES" jarvis# cat /boot/loader.conf # VBox configs vboxdrv_load="YES" # Wireless Lan configs if_ipw_load="YES" if_iwi_load="YES" if_wpi_load="YES" iwn6050fw_load="YES" iwnfw_load="YES" if_iwn_load="YES" legal.intel_ipw.license_ack=1 legal.intel_iwi.license_ack=1 legal.intel_wpi.license_ack=1 legal.intel_iwn.license_ack=1 wlan_wep_load="YES" wlan_ccmp_load="YES" wlan_tkip_load="YES" # Nvidia support? SURE! nvidia_load="YES" When looking at dmesg, I see: jarvis# dmesg | grep wlan0 wlan0: Ethernet address: 00:23:15:46:b6:c8 jarvis# dmesg | grep iwn0 iwn0: mem 0xe6e00000-0xe6e01fff irq 17 at device 0.0 on pci3 iwn0: MIMO 2T2R, MoW, address 00:23:15:46:b6:c8 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 I know that that error has to be part of the problem. I just don't know what to do next, and haven't been able to find any help further. Any ideas? Additionally, any thing I forgot to add, please let me know. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 09:04:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4252A1065695 for ; Fri, 29 Oct 2010 09:04:23 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id D43BC8FC17 for ; Fri, 29 Oct 2010 09:04:22 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id E9B0AE7746; Fri, 29 Oct 2010 10:04:21 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 29 Oct 2010 10:04:21 +0100 (BST) Date: Fri, 29 Oct 2010 10:04:14 +0100 From: Bruce Cran To: Message-ID: <20101029100414.00001337@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Intel PRO/Wireless 6050 in 8.1-RELEASE Problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 09:04:23 -0000 On Fri, 29 Oct 2010 02:32:52 -0600 wrote: > I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most > hardware works just fine, but I'm having a hell of a time with the > wifi. Everytime I try to associate with an access point, my terminal > replies with: > > jarvis# wpa_supplicant -i iwn0 -c /etc/wpa_supplicant.conf > ioctl[SIOCG80211, op 98, len 32]: Invalid argument > Failed to initialize driver interface > ELOOP: remaining socket: sock=4 eloop_data=0x28406140 > user_data=0x2840d040 handler=0x8069f70 I'm sure it's not the cause of the problem, but shouldn't you be running wpa_supplicant on the wlan0 interface, not the underlying iwn0? -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 09:29:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCABD106566C for ; Fri, 29 Oct 2010 09:29:11 +0000 (UTC) (envelope-from me@kmwhite.net) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by mx1.freebsd.org (Postfix) with SMTP id ABADE8FC16 for ; Fri, 29 Oct 2010 09:29:11 +0000 (UTC) Received: (qmail 7651 invoked by uid 0); 29 Oct 2010 08:33:04 -0000 Received: from unknown (HELO box465.bluehost.com) (74.220.219.65) by oproxy1.bluehost.com.bluehost.com with SMTP; 29 Oct 2010 08:33:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kmwhite.net; h=Received:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References:Message-ID:X-Sender:User-Agent:Content-Transfer-Encoding:Content-Type:X-Identified-User; b=T/EblXWAOUSYzqwvkgVln8MgTS/u0If10F2z4GOtrWFPJJ4WodQcsQhYkO0CtQvrRLcZhR3XS+iH01DLqlzHmutPj0dV0P0q6Eug7K5SKqg1wKX/NU2KMD90eC2tavn7; Received: from localhost ([127.0.0.1] helo=box465.bluehost.com) by box465.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PBlGo-0004IN-9s; Fri, 29 Oct 2010 03:29:11 -0600 MIME-Version: 1.0 Date: Fri, 29 Oct 2010 03:29:10 -0600 From: To: Bruce Cran In-Reply-To: <20101029100414.00001337@unknown> References: <20101029100414.00001337@unknown> Message-ID: <218c3f3bdad405e89815139571ebbfe0@krypnos.net> X-Sender: me@kmwhite.net User-Agent: RoundCube Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Identified-User: {1316:box465.bluehost.com:krypnosn:kmwhite.net} {sentby:smtp auth 127.0.0.1 authed with me@kmwhite.net} Cc: freebsd-stable@freebsd.org Subject: Re: Intel PRO/Wireless 6050 in 8.1-RELEASE Problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 09:29:11 -0000 On Fri, 29 Oct 2010 10:04:14 +0100, Bruce Cran wrote: > On Fri, 29 Oct 2010 02:32:52 -0600 > wrote: > >> I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most >> hardware works just fine, but I'm having a hell of a time with the >> wifi. Everytime I try to associate with an access point, my terminal >> replies with: >> >> jarvis# wpa_supplicant -i iwn0 -c /etc/wpa_supplicant.conf >> ioctl[SIOCG80211, op 98, len 32]: Invalid argument >> Failed to initialize driver interface >> ELOOP: remaining socket: sock=4 eloop_data=0x28406140 >> user_data=0x2840d040 handler=0x8069f70 > > I'm sure it's not the cause of the problem, but shouldn't you be > running wpa_supplicant on the wlan0 interface, not the underlying iwn0? You're correct. That was me copying/pasting the wrong command run, sorry: jarvis# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. ^CCTRL-EVENT-TERMINATING - signal 2 received ioctl[SIOCS80211, op 26, arg 0x0]: Operation not supported Failed to disable WPA in the driver. ELOOP: remaining socket: sock=4 eloop_data=0x28406140 user_data=0x2840d040 handler=0x8069f70 jarvis# From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 09:43:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C0D4106566C for ; Fri, 29 Oct 2010 09:43:03 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id DCCCA8FC0C for ; Fri, 29 Oct 2010 09:43:02 +0000 (UTC) Received: from web73.yandex.ru (web73.yandex.ru [77.88.47.198]) by forward2.mail.yandex.net (Yandex) with ESMTP id 0126238A8F23; Fri, 29 Oct 2010 13:43:00 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1288345381; bh=Wf/1gxq/RytDa64KfoKotwZZSmOhrWufc8Clgi9BvxM=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=L36wZKSF+V3PVZVzWgCJzb8wy+CYc1EylvLI8G2EaBcK54Rko6S7sMlp09bEzbOVT ehRJa3kELffy7VwROCgjTmsqcQgbsUEYZa1+0wT0+mO7WqTutVerrM4eF/dxyWFQpH 3XKW5nHJTMQO8wCt7sHxyshQzQ/ZDh9SDXRQzxc4= Received: from localhost (localhost.localdomain [127.0.0.1]) by web73.yandex.ru (Yandex) with ESMTP id EBAE91DF0041; Fri, 29 Oct 2010 13:43:00 +0400 (MSD) X-Yandex-Spam: 0 X-Yandex-Front: web73.yandex.ru X-Yandex-TimeMark: 1288345380 Received: from netman.spbcity.net (netman.spbcity.net [77.244.18.5]) by mail.yandex.ru with HTTP; Fri, 29 Oct 2010 13:43:00 +0400 From: S.N.Grigoriev To: jhell In-Reply-To: <4CCA3C11.4000609@DataIX.net> References: <398231288212690@web127.yandex.ru> <7FF9CDFF-3FA0-45EA-85F5-A236AEFC03C7@lassitu.de> <313981288251001@web49.yandex.ru> <4CCA3C11.4000609@DataIX.net> MIME-Version: 1.0 Message-Id: <257661288345380@web73.yandex.ru> Date: Fri, 29 Oct 2010 13:43:00 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-stable@freebsd.org Subject: Re: ZFS write speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 09:43:03 -0000 29.10.10, 07:14, "jhell" : > On 10/28/2010 03:30, S.N.Grigoriev wrote: > > > > > > 28.10.10, 01:54, "Stefan Bethke" : > > > >> Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: > >> > >> > Hi list, > >> > > >> > I've got very low write speed using ZFS on a SATA disk. > >> > My HDD configuration is: > >> > ad4: 70911MB at ata2-master UDMA100 SATA 3Gb/s > >> > ad6: 78532MB at ata3-master UDMA100 SATA 1.5Gb/s > >> > ad8: 1430799MB at ata4-master UDMA100 SATA 3Gb/s > >> > >> The EARS has 4k sectors, if I'm not mistaken. I don't recall the eventual > >> outcome, but there was a long thread on stable or hackers on how to ensure > >> proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't > >> have to do a read-modify-write cycle, so try and search the archives. > > Though this might play a small part in your write performance with the > EARS drives, this issue has more to do with the stat() calls and the ACL > involvement with ZFS. This was sort of solved in 8.1-STABLE and from 3 > cases that I know about and 1 being my own... write/read speeds have > doubled from what can be seen to an effect of 8.1-RELEASE. > > You may want to either upgrade to stable/8 or use one of the snapshots > from here: > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201010/ > thank you. I'll be experimenting with STABLE next week. -- Regards, S.Grigoriev. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 09:47:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2D55106564A; Fri, 29 Oct 2010 09:47:38 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 984148FC0A; Fri, 29 Oct 2010 09:47:38 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PBksW-0008qe-FF; Fri, 29 Oct 2010 13:04:04 +0400 Date: Fri, 29 Oct 2010 13:04:17 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101029090417.GA17537@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 09:47:39 -0000 On Thu, Oct 28, 2010 at 09:57:22AM +0400, Alexander Zagrebin wrote: > Hi! > > I've noticed that ZFS on 8.1-STABLE still has problems with sendfile. > When accessing a file at first time the transfer speed is too low, but > on following attempts the transfer speed is normal. ... > I've tried ftpd and nginx with "sendfile on". The behavior is the same. > After disabling using sendfile in nginx ("sendfile off") the problem has > gone. Yep, this problem exists. You may workaround it via bumping up net.inet.tcp.sendspace up to 128k. zfs sendfile is very ineffective. I have made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm only one page (4K). I.e. if you have a file with size 512K, sendfile make calls freebsd_zfs_read 128 times. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 11:16:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C51D7106566C for ; Fri, 29 Oct 2010 11:16:56 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB248FC16 for ; Fri, 29 Oct 2010 11:16:56 +0000 (UTC) Received: by bwz3 with SMTP id 3so2406001bwz.13 for ; Fri, 29 Oct 2010 04:16:55 -0700 (PDT) Received: by 10.204.100.17 with SMTP id w17mr9352038bkn.43.1288349141113; Fri, 29 Oct 2010 03:45:41 -0700 (PDT) Received: from jessie.localnet (p5B0E1263.dip0.t-ipconnect.de [91.14.18.99]) by mx.google.com with ESMTPS id u4sm731556bkz.5.2010.10.29.03.45.39 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 03:45:39 -0700 (PDT) From: Bernhard Schmidt To: me@kmwhite.net Date: Fri, 29 Oct 2010 12:45:37 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-25-generic; KDE/4.4.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201010291245.37615.bschmidt@techwires.net> Cc: freebsd-stable@freebsd.org Subject: Re: Intel PRO/Wireless 6050 in 8.1-RELEASE Problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 11:16:56 -0000 On Friday, October 29, 2010 10:32:52 me@kmwhite.net wrote: > I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most hardware > works just fine, but I'm having a hell of a time with the wifi. Everytime I > try to associate with an access point, my terminal replies with: > > [..] > iwn6050fw_load="YES" > [..] > iwn0: mem 0xe6e00000-0xe6e01fff irq 17 at > [..] > iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35 > iwn0: iwn_init_locked: could not initialize hardware, error 35 > iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35 > iwn0: iwn_init_locked: could not initialize hardware, error 35 > > I know that that error has to be part of the problem. I just don't know > what to do next, and haven't been able to find any help further. Any ideas? > Additionally, any thing I forgot to add, please let me know. The messages indicate that you are using 8.1-RELEASE, but afaik 8.1 does not have the 6050 firmware module, did you get that from stable? If you're able to try stable/8, please do so, there have been a few additions/fixes regarding 6000 series chips which are not in 8.1-RELEASE. -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 12:11:54 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4477106564A for ; Fri, 29 Oct 2010 12:11:54 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.213.67.47]) by mx1.freebsd.org (Postfix) with ESMTP id A5E2D8FC13 for ; Fri, 29 Oct 2010 12:11:54 +0000 (UTC) Received: from localhost (unknown [172.16.100.24]) by mail.barafranca.com (Postfix) with ESMTP id 1A5FFC78; Fri, 29 Oct 2010 11:49:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at barafranca.com Received: from mail.barafranca.com ([172.16.100.24]) by localhost (mail.barafranca.com [172.16.100.24]) (amavisd-new, port 10024) with ESMTP id fbOdh3z4S5FL; Fri, 29 Oct 2010 11:49:08 +0000 (UTC) Received: from [10.100.2.100] (a94-132-3-103.cpe.netcabo.pt [94.132.3.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTPSA id 86348C76; Fri, 29 Oct 2010 11:49:07 +0000 (UTC) Message-ID: <4CCAB4C4.5030208@barafranca.com> Date: Fri, 29 Oct 2010 12:49:24 +0100 From: Hugo Silva User-Agent: Thunderbird 2.0.0.23 (X11/20091030) MIME-Version: 1.0 To: Randy Bush References: <20101027200305.GA35927@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable , Jeremy Chadwick Subject: Re: beastiality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 12:11:54 -0000 Randy Bush wrote: >> This is often caused by a combination of two things being enabled >> simultaneously: BIOS-level serial console redirection after POST, and >> FreeBSD's serial console support. > > bingo! > > thanks > > randy > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Must admit I hesitated before opening this email.. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 12:35:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3F571065673; Fri, 29 Oct 2010 12:35:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DD3298FC1D; Fri, 29 Oct 2010 12:35:04 +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 PAA04851; Fri, 29 Oct 2010 15:35:00 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCABF73.8070707@icyb.net.ua> Date: Fri, 29 Oct 2010 15:34:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alexander Zagrebin References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> In-Reply-To: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 12:35:05 -0000 on 28/10/2010 08:57 Alexander Zagrebin said the following: > Hi! > > I've noticed that ZFS on 8.1-STABLE still has problems with sendfile. Which svn revision, just in case? > When accessing a file at first time the transfer speed is too low, but > on following attempts the transfer speed is normal. > > How to repeat: > > $ dd if=/dev/random of=/tmp/test bs=1m count=100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec) > $ sudo env LC_ALL=C /usr/libexec/ftpd -D > > The first attempt to fetch file: > > $ fetch -o /dev/null ftp://localhost/tmp/test > /dev/null 1% of 100 MB 118 kBps > 14m07s^C > fetch: transfer interrupted > > The transfer rate is too low (approx. 120 kBps), but any subsequent attempts > are success: > > $ fetch -o /dev/null ftp://localhost/tmp/test > /dev/null 100% of 100 MB 42 MBps > $ fetch -o /dev/null ftp://localhost/tmp/test > /dev/null 100% of 100 MB 47 MBps Can you do an experiment with the same structure but sendfile excluded? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 12:36:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD58106567A; Fri, 29 Oct 2010 12:36:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A8AF18FC08; Fri, 29 Oct 2010 12:36:27 +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 PAA04897; Fri, 29 Oct 2010 15:36:19 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCABFC2.3040701@icyb.net.ua> Date: Fri, 29 Oct 2010 15:36:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> In-Reply-To: <20101029090417.GA17537@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 12:36:28 -0000 on 29/10/2010 12:04 Artemiev Igor said the following: > Yep, this problem exists. You may workaround it via bumping up > net.inet.tcp.sendspace up to 128k. zfs sendfile is very ineffective. I have > made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm > only one page (4K). I.e. if you have a file with size 512K, sendfile make > calls freebsd_zfs_read 128 times. What svn revision of FreeBSD source tree did you test? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 13:14:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50D18106564A for ; Fri, 29 Oct 2010 13:14:37 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 028688FC12 for ; Fri, 29 Oct 2010 13:14:36 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBomv-0006DK-Km; Fri, 29 Oct 2010 17:14:33 +0400 From: "Alexander Zagrebin" To: "'Andriy Gapon'" References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <4CCABF73.8070707@icyb.net.ua> Date: Fri, 29 Oct 2010 17:14:33 +0400 Keywords: freebsd-stable Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <4CCABF73.8070707@icyb.net.ua> Thread-Index: Act3ZdsC2F3venc4Rcmi6iFCEPFVAAAA4chA Cc: freebsd-stable@freebsd.org Subject: RE: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:14:37 -0000 > > I've noticed that ZFS on 8.1-STABLE still has problems with > sendfile. > > Which svn revision, just in case? 8.1-STABLE The source tree was updated 2010-10-27 > > When accessing a file at first time the transfer speed is > too low, but > > on following attempts the transfer speed is normal. > > > > How to repeat: > > > > $ dd if=/dev/random of=/tmp/test bs=1m count=100 > > 100+0 records in > > 100+0 records out > > 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec) > > $ sudo env LC_ALL=C /usr/libexec/ftpd -D > > > > The first attempt to fetch file: > > > > $ fetch -o /dev/null ftp://localhost/tmp/test > > /dev/null 1% of 100 > MB 118 kBps > > 14m07s^C > > fetch: transfer interrupted > > > > The transfer rate is too low (approx. 120 kBps), but any > subsequent attempts > > are success: > > > > $ fetch -o /dev/null ftp://localhost/tmp/test > > /dev/null 100% of 100 > MB 42 MBps > > $ fetch -o /dev/null ftp://localhost/tmp/test > > /dev/null 100% of 100 > MB 47 MBps > > Can you do an experiment with the same structure but sendfile > excluded? IMHO, ftpd hasn't an option to disable sendfile. I've tried the nginx with disabled sendfile (the nginx.conf contains "sendfile off;"): $ dd if=/dev/random of=test bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec) $ fetch -o /dev/null http://localhost/test /dev/null 100% of 100 MB 41 MBps $ fetch -o /dev/null http://localhost/test /dev/null 100% of 100 MB 44 MBps $ fetch -o /dev/null http://localhost/test /dev/null 100% of 100 MB 44 MBps -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 13:36:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 242F91065670 for ; Fri, 29 Oct 2010 13:36:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2238FC1F for ; Fri, 29 Oct 2010 13:36:04 +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 QAA05942; Fri, 29 Oct 2010 16:36:01 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCACDC0.7050802@icyb.net.ua> Date: Fri, 29 Oct 2010 16:36:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alexander Zagrebin References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <4CCABF73.8070707@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:36:06 -0000 on 29/10/2010 16:14 Alexander Zagrebin said the following: >>> I've noticed that ZFS on 8.1-STABLE still has problems with >> sendfile. >> >> Which svn revision, just in case? > > 8.1-STABLE > The source tree was updated 2010-10-27 OK, good. >>> When accessing a file at first time the transfer speed is >> too low, but >>> on following attempts the transfer speed is normal. >>> >>> How to repeat: >>> >>> $ dd if=/dev/random of=/tmp/test bs=1m count=100 >>> 100+0 records in >>> 100+0 records out >>> 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec) >>> $ sudo env LC_ALL=C /usr/libexec/ftpd -D >>> >>> The first attempt to fetch file: >>> >>> $ fetch -o /dev/null ftp://localhost/tmp/test >>> /dev/null 1% of 100 >> MB 118 kBps >>> 14m07s^C >>> fetch: transfer interrupted >>> >>> The transfer rate is too low (approx. 120 kBps), but any >> subsequent attempts >>> are success: >>> >>> $ fetch -o /dev/null ftp://localhost/tmp/test >>> /dev/null 100% of 100 >> MB 42 MBps >>> $ fetch -o /dev/null ftp://localhost/tmp/test >>> /dev/null 100% of 100 >> MB 47 MBps >> >> Can you do an experiment with the same structure but sendfile >> excluded? > > IMHO, ftpd hasn't an option to disable sendfile. Seems so. The source could be hacked (unconditional goto oldway in libexec/ftpd/ftpd.c, but anyway. > I've tried the nginx with > disabled sendfile (the nginx.conf contains "sendfile off;"): > > $ dd if=/dev/random of=test bs=1m count=100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec) > $ fetch -o /dev/null http://localhost/test > /dev/null 100% of 100 MB 41 MBps > $ fetch -o /dev/null http://localhost/test > /dev/null 100% of 100 MB 44 MBps > $ fetch -o /dev/null http://localhost/test > /dev/null 100% of 100 MB 44 MBps > I am really surprised with such a bad performance of sendfile. Will you be able to profile the issue further? I will also try to think of some measurements. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 13:37:05 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06EDE10656A4 for ; Fri, 29 Oct 2010 13:37:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id DDFD98FC24 for ; Fri, 29 Oct 2010 13:37:04 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta14.emeryville.ca.mail.comcast.net with comcast id QcQQ1f0041smiN4AEdd4At; Fri, 29 Oct 2010 13:37:04 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta20.emeryville.ca.mail.comcast.net with comcast id Qdd21f00N3LrwQ28gdd3Pt; Fri, 29 Oct 2010 13:37:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8DD299B425; Fri, 29 Oct 2010 06:37:02 -0700 (PDT) Date: Fri, 29 Oct 2010 06:37:02 -0700 From: Jeremy Chadwick To: Ian Smith Message-ID: <20101029133702.GA77576@icarus.home.lan> References: <20101027200305.GA35927@icarus.home.lan> <4CCAB4C4.5030208@barafranca.com> <20101030002454.Y33417@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101030002454.Y33417@sola.nimnet.asn.au> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Randy Bush , stable , Hugo Silva Subject: Re: beastiality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:37:05 -0000 On Sat, Oct 30, 2010 at 12:31:49AM +1100, Ian Smith wrote: > On Fri, 29 Oct 2010, Hugo Silva wrote: > > Randy Bush wrote: > > > > This is often caused by a combination of two things being enabled > > > > simultaneously: BIOS-level serial console redirection after POST, and > > > > FreeBSD's serial console support. > > > > > > bingo! > > > > > > thanks > > > > > > randy > > > Must admit I hesitated before opening this email.. > > Ah, this one was pretty tame .. randy's original post was very explicit > though; Jeremy's a real gentleman for not requoting that sort of filth! Randy's just strange sometimes. Hey Randy, TLG called, they want AS2914 back. ;-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 13:54:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 425651065672 for ; Fri, 29 Oct 2010 13:54:56 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id F28068FC21 for ; Fri, 29 Oct 2010 13:54:55 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 7352316004E; Fri, 29 Oct 2010 15:54:53 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 5B526160049; Fri, 29 Oct 2010 15:54:52 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o9TDsppx024943; Fri, 29 Oct 2010 15:54:52 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Oct 2010 15:54:51 +0200 Date: Fri, 29 Oct 2010 15:54:51 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: jakub_lach@mailplus.pl, freebsd-stable@freebsd.org Message-ID: <4ccad22b.8aR/QkBkGvH9giFo%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Oct 2010 13:54:51.0850 (UTC) FILETIME=[DBD67AA0:01CB7770] Cc: Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:54:56 -0000 >Ready to start test for failing command? Enter to continue: >**********> Testing for failed SCSI command. >scgcheck: Input/output error. inquiry: scsi sendcmd: retryable error >CDB: 12 00 00 FF 24 00 >status: 0x0 (GOOD STATUS) >cmd finished after 0.013s timeout 40s >----------> SCSI Transport return != SCG_NO_ERROR (1) >----------> SCSI status byte set to 0 (0x0) >----------> SCSI failed command test FAILED You seem to have a general problem with correct error reporting in SCSI with your kernel SCSI transport. Please try to contact the maintainer of this driver. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 13:56:48 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C7A81065674 for ; Fri, 29 Oct 2010 13:56:48 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1D88FC21 for ; Fri, 29 Oct 2010 13:56:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o9TDVnvf094765; Sat, 30 Oct 2010 00:31:49 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 30 Oct 2010 00:31:49 +1100 (EST) From: Ian Smith To: Hugo Silva In-Reply-To: <4CCAB4C4.5030208@barafranca.com> Message-ID: <20101030002454.Y33417@sola.nimnet.asn.au> References: <20101027200305.GA35927@icarus.home.lan> <4CCAB4C4.5030208@barafranca.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Randy Bush , stable , Jeremy Chadwick Subject: Re: beastiality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:56:48 -0000 On Fri, 29 Oct 2010, Hugo Silva wrote: > Randy Bush wrote: > > > This is often caused by a combination of two things being enabled > > > simultaneously: BIOS-level serial console redirection after POST, and > > > FreeBSD's serial console support. > > > > bingo! > > > > thanks > > > > randy > Must admit I hesitated before opening this email.. Ah, this one was pretty tame .. randy's original post was very explicit though; Jeremy's a real gentleman for not requoting that sort of filth! From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 14:30:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A73111065675 for ; Fri, 29 Oct 2010 14:30:49 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 8165D8FC1D for ; Fri, 29 Oct 2010 14:30:49 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PBpyh-0006QC-PP for freebsd-stable@freebsd.org; Fri, 29 Oct 2010 07:30:47 -0700 Message-ID: <30086322.post@talk.nabble.com> Date: Fri, 29 Oct 2010 07:30:47 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: <4ccad22b.8aR/QkBkGvH9giFo%Joerg.Schilling@fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <29978939.post@talk.nabble.com> <4ccad22b.8aR/QkBkGvH9giFo%Joerg.Schilling@fokus.fraunhofer.de> Subject: Re: cdrtools /devel and wodim broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:30:49 -0000 Joerg Schilling-3 wrote: > > You seem to have a general problem with correct error reporting in SCSI > with > your kernel SCSI transport. Please try to contact the maintainer of this > driver. > Thanks for support, I have pinged him already. ragards, - Jakub Lach -- View this message in context: http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30086322.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 14:31:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85141065694 for ; Fri, 29 Oct 2010 14:31:23 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0598FC1B for ; Fri, 29 Oct 2010 14:31:23 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBpzF-000BFJ-S3; Fri, 29 Oct 2010 18:31:21 +0400 From: "Alexander Zagrebin" To: "'Andriy Gapon'" References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local><4CCABF73.8070707@icyb.net.ua> <4CCACDC0.7050802@icyb.net.ua> Date: Fri, 29 Oct 2010 18:31:21 +0400 Keywords: freebsd-stable Message-ID: <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <4CCACDC0.7050802@icyb.net.ua> Thread-Index: Act3blU3zhBkH9MFR3+frrrfroI88AAB5lww Cc: freebsd-stable@freebsd.org Subject: RE: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:31:24 -0000 > > I've tried the nginx with > > disabled sendfile (the nginx.conf contains "sendfile off;"): > > > > $ dd if=/dev/random of=test bs=1m count=100 > > 100+0 records in > > 100+0 records out > > 104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec) > > $ fetch -o /dev/null http://localhost/test > > /dev/null 100% of 100 > MB 41 MBps > > $ fetch -o /dev/null http://localhost/test > > /dev/null 100% of 100 > MB 44 MBps > > $ fetch -o /dev/null http://localhost/test > > /dev/null 100% of 100 > MB 44 MBps > > > > I am really surprised with such a bad performance of sendfile. > Will you be able to profile the issue further? Yes. > I will also try to think of some measurements. A transfer rate is too low for the _first_ attempt only. Further attempts demonstrates a reasonable transfer rate. For example, nginx with "sendfile on;": $ dd if=/dev/random of=test bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 5.855305 secs (17908136 bytes/sec) $ fetch -o /dev/null http://localhost/test /dev/null 3% of 100 MB 118 kBps 13m50s^C fetch: transfer interrupted $ fetch -o /dev/null http://localhost/test /dev/null 100% of 100 MB 39 MBps If there was no access to the file during some time, then everything repeats: The first attempt - transfer rate is too low A further attempts - no problems Can you reproduce the problem on your system? -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 14:42:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF76106566B; Fri, 29 Oct 2010 14:42:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 871C98FC08; Fri, 29 Oct 2010 14:42:04 +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 RAA07090; Fri, 29 Oct 2010 17:41:59 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCADD37.7000306@icyb.net.ua> Date: Fri, 29 Oct 2010 17:41:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> In-Reply-To: <4CCABFC2.3040701@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Alexander Zagrebin , freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:42:05 -0000 on 29/10/2010 15:36 Andriy Gapon said the following: > on 29/10/2010 12:04 Artemiev Igor said the following: >> Yep, this problem exists. You may workaround it via bumping up >> net.inet.tcp.sendspace up to 128k. zfs sendfile is very ineffective. I have >> made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm >> only one page (4K). I.e. if you have a file with size 512K, sendfile make >> calls freebsd_zfs_read 128 times. > > What svn revision of FreeBSD source tree did you test? > Ah, I think I see what's going on. Either sendfile should (have an option to) use VOP_GETPAGES to request data or ZFS mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY case. Currently ZFS would read a whole FS block into ARC, but populate only one page with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from ARC data. So, e.g. zpool iostat would show that there are only few actual reads from a pool. The rest of the time must be spent churning over the data already in ARC and doing page-per-VOP_READ copies from it. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 14:52:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE28106566C for ; Fri, 29 Oct 2010 14:52:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 76B6C8FC16 for ; Fri, 29 Oct 2010 14:52:40 +0000 (UTC) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id QckK1f0050QuhwU5DeshHG; Fri, 29 Oct 2010 14:52:41 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.westchester.pa.mail.comcast.net with comcast id Qesf1f0053LrwQ23NesftP; Fri, 29 Oct 2010 14:52:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0938D9B422; Fri, 29 Oct 2010 07:52:38 -0700 (PDT) Date: Fri, 29 Oct 2010 07:52:38 -0700 From: Jeremy Chadwick To: Alexander Zagrebin Message-ID: <20101029145237.GA78583@icarus.home.lan> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <4CCABF73.8070707@icyb.net.ua> <4CCACDC0.7050802@icyb.net.ua> <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, 'Andriy Gapon' Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:52:41 -0000 On Fri, Oct 29, 2010 at 06:31:21PM +0400, Alexander Zagrebin wrote: > > > I've tried the nginx with > > > disabled sendfile (the nginx.conf contains "sendfile off;"): > > > > > > $ dd if=/dev/random of=test bs=1m count=100 > > > 100+0 records in > > > 100+0 records out > > > 104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec) > > > $ fetch -o /dev/null http://localhost/test > > > /dev/null 100% of 100 > > MB 41 MBps > > > $ fetch -o /dev/null http://localhost/test > > > /dev/null 100% of 100 > > MB 44 MBps > > > $ fetch -o /dev/null http://localhost/test > > > /dev/null 100% of 100 > > MB 44 MBps > > > > > > > I am really surprised with such a bad performance of sendfile. > > Will you be able to profile the issue further? > > Yes. > > > I will also try to think of some measurements. > > A transfer rate is too low for the _first_ attempt only. > Further attempts demonstrates a reasonable transfer rate. > For example, nginx with "sendfile on;": > > $ dd if=/dev/random of=test bs=1m count=100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 5.855305 secs (17908136 bytes/sec) > $ fetch -o /dev/null http://localhost/test > /dev/null 3% of 100 MB 118 kBps > 13m50s^C > fetch: transfer interrupted > $ fetch -o /dev/null http://localhost/test > /dev/null 100% of 100 MB 39 MBps > > If there was no access to the file during some time, then everything > repeats: > The first attempt - transfer rate is too low > A further attempts - no problems > > Can you reproduce the problem on your system? I can't reproduce it on mine. Note the resilvering was induced from some unrelated disk swaps/tests I was performing, and ftpd is already enabled via inetd on this system. icarus# uname -a FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 PDT 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 icarus# df -k Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ada0s1a 1012974 451808 480130 48% / devfs 1 1 0 100% /dev /dev/ada0s1d 12186190 103986 11107310 1% /var /dev/ada0s1e 4058062 5468 3727950 0% /tmp /dev/ada0s1f 8395622 1918300 5805674 25% /usr data/cvs 686338517 289 686338228 0% /cvs data/home 687130693 792465 686338228 0% /home data/storage 957080511 270742283 686338228 28% /storage icarus# zpool status pool: data state: ONLINE scrub: resilver completed after 0h43m with 0 errors on Sun Oct 17 10:11:19 2010 config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 mirror ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 258G resilvered errors: No known data errors icarus# pw useradd ftp -g users -u 2000 -s /bin/csh icarus# mkdir /home/ftp icarus# chown ftp:users /home/ftp icarus# cd /home/ftp icarus# dd if=/dev/urandom of=test bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 1.384421 secs (75741116 bytes/sec) icarus# chown ftp:users test icarus# ls -l test -rw-r--r-- 1 ftp users 104857600 Oct 29 07:41 test icarus# date ; fetch -o /dev/null ftp://localhost/test Fri Oct 29 07:45:47 PDT 2010 /dev/null 100% of 100 MB 174 MBps icarus# date ; fetch -o /dev/null ftp://localhost/test Fri Oct 29 07:45:48 PDT 2010 /dev/null 100% of 100 MB 156 MBps icarus# date ; fetch -o /dev/null ftp://localhost/test Fri Oct 29 07:45:49 PDT 2010 /dev/null 100% of 100 MB 170 MBps icarus# date ; fetch -o /dev/null ftp://localhost/test Fri Oct 29 07:45:50 PDT 2010 /dev/null 100% of 100 MB 155 MBps icarus# date ; fetch -o /dev/null ftp://localhost/test Fri Oct 29 07:45:52 PDT 2010 /dev/null 100% of 100 MB 151 MBps icarus# dd if=/dev/urandom of=test2 bs=1m count=500 500+0 records in 500+0 records out 524288000 bytes transferred in 6.947780 secs (75461228 bytes/sec) icarus# chown ftp:users test2 icarus# ls -l test2 -rw-r--r-- 1 ftp users 524288000 Oct 29 07:46 test2 icarus# date ; fetch -o /dev/null ftp://localhost/test2 Fri Oct 29 07:47:19 PDT 2010 /dev/null 100% of 500 MB 148 MBps icarus# date ; fetch -o /dev/null ftp://localhost/test2 Fri Oct 29 07:47:24 PDT 2010 /dev/null 100% of 500 MB 175 MBps icarus# date ; fetch -o /dev/null ftp://localhost/test2 Fri Oct 29 07:47:30 PDT 2010 /dev/null 100% of 500 MB 164 MBps What ZFS tunings have you applied to your system? Can you provide output from "sysctl -a kstat.zfs.misc.arcstats" before and after a transfer which exhibits the initial slowdown? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 14:53:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EED31065674 for ; Fri, 29 Oct 2010 14:53:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 932E48FC14 for ; Fri, 29 Oct 2010 14:53:53 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9TErnvd009933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Oct 2010 17:53:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9TErnX8028682; Fri, 29 Oct 2010 17:53:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9TErnIO028681; Fri, 29 Oct 2010 17:53:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Oct 2010 17:53:49 +0300 From: Kostik Belousov To: Alexander Zagrebin Message-ID: <20101029145349.GX2392@deviant.kiev.zoral.com.ua> References: <4CCACDC0.7050802@icyb.net.ua> <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6G52ZTUPzPgnX6I2" Content-Disposition: inline In-Reply-To: <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, 'Andriy Gapon' Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:53:55 -0000 --6G52ZTUPzPgnX6I2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 29, 2010 at 06:31:21PM +0400, Alexander Zagrebin wrote: > > > I've tried the nginx with > > > disabled sendfile (the nginx.conf contains "sendfile off;"): > > >=20 > > > $ dd if=3D/dev/random of=3Dtest bs=3D1m count=3D100 > > > 100+0 records in > > > 100+0 records out > > > 104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec) > > > $ fetch -o /dev/null http://localhost/test > > > /dev/null 100% of 100=20 > > MB 41 MBps > > > $ fetch -o /dev/null http://localhost/test > > > /dev/null 100% of 100=20 > > MB 44 MBps > > > $ fetch -o /dev/null http://localhost/test > > > /dev/null 100% of 100=20 > > MB 44 MBps > > >=20 > >=20 > > I am really surprised with such a bad performance of sendfile. > > Will you be able to profile the issue further? >=20 > Yes. >=20 > > I will also try to think of some measurements. >=20 > A transfer rate is too low for the _first_ attempt only. > Further attempts demonstrates a reasonable transfer rate. > For example, nginx with "sendfile on;": >=20 > $ dd if=3D/dev/random of=3Dtest bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 5.855305 secs (17908136 bytes/sec) > $ fetch -o /dev/null http://localhost/test > /dev/null 3% of 100 MB 118 kBps > 13m50s^C > fetch: transfer interrupted > $ fetch -o /dev/null http://localhost/test > /dev/null 100% of 100 MB 39 MBps >=20 > If there was no access to the file during some time, then everything > repeats: > The first attempt - transfer rate is too low > A further attempts - no problems >=20 > Can you reproduce the problem on your system? Could it be the priming of the vm object pages content ? Due to double-buffering, and (possibly false) optimization to only perform double-buffering when vm object already has some data cached, reads can prime vm object page list before file is mmapped or sendfile-ed. --6G52ZTUPzPgnX6I2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzK3/0ACgkQC3+MBN1Mb4i4xQCeNNxBh8xeQGRogNWqW+x51KCJ x10Ani8du1Qb6EW2alL0FWYvArUXkzU4 =WGoG -----END PGP SIGNATURE----- --6G52ZTUPzPgnX6I2-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 15:05:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C7BE106566B for ; Fri, 29 Oct 2010 15:05:35 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D4E718FC19 for ; Fri, 29 Oct 2010 15:05:32 +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 SAA07363; Fri, 29 Oct 2010 18:05:28 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCAE2B6.1050906@icyb.net.ua> Date: Fri, 29 Oct 2010 18:05:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Kostik Belousov References: <4CCACDC0.7050802@icyb.net.ua> <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> <20101029145349.GX2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101029145349.GX2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Alexander Zagrebin Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:05:35 -0000 on 29/10/2010 17:53 Kostik Belousov said the following: > Could it be the priming of the vm object pages content ? Sorry, not familiar with this term. Do you mean prepopulation of vm object with valid pages? > Due to double-buffering, and (possibly false) optimization to only What optimization? > perform double-buffering when vm object already has some data cached, > reads can prime vm object page list before file is mmapped or > sendfile-ed. > No double-buffering is done to optimize anything. Double-buffering is a consequence of having page cache and ARC. The special "double-buffering code" is to just handle that fact - e.g. making sure that VOP_READ reads data from page cache instead of ARC if it's possible that the data in them differs (i.e. page cache has more recent data). So, if I understood the term 'priming' correctly, no priming should ever occur. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 15:17:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18C63106564A for ; Fri, 29 Oct 2010 15:17:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 858CD8FC13 for ; Fri, 29 Oct 2010 15:17:31 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9TFHRfb015393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Oct 2010 18:17:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9TFHRs1031237; Fri, 29 Oct 2010 18:17:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9TFHR9A031236; Fri, 29 Oct 2010 18:17:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Oct 2010 18:17:27 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101029151727.GY2392@deviant.kiev.zoral.com.ua> References: <4CCACDC0.7050802@icyb.net.ua> <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> <20101029145349.GX2392@deviant.kiev.zoral.com.ua> <4CCAE2B6.1050906@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A4wWcVSW3p6tJXaL" Content-Disposition: inline In-Reply-To: <4CCAE2B6.1050906@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, Alexander Zagrebin Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:17:32 -0000 --A4wWcVSW3p6tJXaL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 29, 2010 at 06:05:26PM +0300, Andriy Gapon wrote: > on 29/10/2010 17:53 Kostik Belousov said the following: > > Could it be the priming of the vm object pages content ? >=20 > Sorry, not familiar with this term. > Do you mean prepopulation of vm object with valid pages? >=20 > > Due to double-buffering, and (possibly false) optimization to only >=20 > What optimization? On zfs vnode read, the page from the corresponding vm object is only populated with the vnode data if the page already exists in the object. Not doing the optimization would be to allocate the page uncoditionally on the read if not already present, and copy the data from ARC to the page. >=20 > > perform double-buffering when vm object already has some data cached, > > reads can prime vm object page list before file is mmapped or > > sendfile-ed. > >=20 >=20 > No double-buffering is done to optimize anything. Double-buffering > is a consequence of having page cache and ARC. The special > "double-buffering code" is to just handle that fact - e.g. making > sure that VOP_READ reads data from page cache instead of ARC if it's > possible that the data in them differs (i.e. page cache has more > recent data). > > So, if I understood the term 'priming' correctly, no priming should > ever occur. The priming is done on the first call to VOP_READ() with the right offset after the page is allocated. --A4wWcVSW3p6tJXaL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzK5YcACgkQC3+MBN1Mb4jUgACfTe+Vbokx+wrN/YfHpX2YrOmV 2HIAn0VtobxirJ/xcvAsPYt8oxDw98pf =Lpdl -----END PGP SIGNATURE----- --A4wWcVSW3p6tJXaL-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 15:23:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FC691065670 for ; Fri, 29 Oct 2010 15:23:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6708E8FC14 for ; Fri, 29 Oct 2010 15:22:59 +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 SAA07518; Fri, 29 Oct 2010 18:22:55 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCAE6CE.9020509@icyb.net.ua> Date: Fri, 29 Oct 2010 18:22:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Kostik Belousov References: <4CCACDC0.7050802@icyb.net.ua> <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> <20101029145349.GX2392@deviant.kiev.zoral.com.ua> <4CCAE2B6.1050906@icyb.net.ua> <20101029151727.GY2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101029151727.GY2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Alexander Zagrebin Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:23:00 -0000 on 29/10/2010 18:17 Kostik Belousov said the following: > On Fri, Oct 29, 2010 at 06:05:26PM +0300, Andriy Gapon wrote: >> on 29/10/2010 17:53 Kostik Belousov said the following: >>> Could it be the priming of the vm object pages content ? >> >> Sorry, not familiar with this term. >> Do you mean prepopulation of vm object with valid pages? >> >>> Due to double-buffering, and (possibly false) optimization to only >> >> What optimization? > On zfs vnode read, the page from the corresponding vm object is only > populated with the vnode data if the page already exists in the > object. Do you mean a specific type of read? For "normal" reads it's the other way around - if the page already exists and is valid, then we read from the page, not from ARC. > Not doing the optimization would be to allocate the page uncoditionally > on the read if not already present, and copy the data from ARC to the page. >> >>> perform double-buffering when vm object already has some data cached, >>> reads can prime vm object page list before file is mmapped or >>> sendfile-ed. >>> >> >> No double-buffering is done to optimize anything. Double-buffering >> is a consequence of having page cache and ARC. The special >> "double-buffering code" is to just handle that fact - e.g. making >> sure that VOP_READ reads data from page cache instead of ARC if it's >> possible that the data in them differs (i.e. page cache has more >> recent data). >> >> So, if I understood the term 'priming' correctly, no priming should >> ever occur. > The priming is done on the first call to VOP_READ() with the right > offset after the page is allocated. Again, what is priming? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 15:25:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E01106566B; Fri, 29 Oct 2010 15:25:51 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 75C858FC0C; Fri, 29 Oct 2010 15:25:51 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PBqpx-000FAn-TK; Fri, 29 Oct 2010 19:25:50 +0400 Date: Fri, 29 Oct 2010 19:26:02 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101029152602.GA18613@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCADD37.7000306@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:25:51 -0000 On Fri, Oct 29, 2010 at 05:41:59PM +0300, Andriy Gapon wrote: > What svn revision of FreeBSD source tree did you test? r213936. Revision seems a little old. > Ah, I think I see what's going on. > Either sendfile should (have an option to) use VOP_GETPAGES to request data or ZFS > mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY case. > Currently ZFS would read a whole FS block into ARC, but populate only one page > with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from > ARC data. > So, e.g. zpool iostat would show that there are only few actual reads from a pool. > The rest of the time must be spent churning over the data already in ARC and > doing page-per-VOP_READ copies from it. I can test it, but what allocflags? VM_ALLOC_RETRY|VM_ALLOC_NORMAL? From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 16:06:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78325106564A; Fri, 29 Oct 2010 16:06:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 973988FC1B; Fri, 29 Oct 2010 16:06:08 +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 TAA07885; Fri, 29 Oct 2010 19:06:03 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CCAF0EB.4080001@icyb.net.ua> Date: Fri, 29 Oct 2010 19:06:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> In-Reply-To: <20101029152602.GA18613@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:06:11 -0000 on 29/10/2010 18:26 Artemiev Igor said the following: > On Fri, Oct 29, 2010 at 05:41:59PM +0300, Andriy Gapon wrote: > >> What svn revision of FreeBSD source tree did you test? > > r213936. Revision seems a little old. > >> Ah, I think I see what's going on. >> Either sendfile should (have an option to) use VOP_GETPAGES to request data or ZFS >> mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY case. >> Currently ZFS would read a whole FS block into ARC, but populate only one page >> with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from >> ARC data. >> So, e.g. zpool iostat would show that there are only few actual reads from a pool. >> The rest of the time must be spent churning over the data already in ARC and >> doing page-per-VOP_READ copies from it. > I can test it, but what allocflags? VM_ALLOC_RETRY|VM_ALLOC_NORMAL? Probably yes, but have to be careful there. First, do vm_page_grab only for UIO_NOCOPY case. Second, the first page is already "shared busy" after vm_page_io_start() call in kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a deadlock. I think that it may be good to separate UIO_NOCOPY/sendfile case from mappedread into a function of its own. P.S. doing VOP_GETPAGES instead of vn_rdwr() in kern_sendfile() might be a better idea still. But there are some additional details to that, e.g. a mount/fs flag to tell which mechanism is preferred. Because, as I've been told, vn_rdwr() has better performance than VOP_GETPAGES. Although, I don't understand why it could/should be that way. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 16:14:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A777C106564A for ; Fri, 29 Oct 2010 16:14:10 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 34BA78FC0A for ; Fri, 29 Oct 2010 16:14:09 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBrah-000HnF-UI; Fri, 29 Oct 2010 20:14:07 +0400 From: "Alexander Zagrebin" To: "'Jeremy Chadwick'" References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local><4CCABF73.8070707@icyb.net.ua><4CCACDC0.7050802@icyb.net.ua><1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> <20101029145237.GA78583@icarus.home.lan> Date: Fri, 29 Oct 2010 20:14:07 +0400 Keywords: freebsd-stable Message-ID: <427A82F90F9C484F8022369EAB690830@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <20101029145237.GA78583@icarus.home.lan> Thread-Index: Act3eP8cyASAdQqNS2a9gfsCfUvs3AABeq6g Cc: freebsd-stable@freebsd.org Subject: RE: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:14:10 -0000 > > Can you reproduce the problem on your system? > > I can't reproduce it on mine. Note the resilvering was induced from > some unrelated disk swaps/tests I was performing, and ftpd is already > enabled via inetd on this system. > > What ZFS tunings have you applied to your system? Can you provide > output from "sysctl -a kstat.zfs.misc.arcstats" before and after a > transfer which exhibits the initial slowdown? It's amd64 Intel Atom based system with 2G RAM. /boot/loader.conf contains nothing special: vm.kmem_size="1536M" vfs.zfs.prefetch_disable="1" $ dd if=/dev/random of=test bs=1m count=50; sysctl -a kstat.zfs.misc.arcstats; fetch -o /dev/null http://localhost/test; sysctl -a kstat.zfs.misc.arcstats 50+0 records in 50+0 records out 52428800 bytes transferred in 2.956783 secs (17731705 bytes/sec) kstat.zfs.misc.arcstats.hits: 10889409 kstat.zfs.misc.arcstats.misses: 2482562 kstat.zfs.misc.arcstats.demand_data_hits: 7920924 kstat.zfs.misc.arcstats.demand_data_misses: 1587278 kstat.zfs.misc.arcstats.demand_metadata_hits: 2968455 kstat.zfs.misc.arcstats.demand_metadata_misses: 895284 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 30 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 5596211 kstat.zfs.misc.arcstats.mru_ghost_hits: 199040 kstat.zfs.misc.arcstats.mfu_hits: 5293198 kstat.zfs.misc.arcstats.mfu_ghost_hits: 481006 kstat.zfs.misc.arcstats.allocated: 2985083 kstat.zfs.misc.arcstats.deleted: 1901535 kstat.zfs.misc.arcstats.stolen: 1269643 kstat.zfs.misc.arcstats.recycle_miss: 464100 kstat.zfs.misc.arcstats.mutex_miss: 658 kstat.zfs.misc.arcstats.evict_skip: 148879 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 150609301504 kstat.zfs.misc.arcstats.evict_l2_ineligible: 36864 kstat.zfs.misc.arcstats.hash_elements: 91782 kstat.zfs.misc.arcstats.hash_elements_max: 168546 kstat.zfs.misc.arcstats.hash_collisions: 2058158 kstat.zfs.misc.arcstats.hash_chains: 23888 kstat.zfs.misc.arcstats.hash_chain_max: 18 kstat.zfs.misc.arcstats.p: 807441359 kstat.zfs.misc.arcstats.c: 1006632960 kstat.zfs.misc.arcstats.c_min: 125829120 kstat.zfs.misc.arcstats.c_max: 1006632960 kstat.zfs.misc.arcstats.size: 1006690472 kstat.zfs.misc.arcstats.hdr_size: 20252216 kstat.zfs.misc.arcstats.data_size: 917198336 kstat.zfs.misc.arcstats.other_size: 69239920 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 9 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 30 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 /dev/null 100% of 50 MB 119 kBps 00m00s kstat.zfs.misc.arcstats.hits: 10928358 kstat.zfs.misc.arcstats.misses: 2486504 kstat.zfs.misc.arcstats.demand_data_hits: 7959052 kstat.zfs.misc.arcstats.demand_data_misses: 1590868 kstat.zfs.misc.arcstats.demand_metadata_hits: 2969276 kstat.zfs.misc.arcstats.demand_metadata_misses: 895636 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 30 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 5601378 kstat.zfs.misc.arcstats.mru_ghost_hits: 199211 kstat.zfs.misc.arcstats.mfu_hits: 5326980 kstat.zfs.misc.arcstats.mfu_ghost_hits: 482037 kstat.zfs.misc.arcstats.allocated: 2989914 kstat.zfs.misc.arcstats.deleted: 1904492 kstat.zfs.misc.arcstats.stolen: 1272047 kstat.zfs.misc.arcstats.recycle_miss: 464306 kstat.zfs.misc.arcstats.mutex_miss: 658 kstat.zfs.misc.arcstats.evict_skip: 148880 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 150970209280 kstat.zfs.misc.arcstats.evict_l2_ineligible: 36864 kstat.zfs.misc.arcstats.hash_elements: 92084 kstat.zfs.misc.arcstats.hash_elements_max: 168546 kstat.zfs.misc.arcstats.hash_collisions: 2062370 kstat.zfs.misc.arcstats.hash_chains: 23974 kstat.zfs.misc.arcstats.hash_chain_max: 18 kstat.zfs.misc.arcstats.p: 810895823 kstat.zfs.misc.arcstats.c: 1006632960 kstat.zfs.misc.arcstats.c_min: 125829120 kstat.zfs.misc.arcstats.c_max: 1006632960 kstat.zfs.misc.arcstats.size: 1006658848 kstat.zfs.misc.arcstats.hdr_size: 20246240 kstat.zfs.misc.arcstats.data_size: 917672960 kstat.zfs.misc.arcstats.other_size: 68739648 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 9 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 30 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 16:25:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7425106566C; Fri, 29 Oct 2010 16:25:37 +0000 (UTC) (envelope-from me@pollux.local.net) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 64D5B8FC16; Fri, 29 Oct 2010 16:25:34 +0000 (UTC) Received: from pollux.local.net (unknown [82.246.30.233]) by smtp4-g21.free.fr (Postfix) with ESMTP id E56D54C80D7; Fri, 29 Oct 2010 18:25:28 +0200 (CEST) Received: by pollux.local.net (Postfix, from userid 2000) id 7B67429011; Fri, 29 Oct 2010 18:25:27 +0200 (CEST) Date: Fri, 29 Oct 2010 18:25:27 +0200 From: Harald Weis To: freebsd-stable@freebsd.org, MAINTAINER Message-ID: <20101029162527.GA1940@pollux.local.net> Mail-Followup-To: freebsd-stable@freebsd.org, MAINTAINER , Doug Barton References: <20101008180046.GA2867@pollux.local.net> <20101009203629.GA2135@pollux.local.net> <20101012195629.GC27117@pollux.local.net> <20101018120227.GA1920@pollux.local.net> <20101019110939.GA21157@pollux.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101019110939.GA21157@pollux.local.net> User-Agent: Mutt/1.4.2.3i Cc: Doug Barton Subject: linux_base-f10 [Was: Re: VirtualBox OpenSolaris guest becomes: portmaster] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:25:37 -0000 On Tue, Oct 19, 2010 at 01:09:39PM +0200, Harald Weis wrote: > On Mon, Oct 18, 2010 at 08:32:04AM -0400, Alex Goncharov wrote: > > ,--- You/Harald (Mon, 18 Oct 2010 14:02:27 +0200) ----* > > | What else could I possibly do? > > > > | - portmaster www/opera-linuxplugins # installing linux_base-f10-10_3, > > | then stopping as follows: > > | ===> Installing for linux-f10-expat-2.0.1 > > | ===> Generating temporary packing list > > | brandelf: error opening file usr/bin/xmlwf: No such file or directory > > | *** Error code 1 > > > > | Stop in /usr/ports/textproc/linux-f10-expat. > > > > I am not using portmaster; try do it simply through make. I just did > > it now: > > > > ---------------------------------------------------------------------- > > cat /compat/linux/etc/fedora-release > > Fedora release 10 (Cambridge) > > Ah, I see, that's it. I can't run this cat command because my > /compat/linux directory is empty. Obviously it went always wrong with > portmaster emulators/linux_base-f10. This command should have populated > the linuxbase, i.e. /compat/linux, directory if I understand correctly. > The script (I kept it) shows no problem whatsoever. The Makefile says > clearly to use the linuxbase as prefix for installation. > Portmaster seems to be responsible here. Please note that portmaster > is my friend since July 2008. Without any problem! In my humble > opinion portmaster is quite an extraordinary tool. By far I prefer it to > portupgrade. > Presently, there seems to be a problem just with the linux stuff. > Doug, may I ask you for help please ? > > Now I will go and reinstall for the third time all ports with > portmaster `cat ~/installed-port-list` which did work like a charm last > time and then install the linux ports with make. I've done it and there is absolutely no change. In fact, I am not surprised. It was unreasonable to accuse portmaster which works fine for all ports. Why should it fail only for the linux ports? I cannot find out why the linux_base-f10 files are not installed in the linuxbase (/compat/linux). The typescript says: ===> Patching for linux_base-f10-10_3 ===> Configuring for linux_base-f10-10_3 ===> Building for linux_base-f10-10_3 ===> Installing for linux_base-f10-10_3 ===> Generating temporary packing list ===> Checking if emulators/linux_base-f10 already installed 274736 blocks +++ Some programs may need linprocfs, please add it to /etc/fstab! +++ Running linux ldconfig... This software is based in part on the work of the FreeType Team. See . Installation of the Linux base system is finished. The Linux kernel mode, which must be enabled for Linux binaries to run, is now enabled. Linux mode can be enabled permanently with the linux_enable variable of rc.conf(5). NOTHING has been installed in /compat/linux in spite of the USE_LINUX_PREFIX=yes line in Makefile. No wonder that the system gets broken. This time I've succeeded in repairing it - more or less - without reinstalling _all_ ports. As I said earlier, nothing in the typescript indicates that something went wrong. Testing the LINUXBASE variable is also alright: me@pollux:/<3>linux_base-f10 # make clean ===> Cleaning for linux_base-f10-10_3 me@pollux:/<3>linux_base-f10 # make -V LINUXBASE /compat/linux me@pollux:/<3>linux_base-f10 # For the next (fourth) experiment I would like to run "make install WITH_DEBUG=yes" . Is that okay or is there a better way? Thank you in advance, Harald From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 16:34:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EA191065672 for ; Fri, 29 Oct 2010 16:34:20 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by mx1.freebsd.org (Postfix) with ESMTP id 35E378FC12 for ; Fri, 29 Oct 2010 16:34:19 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=l9fkLYjJz4lSk2fMO0FvN+8JgHoQbkGYmy6bk8H7oAwApxc7gT32Fc0fDsI48d1J; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PBqif-0004dO-0p for freebsd-stable@freebsd.org; Fri, 29 Oct 2010 11:18:17 -0400 Message-ID: <4CCAE59E.5020006@earthlink.net> Date: Fri, 29 Oct 2010 11:17:50 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec791618b0570834f9695c2f50a5d4d74682350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Subject: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:34:20 -0000 Hello, I am having a problem getting 6.3 to boot on an intel atom mb. When it gets to where it should identify the drive it hangs. If I boot with no acpi it does the same thing. If I boot with safe mode it comes up and identifies the drive but then starts spewing the following errors: ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to ad interrupt storm detected on "irq15:"; throttling interrupt source ad4: 152627MB at ata2-master PIO4 interrupt storm detected on "irq15:"; throttling interrupt source interrupt storm detected on "irq15:"; throttling interrupt source interrupt storm detected on "irq15:"; throttling interrupt source FreeBSD runs but I continue to get these errors: What exactly does safe mode do - I am afraid my forth skills are not what they should be. Is there some device.hints I could set to correct this problem? A pciconf listing follows. # pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0xa0008086 chip=0xa0008086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0xa0018086 chip=0xa0018086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0xa0018086 chip=0xa0028086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = display uhci0@pci0:0:26:0: class=0x0c0300 card=0x28348086 chip=0x28348086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci1@pci0:0:26:1: class=0x0c0300 card=0x28358086 chip=0x28358086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB ehci0@pci0:0:26:7: class=0x0c0320 card=0x283a8086 chip=0x283a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '81EC1043 (?) ICH8 Enhanced USB2 Enhanced Host Controller' class = serial bus subclass = USB none0@pci0:0:27:0: class=0x040300 card=0xa62516f3 chip=0x284b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8' class = multimedia subclass = HDA pcib1@pci0:0:28:0: class=0x060400 card=0x283f8086 chip=0x283f8086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 1' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:3: class=0x060400 card=0x28458086 chip=0x28458086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 4' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:4: class=0x060400 card=0x28478086 chip=0x28478086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) PCIe Port 5' class = bridge subclass = PCI-PCI uhci2@pci0:0:29:0: class=0x0c0300 card=0x28308086 chip=0x28308086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci3@pci0:0:29:1: class=0x0c0300 card=0x28318086 chip=0x28318086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB uhci4@pci0:0:29:2: class=0x0c0300 card=0x28328086 chip=0x28328086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x28368086 chip=0x28368086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB2 EHCI' class = serial bus subclass = USB pcib4@pci0:0:30:0: class=0x060401 card=0x24488086 chip=0x24488086 rev=0xf3 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x28158086 chip=0x28158086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH8M-E (ICH8 Family) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x28508086 chip=0x28508086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) Ultra ATA Storage Controllers' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x01018f card=0x28288086 chip=0x28288086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH8M (ICH8 Family) 3 port SATA Controller' class = mass storage subclass = ATA none1@pci0:0:31:3: class=0x0c0500 card=0x283e8086 chip=0x283e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus re0@pci0:2:0:0: class=0x020000 card=0x816810ec chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet rl0@pci0:4:4:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class = network subclass = ethernet rl1@pci0:4:6:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class = network subclass = ethernet rl2@pci0:4:7:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class = network subclass = ethernet I am stuck for now on 6.3 so moving to a later release 7+ is not feasible. Additional info: 6.4 exhibits the same behavior. 7.2 boots okay in normal mode. If there is a patch I could apply to 6.3 I am not averse to that. Thanks for any help, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 16:54:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA6D11065673 for ; Fri, 29 Oct 2010 16:54:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 66E508FC14 for ; Fri, 29 Oct 2010 16:54:06 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id QgST1f0091YDfWL5Fgu7do; Fri, 29 Oct 2010 16:54:07 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta20.westchester.pa.mail.comcast.net with comcast id Qgu61f00L3LrwQ23ggu7Gx; Fri, 29 Oct 2010 16:54:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 653849B422; Fri, 29 Oct 2010 09:54:05 -0700 (PDT) Date: Fri, 29 Oct 2010 09:54:05 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20101029165405.GA82279@icarus.home.lan> References: <4CCAE59E.5020006@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCAE59E.5020006@earthlink.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:54:07 -0000 On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote: > I am having a problem getting 6.3 to boot on an intel atom mb. When > it gets to where it should identify the drive it hangs. Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead? I mean, you *are* using an Intel Atom system, which contains significantly more advanced hardware than was available during the RELENG_6 days. Oh, I think you answer this further down... > If I boot with no acpi it does the same thing. > > If I boot with safe mode it comes up and identifies the drive but then > starts spewing the following errors: > ipfw2 initialized, divert enabled, rule-based forwarding disabled, > default to ad > interrupt storm detected on "irq15:"; throttling interrupt source > ad4: 152627MB at ata2-master PIO4 > interrupt storm detected on "irq15:"; throttling interrupt source > interrupt storm detected on "irq15:"; throttling interrupt source > interrupt storm detected on "irq15:"; throttling interrupt source > > FreeBSD runs but I continue to get these errors: > > What exactly does safe mode do - I am afraid my forth skills are not > what they should be. "Safe mode" does the following before doing "boot": set hw.ata.ata_dma=0 set hw.ata.atapi_dma=0 set hw.ata.wc=0 set hw.eisa_slots=0 set hint.kbdmux.0.disabled=1 It also does the following if you're booting/running i386: unset acpi_load set hint.acpi.0.disabled=1 set loader.acpi_disabled_by_user=1 set hint.apic.0.disabled=1 The code is in /boot/beastie.4th. IMHO, you shouldn't be disabling ACPI, or using "safe mode" to try and get your system working. Can you please boot Verbose mode instead and provide all of the output somewhere? You'll probably need serial console for this, since the system hangs. > atapci0@pci0:0:31:1: class=0x01018a card=0x28508086 > chip=0x28508086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801H (ICH8 Family) Ultra ATA Storage Controllers' > class = mass storage > subclass = ATA > atapci1@pci0:0:31:2: class=0x01018f card=0x28288086 > chip=0x28288086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'ICH8M (ICH8 Family) 3 port SATA Controller' > class = mass storage > subclass = ATA Your storage controller is an Intel ICH8, which is supported by FreeBSD, but the ATA layer differs greatly between 6.x and 8.x (read: better on 8.x). AHCI is also well-supported on 8.x if your system/BIOS supports it. > I am stuck for now on 6.3 so moving to a later release 7+ is not feasible. Can you explain why? (If I don't ask it, someone else will.) This will almost certainly be the key to this discussion, especially since you say: > Additional info: > 6.4 exhibits the same behavior. 7.2 boots okay in normal mode. You should probably read this, specifically the fact that the RELENG_6 branch is being EOL'd in about 30 days. http://www.freebsd.org/security/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 17:12:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0844E106566B for ; Fri, 29 Oct 2010 17:12:32 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by mx1.freebsd.org (Postfix) with ESMTP id B20DC8FC12 for ; Fri, 29 Oct 2010 17:12:31 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=kW9ITa7RvRFbxbrP2fRgRUUtOCZVyouhP6pFTqmIIitKViV0Peq4zNeS6DGSO3Ma; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PBsVC-0006tQ-Jb; Fri, 29 Oct 2010 13:12:31 -0400 Message-ID: <4CCB007D.8080204@earthlink.net> Date: Fri, 29 Oct 2010 13:12:29 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4CCAE59E.5020006@earthlink.net> <20101029165405.GA82279@icarus.home.lan> In-Reply-To: <20101029165405.GA82279@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec7947ac7ffae4e054066798f50161827a4e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: FreeBSD Stable Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 17:12:32 -0000 On 10/29/2010 12:54 PM, Jeremy Chadwick wrote: > On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote: > >> I am having a problem getting 6.3 to boot on an intel atom mb. When >> it gets to where it should identify the drive it hangs. >> > Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead? I mean, you > *are* using an Intel Atom system, which contains significantly more > advanced hardware than was available during the RELENG_6 days. > > Oh, I think you answer this further down... > > >> If I boot with no acpi it does the same thing. >> >> If I boot with safe mode it comes up and identifies the drive but then >> starts spewing the following errors: >> ipfw2 initialized, divert enabled, rule-based forwarding disabled, >> default to ad >> interrupt storm detected on "irq15:"; throttling interrupt source >> ad4: 152627MB at ata2-master PIO4 >> interrupt storm detected on "irq15:"; throttling interrupt source >> interrupt storm detected on "irq15:"; throttling interrupt source >> interrupt storm detected on "irq15:"; throttling interrupt source >> >> FreeBSD runs but I continue to get these errors: >> >> What exactly does safe mode do - I am afraid my forth skills are not >> what they should be. >> > "Safe mode" does the following before doing "boot": > > set hw.ata.ata_dma=0 > set hw.ata.atapi_dma=0 > set hw.ata.wc=0 > set hw.eisa_slots=0 > set hint.kbdmux.0.disabled=1 > > It also does the following if you're booting/running i386: > > unset acpi_load > set hint.acpi.0.disabled=1 > set loader.acpi_disabled_by_user=1 > set hint.apic.0.disabled=1 > > The code is in /boot/beastie.4th. > > IMHO, you shouldn't be disabling ACPI, or using "safe mode" to try and > get your system working. Can you please boot Verbose mode instead and > provide all of the output somewhere? You'll probably need serial > console for this, since the system hangs. > > > >> atapci0@pci0:0:31:1: class=0x01018a card=0x28508086 >> chip=0x28508086 rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801H (ICH8 Family) Ultra ATA Storage Controllers' >> class = mass storage >> subclass = ATA >> atapci1@pci0:0:31:2: class=0x01018f card=0x28288086 >> chip=0x28288086 rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'ICH8M (ICH8 Family) 3 port SATA Controller' >> class = mass storage >> subclass = ATA >> > Your storage controller is an Intel ICH8, which is supported by FreeBSD, > but the ATA layer differs greatly between 6.x and 8.x (read: better on > 8.x). AHCI is also well-supported on 8.x if your system/BIOS supports > it. > > >> I am stuck for now on 6.3 so moving to a later release 7+ is not feasible. >> > Can you explain why? (If I don't ask it, someone else will.) This will > almost certainly be the key to this discussion, especially since you > say: > > I am supporting over 700 units in the field that are acting as firewall/router/vpn devices, that are running 6.3. It would not be feasible to upgrade them to a new version of FreeBSD remotely. Also if I was going to move to a later release of FreeBSD for the new hardware it would involve months of new testing and validation of the new release, where putting a patched 6.3 kernel is relatively straightforward. Verbose boot output at the end. >> Additional info: >> 6.4 exhibits the same behavior. 7.2 boots okay in normal mode. >> > You should probably read this, specifically the fact that the RELENG_6 > branch is being EOL'd in about 30 days. > > http://www.freebsd.org/security/ > > � Select option, [Enter] for default � � or [Space] to pause timer 5 � /boot/kernel/acpi.ko text=0x44a7c data=0x24c0+0x1b8c syms=[0x4+0x7d50+0x4+0xaa]| SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000003f5a0000 SMAP type=03 base=000000003f6a0000 len=000000000000e000 SMAP type=04 base=000000003f6ae000 len=0000000000032000 SMAP type=02 base=000000003f6e0000 len=0000000000010000 SMAP type=02 base=000000003f6f0000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffb00000 len=0000000000500000 Copyright (c) 1992-2008 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 6.3-RELEASE-p15 #17: Fri Apr 16 12:51:57 EST 2010 root@Z2984.netwolves.com:/usr/src/sys/i386/compile/WOLFPAC6SMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bfd000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0bfd19c. MP Configuration Table version 1.4 found at 0xc00fdc90 Table 'FACP' at 0x3f6a0290 Table 'APIC' at 0x3f6a0390 MADT: Found table at 0x3f6a0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) INTR: Adding local APIC 0 as a target ACPI APIC Table: <080610 APIC1657> Calibrating clock(s) ... i8254 clock: 1193267 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1666659490 Hz CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.66-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106ca Stepping = 10 Features=0xbfebfbff Features2=0x40e31d> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Logical CPUs per core: 2 real memory = 1063911424 (1014 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000003e481fff, 1032167424 bytes (251994 pages) avail memory = 1031905280 (984 MB) INTR: Adding local APIC 2 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f6100 pnpbios: Entry = f0000:78ba Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 4 MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 4 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 crypto: wlan: <802.11 Link Layer> nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: null: random: npx0: INT 16 interface acpi0: <080610 XSDT1657> on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=a0008086) pcibios: BIOS version 3.00 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xd8a5b000 pa 0x8e000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.FHR0 -> bus 0 dev 31 func 0 acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 0/5682 1/1 1/1 -> 9 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0xa000, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0xa001, revid=0x02 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base fe980000, size 19, enabled map[14]: type 4, range 32, base 0000cc00, size 3, enabled map[18]: type 3, range 32, base d0000000, size 28, enabled map[1c]: type 1, range 32, base fe800000, size 20, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa002, revid=0x02 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fe780000, size 19, enabled found-> vendor=0x8086, dev=0x2834, revid=0x03 bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type 4, range 32, base 0000c880, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2835, revid=0x03 bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 0000c800, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x03 bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fe977c00, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x284b, revid=0x03 bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base fe970000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283f, revid=0x03 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2845, revid=0x03 bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2847, revid=0x03 bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2830, revid=0x03 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type 4, range 32, base 0000c480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2831, revid=0x03 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 0000c400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2832, revid=0x03 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type 4, range 32, base 0000c080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2836, revid=0x03 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fe977800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xf3 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x03 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2850, revid=0x03 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x2828, revid=0x03 bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 powerspec 3 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000c000, size 3, enabled map[14]: type 4, range 32, base 0000bc00, size 2, enabled map[18]: type 4, range 32, base 0000b880, size 3, enabled map[1c]: type 4, range 32, base 0000b800, size 2, enabled map[20]: type 4, range 32, base 0000b480, size 4, enabled map[24]: type 4, range 32, base 0000b400, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 18 found-> vendor=0x8086, dev=0x283e, revid=0x03 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type 1, range 32, base fe977400, size 8, enabled map[20]: type 4, range 32, base 00000400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 17 pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) uhci0: port 0xc880-0xc89f irq 16 at device 26.00 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc880 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f irq 21 at device 26.10 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfe977c00-0xfe977fff irq 18 at 0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe977c00 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pci0: at device 27.0 (no driver attached) pcib1: irq 22 at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: memory decode 0x0-0x0 pcib1: prefetched decode 0x0-0x0 pci1: on pcib1 pci1: physical bus=1 pcib2: irq 21 at device 28.3 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: prefetched decode 0xfdf00000-0xfdffffff pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x03 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type 4, range 32, base 0000d800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type 3, range 64, base fdfff000, size 12, enabled pcib2: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type 3, range 64, base fdff8000, size 14, enabled pcib2: requested memory range 0xfdff8000-0xfdffbfff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd800 pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pci2: at device 0.0 (no driver attached) pcib3: irq 22 at device 28.4 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x0-0x0 pcib3: memory decode 0x0-0x0 pcib3: prefetched decode 0x0-0x0 pci3: on pcib3 pci3: physical bus=3 uhci2: port 0xc480-0xc49f irq 23 at device 29.00 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc480 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 uhci2: [GIANT-LOCKED] usb3: on uhci2 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xc400-0xc41f irq 19 at device 29.10 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc400 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 uhci3: [GIANT-LOCKED] usb4: on uhci3 usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xc080-0xc09f irq 18 at device 29.20 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc080 uhci4: [GIANT-LOCKED] usb5: on uhci4 usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfe977800-0xfe977bff irq 23 at 0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe977800 ehci1: [GIANT-LOCKED] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub6: 6 ports with 6 removable, self powered umass0: HP v100w, rev 2.00/20.48, addr 2 umass0:0:0:-1: Attached to scbus0 pcib4: at device 30.0 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xe000-0xefff pcib4: memory decode 0xfeb00000-0xfebfffff pcib4: prefetched decode 0xfff00000-0xfffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: physical bus=4 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=4, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=15 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e800, size 8, enabled pcib4: requested I/O range 0xe800-0xe8ff: in range map[14]: type 1, range 32, base febffc00, size 8, enabled pcib4: requested memory range 0xfebffc00-0xfebffcff: good pcib4: matched entry for 4.4.INTA pcib4: slot 4 INTA hardwired to IRQ 18 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=4, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 8, enabled pcib4: requested I/O range 0xe400-0xe4ff: in range map[14]: type 1, range 32, base febff800, size 8, enabled pcib4: requested memory range 0xfebff800-0xfebff8ff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 19 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=4, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled pcib4: requested I/O range 0xe000-0xe0ff: in range map[14]: type 1, range 32, base febff400, size 8, enabled pcib4: requested memory range 0xfebff400-0xfebff4ff: good pcib4: matched entry for 4.7.INTA pcib4: slot 7 INTA hardwired to IRQ 16 rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe800 pcib4: re0 requested I/O range 0xe800-0xe8ff: in range pcib4: rl0 requested I/O range 0xe800-0xe8ff: in range rl0: port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff i4 pcib4: rl0 requested I/O range 0xe800-0xe8ff: in range miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:30:18:a1:7f:e9 rl0: [MPSAFE] rl1: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 pcib4: re0 requested I/O range 0xe400-0xe4ff: in range pcib4: rl1 requested I/O range 0xe400-0xe4ff: in range rl1: port 0xe400-0xe4ff mem 0xfebff800-0xfebff8ff i4 pcib4: rl1 requested I/O range 0xe400-0xe4ff: in range miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: bpf attached rl1: Ethernet address: 00:30:18:a1:7f:ea rl1: [MPSAFE] rl2: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe000 pcib4: re0 requested I/O range 0xe000-0xe0ff: in range pcib4: rl2 requested I/O range 0xe000-0xe0ff: in range rl2: port 0xe000-0xe0ff mem 0xfebff400-0xfebff4ff i4 pcib4: rl2 requested I/O range 0xe000-0xe0ff: in range miibus2: on rl2 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl2: bpf attached rl2: Ethernet address: 00:30:18:a1:7f:eb rl2: [MPSAFE] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa00 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: reset tp2 stat0=87 stat1=8f devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] atapci1: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480 atapci1: [MPSAFE] ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: Changing trigger for pin 4 to level ioapic0: Changing polarity for pin 4 to low ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: Changing trigger for pin 3 to level ioapic0: Changing polarity for pin 3 to low ioapic0: routing intpin 3 (ISA IRQ 3) to vector 57 ppc0: using extended I/O port range ioapic0: Changing trigger for pin 7 to level ioapic0: Changing polarity for pin 7 to low ppc0: SPP ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 58 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x83ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 59 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 83332993 hz Timecounter "TSC" frequency 1666659490 Hz quality -100 Timecounters tick every 4.000 msec crypto: crypto: assign driver 0, flags 6 crypto: driver 0 registers alg 1 flags 0 maxoplen 0 crypto: driver 0 registers alg 2 flags 0 maxoplen 0 crypto: driver 0 registers alg 3 flags 0 maxoplen 0 crypto: driver 0 registers alg 4 flags 0 maxoplen 0 crypto: driver 0 registers alg 5 flags 0 maxoplen 0 crypto: driver 0 registers alg 16 flags 0 maxoplen 0 crypto: driver 0 registers alg 6 flags 0 maxoplen 0 crypto: driver 0 registers alg 7 flags 0 maxoplen 0 crypto: driver 0 registers alg 18 flags 0 maxoplen 0 crypto: driver 0 registers alg 19 flags 0 maxoplen 0 crypto: driver 0 registers alg 20 flags 0 maxoplen 0 crypto: driver 0 registers alg 8 flags 0 maxoplen 0 crypto: driver 0 registers alg 15 flags 0 maxoplen 0 crypto: driver 0 registers alg 9 flags 0 maxoplen 0 crypto: driver 0 registers alg 10 flags 0 maxoplen 0 crypto: driver 0 registers alg 13 flags 0 maxoplen 0 crypto: driver 0 registers alg 14 flags 0 maxoplen 0 crypto: driver 0 registers alg 11 flags 0 maxoplen 0 crypto: driver 0 registers alg 17 flags 0 maxoplen 0 Fast IPsec: Initialized Security Association Processing. ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to ad lo0: bpf attached DUMMYNET with IPv6 initialized (040826) -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 17:40:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC811065674 for ; Fri, 29 Oct 2010 17:40:17 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id E2BEE8FC13 for ; Fri, 29 Oct 2010 17:40:16 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta09.emeryville.ca.mail.comcast.net with comcast id QgCW1f0071bwxycA9hgGQf; Fri, 29 Oct 2010 17:40:16 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta18.emeryville.ca.mail.comcast.net with comcast id QhgF1f0013LrwQ28ehgFYC; Fri, 29 Oct 2010 17:40:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 023BF9B422; Fri, 29 Oct 2010 10:40:15 -0700 (PDT) Date: Fri, 29 Oct 2010 10:40:14 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20101029174014.GA82936@icarus.home.lan> References: <4CCAE59E.5020006@earthlink.net> <20101029165405.GA82279@icarus.home.lan> <4CCB007D.8080204@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCB007D.8080204@earthlink.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 17:40:17 -0000 On Fri, Oct 29, 2010 at 01:12:29PM -0400, Stephen Clark wrote: > On 10/29/2010 12:54 PM, Jeremy Chadwick wrote: > >On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote: > >>I am having a problem getting 6.3 to boot on an intel atom mb. When > >>it gets to where it should identify the drive it hangs. > >Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead? I mean, you > >*are* using an Intel Atom system, which contains significantly more > >advanced hardware than was available during the RELENG_6 days. > > > >Oh, I think you answer this further down... > > > >>If I boot with no acpi it does the same thing. > >> > >>If I boot with safe mode it comes up and identifies the drive but then > >>starts spewing the following errors: > >>ipfw2 initialized, divert enabled, rule-based forwarding disabled, > >>default to ad > >>interrupt storm detected on "irq15:"; throttling interrupt source > >>ad4: 152627MB at ata2-master PIO4 > >>interrupt storm detected on "irq15:"; throttling interrupt source > >>interrupt storm detected on "irq15:"; throttling interrupt source > >>interrupt storm detected on "irq15:"; throttling interrupt source > >> > >>FreeBSD runs but I continue to get these errors: > >> > >>What exactly does safe mode do - I am afraid my forth skills are not > >>what they should be. > >"Safe mode" does the following before doing "boot": > > > >set hw.ata.ata_dma=0 > >set hw.ata.atapi_dma=0 > >set hw.ata.wc=0 > >set hw.eisa_slots=0 > >set hint.kbdmux.0.disabled=1 > > > >It also does the following if you're booting/running i386: > > > >unset acpi_load > >set hint.acpi.0.disabled=1 > >set loader.acpi_disabled_by_user=1 > >set hint.apic.0.disabled=1 > > > >The code is in /boot/beastie.4th. > > > >IMHO, you shouldn't be disabling ACPI, or using "safe mode" to try and > >get your system working. Can you please boot Verbose mode instead and > >provide all of the output somewhere? You'll probably need serial > >console for this, since the system hangs. > > > > > >>atapci0@pci0:0:31:1: class=0x01018a card=0x28508086 > >>chip=0x28508086 rev=0x03 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = '82801H (ICH8 Family) Ultra ATA Storage Controllers' > >> class = mass storage > >> subclass = ATA > >>atapci1@pci0:0:31:2: class=0x01018f card=0x28288086 > >>chip=0x28288086 rev=0x03 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'ICH8M (ICH8 Family) 3 port SATA Controller' > >> class = mass storage > >> subclass = ATA > >Your storage controller is an Intel ICH8, which is supported by FreeBSD, > >but the ATA layer differs greatly between 6.x and 8.x (read: better on > >8.x). AHCI is also well-supported on 8.x if your system/BIOS supports > >it. > > > >>I am stuck for now on 6.3 so moving to a later release 7+ is not feasible. > >Can you explain why? (If I don't ask it, someone else will.) This will > >almost certainly be the key to this discussion, especially since you > >say: > > > I am supporting over 700 units in the field that are acting as > firewall/router/vpn devices, > that are running 6.3. It would not be feasible to upgrade them to a > new version of FreeBSD > remotely. Also if I was going to move to a later release of FreeBSD > for the new hardware > it would involve months of new testing and validation of the new > release, where putting a patched > 6.3 kernel is relatively straightforward. I'm a little confused. Did you deploy over 700 field units running FreeBSD 6.3 without testing it first on this particular piece of hardware/setup? Or did you recently upgrade from FreeBSD X.Y to 6.3 and found that things broke? What I'm trying to find out is whether or not these systems ever worked for you, and if so, at what point did they stop working. Possibly we can work backwards to figure out what code change/commit broke things for you. Keep reading for some ideas. First question: are you using any parameters in /boot/loader.conf or /boot.config? If so, what are they? Second question: can you provide your kernel configuration file? As for the verbose boot -- thanks much. Appropriate folks should be here on the list, so if they have ideas they'll probably reply. A quick analysis indicates the following: ata0 --> atapci0 --> Intel ATA controller master, IDE/PATA, IRQ 14 ata1 --> atapci0 --> Intel ATA controller slave, IDE/PATA, IRQ 14 ata2 --> atapci1 --> Intel ATA controller master, IDE/PATA, IRQ 15 ata3 --> atapci1 --> Intel ATA controller slave, IDE/PATA, IRQ 15 A single device is found on ata2, but no other devices are found on the other ATA busses: > ata2: reset tp2 stat0=50 stat1=00 devices=0x1 That probably correlates with what you see when you boot "safe mode", since there we see this message: ad4: 152627MB at ata2-master PIO4 However, there's other messages which are a serious concern, given their association with the ATA controller in question: interrupt storm detected on "irq15:"; throttling interrupt source interrupt storm detected on "irq15:"; throttling interrupt source interrupt storm detected on "irq15:"; throttling interrupt source interrupt storm detected on "irq15:"; throttling interrupt source You might try escaping to the loader prompt (I forget what menu item it is on 6.x, might be item 6) and entering the following commands. These are the 3 things I'd try first, and in this order: 1) set hint.apic.0.disabled=1 boot 2) set hw.ata.ata_dma=0 boot 3) set hint.apic.0.disabled=1 set hw.ata.ata_dma=0 set hint.kbdmux.0.disabled=1 boot If any of these work (I'm hoping #1 or #2 suffices), you can add the appropriate lines to your /boot/loader.conf without the "set" portion and they should be retained going forward. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 17:50:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68DC61065670; Fri, 29 Oct 2010 17:50:55 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 12BB78FC0A; Fri, 29 Oct 2010 17:50:54 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PBt6L-000HYZ-O5; Fri, 29 Oct 2010 21:50:53 +0400 Date: Fri, 29 Oct 2010 21:51:05 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101029175105.GB18613@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCAF0EB.4080001@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 17:50:55 -0000 On Fri, Oct 29, 2010 at 07:06:03PM +0300, Andriy Gapon wrote: > Probably yes, but have to be careful there. > First, do vm_page_grab only for UIO_NOCOPY case. > Second, the first page is already "shared busy" after vm_page_io_start() call in > kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a deadlock. RELENG_8 doesn`t have VM_ALLOC_IGN_SBUSY, it appeared only in HEAD. Can you review this patch, Whether correctly I have understood? (didnt test it yet) --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2010-10-29 18:18:23.921078337 +0200 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-10-29 19:23:48.142513084 +0200 @@ -449,7 +449,7 @@ int bytes = MIN(PAGESIZE - off, len); again: - if ((m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL && + if (uio->uio_segflg != UIO_NOCOPY && (m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL && vm_page_is_valid(m, off, bytes)) { if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; @@ -464,7 +464,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -472,11 +472,9 @@ * but it pessimize performance of sendfile/UFS, that's * why I handle this special case in ZFS code. */ - KASSERT(off == 0, - ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) - goto again; - vm_page_busy(m); + if((m = vm_page_lookup(obj, OFF_TO_IDX(start))) == NULL || !vm_page_is_valid(m, off, bytes)) + m = vm_page_grab(obj, OFF_TO_IDX(start), VM_ALLOC_NORMAL|VM_ALLOC_RETRY); + VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 18:34:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 089CB1065670 for ; Fri, 29 Oct 2010 18:34:44 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 717148FC19 for ; Fri, 29 Oct 2010 18:34:43 +0000 (UTC) Received: by qwg8 with SMTP id 8so1338332qwg.13 for ; Fri, 29 Oct 2010 11:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=97VuYfAkQJwseDuQe31lWKl8HqDoec3H8pPUa4wX5KI=; b=KJT3fmGEsY03Nsz4Tqt31CGe+K8cIRzmfL7sEuUUO7LXKAxUwaIrybY2JBY1EUAQNU ePh0P5lpSLIH0mZlg42lvzrftqoSjv51SDNyFQM7SUh4gaGM9o0YNoSk0jTv+/yAyNNm w/bj1S6OJ+iJssHn+wUR5ZKqKJwNOwU7+eqTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XrqO5WGhGLG9cBKegE4qhCSQ2/DGcPbFVNT3W+G4jj+68nzQFnAmrBauvps8P0KIEi SkHrYxTKGwDfVQju40DcSS9sUDuDT/pPW/gaASnVN36naIHudGles0zDuV7vXj8/Ngre Lh2rgi+OZ9Igp4DNQJMJ4f3Jk9ubHELx/n4vI= MIME-Version: 1.0 Received: by 10.229.214.73 with SMTP id gz9mr11977692qcb.226.1288377282128; Fri, 29 Oct 2010 11:34:42 -0700 (PDT) Received: by 10.229.110.12 with HTTP; Fri, 29 Oct 2010 11:34:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 11:34:41 -0700 Message-ID: From: Rumen Telbizov To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 18:34:44 -0000 Hi Artem, everyone, Thanks once again for your feedback and help. Here's more information. # zpool export tank # ls /dev/gpt disk-e1:s10 disk-e1:s11 disk-e1:s12 disk-e1:s13 disk-e1:s14 disk-e1:s15 disk-e1:s16 disk-e1:s18 disk-e1:s19 disk-e1:s20 disk-e1:s21 disk-e1:s22 disk-e1:s23 disk-e1:s3 disk-e1:s4 disk-e1:s5 disk-e1:s6 disk-e1:s7 disk-e1:s8 disk-e1:s9 disk-e2:s0 disk-e2:s1 disk-e2:s10 disk-e2:s11 disk-e2:s2 disk-e2:s3 disk-e2:s4 disk-e2:s5 disk-e2:s6 disk-e2:s7 disk-e2:s8 disk-e2:s9 newdisk-e1:s17 newdisk-e1:s2 All the disks are here! Same for /dev/gptid/. Now importing the pool back like you suggested: # zpool import -d /dev/gpt pool: tank id: 13504509992978610301 state: UNAVAIL status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. see: http://www.sun.com/msg/ZFS-8000-5E config: tank UNAVAIL insufficient replicas raidz1 ONLINE gpt/disk-e1:s10 ONLINE mfid9p1 ONLINE mfid10p1 ONLINE mfid11p1 ONLINE It's missing a ton of drives. kern.geom.label.gptid.enable=0 makes no difference either And if I import it normally I get the same result as before. The pool is imported OK but with most of the disks referred to as mfidXXX instead of /dev/gpt/disk-XX and here's what I have left: # ls /dev/gpt disk-e1:s10 disk-e1:s20 disk-e2:s0 The problem I think comes down to what I have written in the zpool.cache file. It stores the mfid path instead of the gpt/disk one. children[0] type='disk' id=0 guid=1641394056824955485 * path='/dev/mfid33p1'* * phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0/sd@1,0:a'* whole_disk=0 * DTL=55* * * Compared to a disk from a partner server which is fine: children[0] type='disk' id=0 guid=5513814503830705577 path='/dev/gpt/disk-e1:s6' whole_disk=0 * * *I suspect OpenSolaris overwrote that part. So I wonder if there's way to actually* *edit the /boot/zfs/zpool.cache file and replace path with the corresponding /dev/gpt* *entry and remove the **phys_path **one. I don't know about DTL? Is there a way * to do this and how stupid that idea sounds to you? They should still point to the same data after all? * I cannot find a good zdb tutorial so this is what I've got for now: * # zdb tank version=14 name='tank' state=0 txg=206266 pool_guid=13504509992978610301 hostid=409325918 hostname='XXXX' vdev_tree type='root' id=0 guid=13504509992978610301 children[0] type='raidz' id=0 guid=3740854890192825394 nparity=1 metaslab_array=33 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=1641394056824955485 * path='/dev/mfid33p1'* * phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@1,0:a'* whole_disk=0 * DTL=55* children[1] type='disk' id=1 guid=6047192237176807561 path='/dev/mfid1p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@2,0:a' whole_disk=0 DTL=250 children[2] type='disk' id=2 guid=9178318500891071208 path='/dev/mfid2p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@3,0:a' whole_disk=0 DTL=249 children[3] type='disk' id=3 guid=2567999855746767831 path='/dev/mfid3p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@4,0:a' whole_disk=0 DTL=248 children[1] type='raidz' id=1 guid=17097047310177793733 nparity=1 metaslab_array=31 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=14513380297393196654 path='/dev/mfid4p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@5,0:a' whole_disk=0 DTL=266 children[1] type='disk' id=1 guid=7673391645329839273 path='/dev/mfid5p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@6,0:a' whole_disk=0 DTL=265 children[2] type='disk' id=2 guid=15189132305590412134 path='/dev/mfid6p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@7,0:a' whole_disk=0 DTL=264 children[3] type='disk' id=3 guid=17171875527714022076 path='/dev/mfid7p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@8,0:a' whole_disk=0 DTL=263 children[2] type='raidz' id=2 guid=4551002265962803186 nparity=1 metaslab_array=30 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=12104241519484712161 path='/dev/gpt/disk-e1:s10' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@9,0:a' whole_disk=0 DTL=262 children[1] type='disk' id=1 guid=3950210349623142325 path='/dev/mfid9p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@a,0:a' whole_disk=0 DTL=261 children[2] type='disk' id=2 guid=14559903955698640085 path='/dev/mfid10p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@b,0:a' whole_disk=0 DTL=260 children[3] type='disk' id=3 guid=12364155114844220066 path='/dev/mfid11p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@c,0:a' whole_disk=0 DTL=259 children[3] type='raidz' id=3 guid=12517231224568010294 nparity=1 metaslab_array=29 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=7655789038925330983 path='/dev/mfid12p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@d,0:a' whole_disk=0 DTL=258 children[1] type='disk' id=1 guid=17815755378968233141 path='/dev/mfid13p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@e,0:a' whole_disk=0 DTL=257 children[2] type='disk' id=2 guid=9590421681925673767 path='/dev/mfid14p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@f,0:a' whole_disk=0 DTL=256 children[3] type='disk' id=3 guid=13312724999073057440 path='/dev/mfid34p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@10,0:a' whole_disk=0 DTL=60 children[4] type='raidz' id=4 guid=7622366288306613136 nparity=1 metaslab_array=28 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=11283483106921343963 path='/dev/mfid15p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@11,0:a' whole_disk=0 DTL=254 children[1] type='disk' id=1 guid=14900597968455968576 path='/dev/mfid16p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@12,0:a' whole_disk=0 DTL=253 children[2] type='disk' id=2 guid=4140592611852504513 path='/dev/gpt/disk-e1:s20' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@13,0:a' whole_disk=0 DTL=252 children[3] type='disk' id=3 guid=2794215380207576975 path='/dev/mfid18p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@14,0:a' whole_disk=0 DTL=251 children[5] type='raidz' id=5 guid=17655293908271300889 nparity=1 metaslab_array=27 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=5274146379037055039 path='/dev/mfid19p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@15,0:a' whole_disk=0 DTL=278 children[1] type='disk' id=1 guid=8651755019404873686 path='/dev/mfid20p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@16,0:a' whole_disk=0 DTL=277 children[2] type='disk' id=2 guid=16827379661759988976 path='/dev/gpt/disk-e2:s0' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@17,0:a' whole_disk=0 DTL=276 children[3] type='disk' id=3 guid=2524967151333933972 path='/dev/mfid22p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@18,0:a' whole_disk=0 DTL=275 children[6] type='raidz' id=6 guid=2413519694016115220 nparity=1 metaslab_array=26 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=16361968944335143412 path='/dev/mfid23p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@19,0:a' whole_disk=0 DTL=274 children[1] type='disk' id=1 guid=10054650477559530937 path='/dev/mfid24p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@1a,0:a' whole_disk=0 DTL=273 children[2] type='disk' id=2 guid=17105959045159531558 path='/dev/mfid25p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@1b,0:a' whole_disk=0 DTL=272 children[3] type='disk' id=3 guid=17370453969371497663 path='/dev/mfid26p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@1c,0:a' whole_disk=0 DTL=271 children[7] type='raidz' id=7 guid=4614010953103453823 nparity=1 metaslab_array=24 metaslab_shift=36 ashift=9 asize=7995163410432 is_log=0 children[0] type='disk' id=0 guid=10090128057592036175 path='/dev/mfid27p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@1d,0:a' whole_disk=0 DTL=270 children[1] type='disk' id=1 guid=16676544025008223925 path='/dev/mfid28p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@1e,0:a' whole_disk=0 DTL=269 children[2] type='disk' id=2 guid=11777789246954957292 path='/dev/mfid29p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@1f,0:a' whole_disk=0 DTL=268 children[3] type='disk' id=3 guid=3406600121427522915 path='/dev/mfid30p1' phys_path='/pci@0,0/pci8086,3b42@1c/pci15d9,c480@0 /sd@20,0:a' whole_disk=0 DTL=267 Your help is highly appreciated. Thanks you very much, Rumen Telbizov On Fri, Oct 29, 2010 at 12:26 AM, Artem Belevich wrote: > On Thu, Oct 28, 2010 at 10:51 PM, Rumen Telbizov > wrote: > > Hi Artem, everyone, > > > > Thanks for your quick response. Unfortunately I already did try this > > approach. > > Applying -d /dev/gpt only limits the pool to the bare three remaining > disks > > which turns > > pool completely unusable (no mfid devices). Maybe those labels are > removed > > shortly > > they are being tried to be imported/accessed? > > In one of the previous emails you've clearly listed many devices in > /dev/gpt and said that they've disappeared after pool import. > Did you do "zpool import -d /dev/gpt" while /dev/gpt entries were present? > > > What I don't understand is what exactly makes those gpt labels disappear > > when the pool is imported and otherwise are just fine?! > > This is the way GEOM works. If something (ZFS in this case) uses raw > device, derived GEOM entities disappear. > > Try exporting the pool. Your /dev/gpt entries should be back. Now try > to import with -d option and see if it works. > > You may try bringing the labels back the hard way by detaching raw > drive and then re-attaching it via the label, but resilvering one > drive at a time will take a while. > > --Artem > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 19:51:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8F85106564A for ; Fri, 29 Oct 2010 19:51:43 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB908FC1B for ; Fri, 29 Oct 2010 19:51:43 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WutnOlaG4zustr2613+Km4jTYY7RS0fwvggeJVpMkSHZ7WDw1xnHTs3KCgYsGqLN; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PBuzG-0005LE-8z; Fri, 29 Oct 2010 15:51:42 -0400 Message-ID: <4CCB25CC.9050405@earthlink.net> Date: Fri, 29 Oct 2010 15:51:40 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4CCAE59E.5020006@earthlink.net> <20101029165405.GA82279@icarus.home.lan> <4CCB007D.8080204@earthlink.net> <20101029174014.GA82936@icarus.home.lan> In-Reply-To: <20101029174014.GA82936@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79dfdc2da1f2ccec377d625a15f5ba2830350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: FreeBSD Stable Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 19:51:43 -0000 On 10/29/2010 01:40 PM, Jeremy Chadwick wrote: > On Fri, Oct 29, 2010 at 01:12:29PM -0400, Stephen Clark wrote: > >> On 10/29/2010 12:54 PM, Jeremy Chadwick wrote: >> >>> On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote: >>> >>>> I am having a problem getting 6.3 to boot on an intel atom mb. When >>>> it gets to where it should identify the drive it hangs. >>>> >>> Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead? I mean, you >>> *are* using an Intel Atom system, which contains significantly more >>> advanced hardware than was available during the RELENG_6 days. >>> >>> Oh, I think you answer this further down... >>> >>> >>>> If I boot with no acpi it does the same thing. >>>> >>>> If I boot with safe mode it comes up and identifies the drive but then >>>> starts spewing the following errors: >>>> ipfw2 initialized, divert enabled, rule-based forwarding disabled, >>>> default to ad >>>> interrupt storm detected on "irq15:"; throttling interrupt source >>>> ad4: 152627MB at ata2-master PIO4 >>>> interrupt storm detected on "irq15:"; throttling interrupt source >>>> interrupt storm detected on "irq15:"; throttling interrupt source >>>> interrupt storm detected on "irq15:"; throttling interrupt source >>>> >>>> FreeBSD runs but I continue to get these errors: >>>> >>>> What exactly does safe mode do - I am afraid my forth skills are not >>>> what they should be. >>>> >>> "Safe mode" does the following before doing "boot": >>> >>> set hw.ata.ata_dma=0 >>> set hw.ata.atapi_dma=0 >>> set hw.ata.wc=0 >>> set hw.eisa_slots=0 >>> set hint.kbdmux.0.disabled=1 >>> >>> It also does the following if you're booting/running i386: >>> >>> unset acpi_load >>> set hint.acpi.0.disabled=1 >>> set loader.acpi_disabled_by_user=1 >>> set hint.apic.0.disabled=1 >>> >>> The code is in /boot/beastie.4th. >>> >>> IMHO, you shouldn't be disabling ACPI, or using "safe mode" to try and >>> get your system working. Can you please boot Verbose mode instead and >>> provide all of the output somewhere? You'll probably need serial >>> console for this, since the system hangs. >>> >>> >>> >>>> atapci0@pci0:0:31:1: class=0x01018a card=0x28508086 >>>> chip=0x28508086 rev=0x03 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801H (ICH8 Family) Ultra ATA Storage Controllers' >>>> class = mass storage >>>> subclass = ATA >>>> atapci1@pci0:0:31:2: class=0x01018f card=0x28288086 >>>> chip=0x28288086 rev=0x03 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = 'ICH8M (ICH8 Family) 3 port SATA Controller' >>>> class = mass storage >>>> subclass = ATA >>>> >>> Your storage controller is an Intel ICH8, which is supported by FreeBSD, >>> but the ATA layer differs greatly between 6.x and 8.x (read: better on >>> 8.x). AHCI is also well-supported on 8.x if your system/BIOS supports >>> it. >>> >>> >>>> I am stuck for now on 6.3 so moving to a later release 7+ is not feasible. >>>> >>> Can you explain why? (If I don't ask it, someone else will.) This will >>> almost certainly be the key to this discussion, especially since you >>> say: >>> >>> >> I am supporting over 700 units in the field that are acting as >> firewall/router/vpn devices, >> that are running 6.3. It would not be feasible to upgrade them to a >> new version of FreeBSD >> remotely. Also if I was going to move to a later release of FreeBSD >> for the new hardware >> it would involve months of new testing and validation of the new >> release, where putting a patched >> 6.3 kernel is relatively straightforward. >> > I'm a little confused. Did you deploy over 700 field units running > FreeBSD 6.3 without testing it first on this particular piece of > hardware/setup? Or did you recently upgrade from FreeBSD X.Y to 6.3 and > found that things broke? What I'm trying to find out is whether or not > these systems ever worked for you, and if so, at what point did they > stop working. Sorry for the confusion. We have a mix of hardware in the field. The current hardware platform we are shipping is going EOL from the vendor. I am testing the vendors next generation of hardware. I included at the end a verbose startup using the 6.3 install disc. > Possibly we can work backwards to figure out what code > change/commit broke things for you. Keep reading for some ideas. > > First question: are you using any parameters in /boot/loader.conf or > /boot.config? If so, what are they? > > Second question: can you provide your kernel configuration file? > > As for the verbose boot -- thanks much. Appropriate folks should be > here on the list, so if they have ideas they'll probably reply. A quick > analysis indicates the following: > > ata0 --> atapci0 --> Intel ATA controller master, IDE/PATA, IRQ 14 > ata1 --> atapci0 --> Intel ATA controller slave, IDE/PATA, IRQ 14 > ata2 --> atapci1 --> Intel ATA controller master, IDE/PATA, IRQ 15 > ata3 --> atapci1 --> Intel ATA controller slave, IDE/PATA, IRQ 15 > > A single device is found on ata2, but no other devices are found on the > other ATA busses: > > >> ata2: reset tp2 stat0=50 stat1=00 devices=0x1 >> > That probably correlates with what you see when you boot "safe mode", > since there we see this message: > > ad4: 152627MB at ata2-master PIO4 > > However, there's other messages which are a serious concern, given their > association with the ATA controller in question: > > interrupt storm detected on "irq15:"; throttling interrupt source > interrupt storm detected on "irq15:"; throttling interrupt source > interrupt storm detected on "irq15:"; throttling interrupt source > interrupt storm detected on "irq15:"; throttling interrupt source > > You might try escaping to the loader prompt (I forget what menu item it > is on 6.x, might be item 6) and entering the following commands. These > are the 3 things I'd try first, and in this order: > > 1) set hint.apic.0.disabled=1 > boot > > 2) set hw.ata.ata_dma=0 > boot > > 3) set hint.apic.0.disabled=1 > set hw.ata.ata_dma=0 > set hint.kbdmux.0.disabled=1 > boot > > If any of these work (I'm hoping #1 or #2 suffices), you can add the > appropriate lines to your /boot/loader.conf without the "set" portion > and they should be retained going forward. > > Unfortunately none of the above worked. Here is a verbose startup from the generic kernel on the 6.3 install disk. Note: when I used the safe for the install it actually went into the install program and didn't hang - though I did see the interrupt storm message right before sysinstall ran. m��^:FZ�2+/#";wJ/+*+"�:*;+&o""""B"B""""B"~"""B"B"""B"�"B"B""6"B"B"*""B"B" 0 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000003f9a0000 SMAP type=03 base=000000003faa0000 len=000000000000e000 SMAP type=04 base=000000003faae000 len=0000000000032000 SMAP type=02 base=000000003fae0000 len=0000000000010000 SMAP type=02 base=000000003faf0000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffb00000 len=0000000000500000 Copyright (c) 1992-2008 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 6.3-RELEASE #0: Wed Jan 16 04:18:52 UTC 2008 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc1037000. Preloaded mfs_root "/boot/mfsroot" at 0xc10371ac. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc10371f0. MP Configuration Table version 1.4 found at 0xc00fdc90 Table 'FACP' at 0x3faa0290 Table 'APIC' at 0x3faa0390 MADT: Found table at 0x3faa0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled MADT: Found CPU APIC ID 2 ACPI ID 2: enabled MADT: Found CPU APIC ID 1 ACPI ID 3: enabled MADT: Found CPU APIC ID 3 ACPI ID 4: enabled ACPI APIC Table: <080610 APIC1657> Calibrating clock(s) ... i8254 clock: 1188490 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1673327070 Hz CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1673.33-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106ca Stepping = 10 Features=0xbfebfbff Features2=0x40e31d> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Logical CPUs per core: 2 real memory = 1068105728 (1018 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001425000 - 0x000000003e86ffff, 1027911680 bytes (250955 pages) avail memory = 1027821568 (980 MB) bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f6100 pnpbios: Entry = f0000:78ba Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 4 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) npx0: INT 16 interface acpi0: <080610 XSDT1657> on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=a0008086) pcibios: BIOS version 3.00 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xd9248000 pa 0x9d000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.FHR0 -> bus 0 dev 31 func 0 acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 cpu0: on acpi0 cpu0: switching to generic Cx mode pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0xa000, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0xa001, revid=0x02 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base fe980000, size 19, enabled map[14]: type 4, range 32, base 0000cc00, size 3, enabled map[18]: type 3, range 32, base d0000000, size 28, enabled map[1c]: type 1, range 32, base fe800000, size 20, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa002, revid=0x02 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fe780000, size 19, enabled found-> vendor=0x8086, dev=0x2834, revid=0x03 bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type 4, range 32, base 0000c880, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2835, revid=0x03 bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 0000c800, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x03 bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fe977c00, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x283f, revid=0x03 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2845, revid=0x03 bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2830, revid=0x03 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type 4, range 32, base 0000c480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2831, revid=0x03 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 0000c400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2832, revid=0x03 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type 4, range 32, base 0000c080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2836, revid=0x03 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fe977800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xf3 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x03 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2850, revid=0x03 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x2828, revid=0x03 bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 powerspec 3 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000c000, size 3, enabled map[14]: type 4, range 32, base 0000bc00, size 2, enabled map[18]: type 4, range 32, base 0000b880, size 3, enabled map[1c]: type 4, range 32, base 0000b800, size 2, enabled map[20]: type 4, range 32, base 0000b480, size 4, enabled map[24]: type 4, range 32, base 0000b400, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 18 found-> vendor=0x8086, dev=0x283e, revid=0x03 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type 1, range 32, base fe977400, size 8, enabled map[20]: type 4, range 32, base 00000400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 17 pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) uhci0: port 0xc880-0xc89f irq 16 at device 26.00 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc880 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f irq 21 at device 26.10 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfe977c00-0xfe977fff irq 18 at 0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe977c00 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib1: irq 22 at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: memory decode 0x0-0x0 pcib1: prefetched decode 0x0-0x0 pci1: on pcib1 pci1: physical bus=1 pcib2: irq 21 at device 28.3 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: prefetched decode 0xfdf00000-0xfdffffff pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x03 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type 4, range 32, base 0000d800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type 3, range 64, base fdfff000, size 12, enabled pcib2: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type 3, range 64, base fdff8000, size 14, enabled pcib2: requested memory range 0xfdff8000-0xfdffbfff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd800 pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pci2: at device 0.0 (no driver attached) uhci2: port 0xc480-0xc49f irq 23 at device 29.00 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc480 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 uhci2: [GIANT-LOCKED] usb3: on uhci2 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xc400-0xc41f irq 19 at device 29.10 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc400 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 uhci3: [GIANT-LOCKED] usb4: on uhci3 usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xc080-0xc09f irq 18 at device 29.20 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc080 uhci4: [GIANT-LOCKED] usb5: on uhci4 usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfe977800-0xfe977bff irq 23 at 0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe977800 ehci1: [GIANT-LOCKED] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub6: 6 ports with 6 removable, self powered umass0: vendor 0x059b USB 2.0 Storage Device, rev 2.00/1.03, addr 2 umass0:0:0:-1: Attached to scbus0 pcib3: at device 30.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfeb00000-0xfebfffff pcib3: prefetched decode 0xfff00000-0xfffff pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=3, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=15 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e800, size 8, enabled pcib3: requested I/O range 0xe800-0xe8ff: in range map[14]: type 1, range 32, base febffc00, size 8, enabled pcib3: requested memory range 0xfebffc00-0xfebffcff: good pcib3: matched entry for 3.4.INTA pcib3: slot 4 INTA hardwired to IRQ 18 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=3, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 8, enabled pcib3: requested I/O range 0xe400-0xe4ff: in range map[14]: type 1, range 32, base febff800, size 8, enabled pcib3: requested memory range 0xfebff800-0xfebff8ff: good pcib3: matched entry for 3.6.INTA pcib3: slot 6 INTA hardwired to IRQ 19 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=3, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled pcib3: requested I/O range 0xe000-0xe0ff: in range map[14]: type 1, range 32, base febff400, size 8, enabled pcib3: requested memory range 0xfebff400-0xfebff4ff: good pcib3: matched entry for 3.7.INTA pcib3: slot 7 INTA hardwired to IRQ 16 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe800 pcib3: rl0 requested I/O range 0xe800-0xe8ff: in range pcib3: rl0 requested I/O range 0xe800-0xe8ff: in range rl0: port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff i3 pcib3: rl0 requested I/O range 0xe800-0xe8ff: in range miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:30:18:a1:7f:e9 rl0: [MPSAFE] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 pcib3: rl1 requested I/O range 0xe400-0xe4ff: in range pcib3: rl1 requested I/O range 0xe400-0xe4ff: in range rl1: port 0xe400-0xe4ff mem 0xfebff800-0xfebff8ff i3 pcib3: rl1 requested I/O range 0xe400-0xe4ff: in range miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: bpf attached rl1: Ethernet address: 00:30:18:a1:7f:ea rl1: [MPSAFE] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe000 pcib3: rl2 requested I/O range 0xe000-0xe0ff: in range pcib3: rl2 requested I/O range 0xe000-0xe0ff: in range rl2: port 0xe000-0xe0ff mem 0xfebff400-0xfebff4ff i3 pcib3: rl2 requested I/O range 0xe000-0xe0ff: in range miibus2: on rl2 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl2: bpf attached rl2: Ethernet address: 00:30:18:a1:7f:eb rl2: [MPSAFE] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa00 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat0=0x74 err=0x74 lsb=0x74 msb=0x74 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: reset tp2 stat0=00 stat1=87 devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] atapci1: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480 atapci1: [MPSAFE] ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: Changing trigger for pin 4 to level ioapic0: Changing polarity for pin 4 to low ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x83ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 83666365 hz Timecounter "TSC" frequency 1673327070 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. hptrr: no controller detected. m -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 20:11:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F02AA10656A5; Fri, 29 Oct 2010 20:11:13 +0000 (UTC) (envelope-from nwf@cs.jhu.edu) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) by mx1.freebsd.org (Postfix) with ESMTP id C3BDC8FC14; Fri, 29 Oct 2010 20:11:12 +0000 (UTC) Received: from gradx.cs.jhu.edu (gradx.cs.jhu.edu [128.220.13.52]) by blaze.cs.jhu.edu (8.14.3/8.14.3) with ESMTP id o9TJcoYP029212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Oct 2010 15:38:51 -0400 (EDT) Received: from gradx.cs.jhu.edu (localhost [127.0.0.1]) by gradx.cs.jhu.edu (8.14.3/8.13.1) with ESMTP id o9TJcoCB030983; Fri, 29 Oct 2010 15:38:50 -0400 Received: (from nwf@localhost) by gradx.cs.jhu.edu (8.14.3/8.13.8/Submit) id o9TJcok3030981; Fri, 29 Oct 2010 15:38:50 -0400 Date: Fri, 29 Oct 2010 15:38:50 -0400 From: Nathaniel W Filardo To: freebsd-sparc64@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20101029193850.GH11447@gradx.cs.jhu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ewQ5hdP4CtoTt3oD" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) Cc: Subject: Cross-build failure on sparc64 for TARGET=amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 20:11:14 -0000 --ewQ5hdP4CtoTt3oD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Running > sudo make TARGET_ARCH=3Damd64 TARGET=3Damd64 DESTDIR=3D/usr/x86_64 -j4 bu= ildworld=20 on > FreeBSD sparcslave.priv.oc.ietfng.org 8.1-STABLE FreeBSD 8.1-STABLE #2 r2= 14092=3D9050e7b-dirty: Thu Oct 21 01:25:54 UTC 2010 root@t@sparcslave.priv.= oc.ietfng.org:/usr/obj/usr/src/sys/SLAVKERN sparc64 with /usr/src at e32025d from git://gitorious.org/freebsd/freebsd.git (svn http://svn.freebsd.org/base/stable/8@214488) fails with > cc -O2 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=3D\"/usr/obj/amd64/usr/src= /tmp/usr\" -DCROSS_COMPILE -I/usr/obj/amd64/usr/src/tmp/usr /src/gnu/usr.bi= n/cc/cc/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc/../cc_tools -I/usr/src/gnu= /usr.bin/cc/cc/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc/../../.= =2E/../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/= gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcclibs/li= bcpp/include -I/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcclibs/libde= cnumber -DGCC_DRIVER -DDEFAULT_TARGET_VERSION=3D\"4.2.1\" -DDEFAULT_TARGET= _MACHINE=3D\"amd64-undermydesk-freebsd\" -DENABLE_SHARED_LIBGCC -I/usr/ob= j/amd64/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/cc/../../= =2E./../contrib/gcc/gccspec.c > /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i38= 6.c: In function 'host_detect_local_cpu': > /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i38= 6.c:96: error: impossible constraint in 'asm' > /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i38= 6.c:103: error: impossible constraint in 'asm' > /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i38= 6.c:113: error: impossible constraint in 'asm' > /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i38= 6.c:117: error: impossible constraint in 'asm' > {standard input}: Assembler messages: > {standard input}:92: Error: Unknown opcode: `pushfl' > {standard input}:92: Error: Unknown opcode: `pushfl' > {standard input}:92: Error: Unknown opcode: `popl' > {standard input}:92: Error: Illegal operands > {standard input}:92: Error: Unknown opcode: `xorl' > {standard input}:92: Error: Unknown opcode: `pushl' > {standard input}:92: Error: Unknown opcode: `popfl' > {standard input}:92: Error: Unknown opcode: `pushfl' > {standard input}:92: Error: Unknown opcode: `popl' > {standard input}:92: Error: Unknown opcode: `popfl' > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error which looks like it's trying to build some x86 code with the host toolchain, not the cross tools. Help? :) Thanks. --nwf; --ewQ5hdP4CtoTt3oD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzLIsoACgkQTeQabvr9Tc+JRACff4Jnb7f1x2Zh3tTOkl6Pl/Iy 8tgAniPynHGvIgTkkeTtAtWZn3BKq4j3 =Zkxa -----END PGP SIGNATURE----- --ewQ5hdP4CtoTt3oD-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 20:21:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 509A7106566C for ; Fri, 29 Oct 2010 20:21:37 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by mx1.freebsd.org (Postfix) with ESMTP id 12E708FC19 for ; Fri, 29 Oct 2010 20:21:36 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rlp4R50Zx4bVP6IamYupekJWzawSB5RDY7F9QWQNKL6xWEV593dG+OiKriuuJmlG; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PBvRS-000845-Rv; Fri, 29 Oct 2010 16:20:51 -0400 Message-ID: <4CCB2C88.9050208@earthlink.net> Date: Fri, 29 Oct 2010 16:20:24 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: sclark46@earthlink.net References: <4CCAE59E.5020006@earthlink.net> <20101029165405.GA82279@icarus.home.lan> <4CCB007D.8080204@earthlink.net> <20101029174014.GA82936@icarus.home.lan> <4CCB25CC.9050405@earthlink.net> In-Reply-To: <4CCB25CC.9050405@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec7935beb0da83ee8210976ad22cc36d5c45350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: FreeBSD Stable , Jeremy Chadwick Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 20:21:37 -0000 On 10/29/2010 03:51 PM, Stephen Clark wrote: > On 10/29/2010 01:40 PM, Jeremy Chadwick wrote: >> On Fri, Oct 29, 2010 at 01:12:29PM -0400, Stephen Clark wrote: >>> On 10/29/2010 12:54 PM, Jeremy Chadwick wrote: >>>> On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote: >>>>> I am having a problem getting 6.3 to boot on an intel atom mb. When >>>>> it gets to where it should identify the drive it hangs. >>>> Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead? I mean, >>>> you >>>> *are* using an Intel Atom system, which contains significantly more >>>> advanced hardware than was available during the RELENG_6 days. >>>> >>>> Oh, I think you answer this further down... >>>> >>>>> If I boot with no acpi it does the same thing. >>>>> >>>>> If I boot with safe mode it comes up and identifies the drive but >>>>> then >>>>> starts spewing the following errors: >>>>> ipfw2 initialized, divert enabled, rule-based forwarding disabled, >>>>> default to ad >>>>> interrupt storm detected on "irq15:"; throttling interrupt source >>>>> ad4: 152627MB at ata2-master PIO4 >>>>> interrupt storm detected on "irq15:"; throttling interrupt source >>>>> interrupt storm detected on "irq15:"; throttling interrupt source >>>>> interrupt storm detected on "irq15:"; throttling interrupt source >>>>> >>>>> FreeBSD runs but I continue to get these errors: >>>>> >>>>> What exactly does safe mode do - I am afraid my forth skills are not >>>>> what they should be. >>>> "Safe mode" does the following before doing "boot": >>>> >>>> set hw.ata.ata_dma=0 >>>> set hw.ata.atapi_dma=0 >>>> set hw.ata.wc=0 >>>> set hw.eisa_slots=0 >>>> set hint.kbdmux.0.disabled=1 >>>> >>>> It also does the following if you're booting/running i386: >>>> >>>> unset acpi_load >>>> set hint.acpi.0.disabled=1 >>>> set loader.acpi_disabled_by_user=1 >>>> set hint.apic.0.disabled=1 >>>> >>>> The code is in /boot/beastie.4th. >>>> >>>> IMHO, you shouldn't be disabling ACPI, or using "safe mode" to try and >>>> get your system working. Can you please boot Verbose mode instead and >>>> provide all of the output somewhere? You'll probably need serial >>>> console for this, since the system hangs. >>>> >>>> >>>>> atapci0@pci0:0:31:1: class=0x01018a card=0x28508086 >>>>> chip=0x28508086 rev=0x03 hdr=0x00 >>>>> vendor = 'Intel Corporation' >>>>> device = '82801H (ICH8 Family) Ultra ATA Storage >>>>> Controllers' >>>>> class = mass storage >>>>> subclass = ATA >>>>> atapci1@pci0:0:31:2: class=0x01018f card=0x28288086 >>>>> chip=0x28288086 rev=0x03 hdr=0x00 >>>>> vendor = 'Intel Corporation' >>>>> device = 'ICH8M (ICH8 Family) 3 port SATA Controller' >>>>> class = mass storage >>>>> subclass = ATA >>>> Your storage controller is an Intel ICH8, which is supported by >>>> FreeBSD, >>>> but the ATA layer differs greatly between 6.x and 8.x (read: better on >>>> 8.x). AHCI is also well-supported on 8.x if your system/BIOS supports >>>> it. >>>> >>>>> I am stuck for now on 6.3 so moving to a later release 7+ is not >>>>> feasible. >>>> Can you explain why? (If I don't ask it, someone else will.) This >>>> will >>>> almost certainly be the key to this discussion, especially since you >>>> say: >>>> >>> I am supporting over 700 units in the field that are acting as >>> firewall/router/vpn devices, >>> that are running 6.3. It would not be feasible to upgrade them to a >>> new version of FreeBSD >>> remotely. Also if I was going to move to a later release of FreeBSD >>> for the new hardware >>> it would involve months of new testing and validation of the new >>> release, where putting a patched >>> 6.3 kernel is relatively straightforward. >> I'm a little confused. Did you deploy over 700 field units running >> FreeBSD 6.3 without testing it first on this particular piece of >> hardware/setup? Or did you recently upgrade from FreeBSD X.Y to 6.3 and >> found that things broke? What I'm trying to find out is whether or not >> these systems ever worked for you, and if so, at what point did they >> stop working. > Sorry for the confusion. We have a mix of hardware in the field. The > current > hardware platform we are shipping is going EOL from the vendor. I am > testing > the vendors next generation of hardware. > > I included at the end a verbose startup using the 6.3 install disc. > >> Possibly we can work backwards to figure out what code >> change/commit broke things for you. Keep reading for some ideas. >> >> First question: are you using any parameters in /boot/loader.conf or >> /boot.config? If so, what are they? >> Second question: can you provide your kernel configuration file? >> >> As for the verbose boot -- thanks much. Appropriate folks should be >> here on the list, so if they have ideas they'll probably reply. A quick >> analysis indicates the following: >> >> ata0 --> atapci0 --> Intel ATA controller master, IDE/PATA, IRQ 14 >> ata1 --> atapci0 --> Intel ATA controller slave, IDE/PATA, IRQ 14 >> ata2 --> atapci1 --> Intel ATA controller master, IDE/PATA, IRQ 15 >> ata3 --> atapci1 --> Intel ATA controller slave, IDE/PATA, IRQ 15 >> >> A single device is found on ata2, but no other devices are found on the >> other ATA busses: >> >>> ata2: reset tp2 stat0=50 stat1=00 devices=0x1 >> That probably correlates with what you see when you boot "safe mode", >> since there we see this message: >> >> ad4: 152627MB at ata2-master PIO4 >> >> However, there's other messages which are a serious concern, given their >> association with the ATA controller in question: >> >> interrupt storm detected on "irq15:"; throttling interrupt source >> interrupt storm detected on "irq15:"; throttling interrupt source >> interrupt storm detected on "irq15:"; throttling interrupt source >> interrupt storm detected on "irq15:"; throttling interrupt source >> >> You might try escaping to the loader prompt (I forget what menu item it >> is on 6.x, might be item 6) and entering the following commands. These >> are the 3 things I'd try first, and in this order: >> >> 1) set hint.apic.0.disabled=1 >> boot >> >> 2) set hw.ata.ata_dma=0 >> boot >> >> 3) set hint.apic.0.disabled=1 >> set hw.ata.ata_dma=0 >> set hint.kbdmux.0.disabled=1 >> boot >> >> If any of these work (I'm hoping #1 or #2 suffices), you can add the >> appropriate lines to your /boot/loader.conf without the "set" portion >> and they should be retained going forward. >> > Unfortunately none of the above worked. Here is a verbose startup from > the > generic kernel on the 6.3 install disk. Note: when I used the safe for > the install > it actually went into the install program and didn't hang - though I > did see the > interrupt storm message right before sysinstall ran. > > > m��^:FZ�2+/#";wJ/+*+"�:*;+&o""""B"B""""B"~"""B"B"""B"�"B"B""6"B"B"*""B"B" > 0 > SMAP type=02 base=000000000009fc00 len=0000000000000400 > SMAP type=02 base=00000000000e0000 len=0000000000020000 > SMAP type=01 base=0000000000100000 len=000000003f9a0000 > SMAP type=03 base=000000003faa0000 len=000000000000e000 > SMAP type=04 base=000000003faae000 len=0000000000032000 > SMAP type=02 base=000000003fae0000 len=0000000000010000 > SMAP type=02 base=000000003faf0000 len=0000000000010000 > SMAP type=02 base=00000000fee00000 len=0000000000001000 > SMAP type=02 base=00000000ffb00000 len=0000000000500000 > Copyright (c) 1992-2008 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 6.3-RELEASE #0: Wed Jan 16 04:18:52 UTC 2008 > root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Preloaded elf kernel "/boot/kernel/kernel" at 0xc1037000. > Preloaded mfs_root "/boot/mfsroot" at 0xc10371ac. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc10371f0. > MP Configuration Table version 1.4 found at 0xc00fdc90 > Table 'FACP' at 0x3faa0290 > Table 'APIC' at 0x3faa0390 > MADT: Found table at 0x3faa0390 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > MADT: Found CPU APIC ID 2 ACPI ID 2: enabled > MADT: Found CPU APIC ID 1 ACPI ID 3: enabled > MADT: Found CPU APIC ID 3 ACPI ID 4: enabled > ACPI APIC Table: <080610 APIC1657> > Calibrating clock(s) ... i8254 clock: 1188490 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 1673327070 Hz > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1673.33-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x106ca Stepping = 10 > > Features=0xbfebfbff > > > Features2=0x40e31d> > AMD Features=0x20100000 > AMD Features2=0x1 > Cores per package: 2 > Logical CPUs per core: 2 > real memory = 1068105728 (1018 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000001425000 - 0x000000003e86ffff, 1027911680 bytes (250955 pages) > avail memory = 1027821568 (980 MB) > bios32: Found BIOS32 Service Directory header at 0xc00f0000 > bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0x31 > pnpbios: Found PnP BIOS data at 0xc00f6100 > pnpbios: Entry = f0000:78ba Rev = 1.0 > Other BIOS signatures found: > APIC: CPU 0 has ACPI ID 1 > MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 4 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 > wlan: <802.11 Link Layer> > ath_rate: version 1.2 > null: > random: > nfslock: pseudo-device > io: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) > hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) > big snip > lo0: bpf attached > rr232x: no controller detected. > hptrr: no controller detected. > m > Why does FreeBSD think I have a rocket raid controller? This the generic kernel. Is there some way disable this from loading? When I boot the 7.2 install disk it doesn't say anything about finding hptrr: -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 20:36:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A879C106564A for ; Fri, 29 Oct 2010 20:36:30 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 64CFC8FC16 for ; Fri, 29 Oct 2010 20:36:30 +0000 (UTC) Received: by iwn39 with SMTP id 39so4050478iwn.13 for ; Fri, 29 Oct 2010 13:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2vef156h3a6p4GGmcVzBkbl/gUxBKW+PvVvXxgjeOnc=; b=TgYAinUZ3Hy949RL0hjXqUw91V8HfIRDVgZ12WuwTQoXrfqaW3zP3+uLMGmJQKLAZ1 AdSs5PO0GPtNK1ZYFqpxa0drnjQr+xXt8TjEICQn/j+Bjq90usFz0SIq+iZHHTtOfE/j aEhCy6mL+KutjYRt2ufWA4i7cNpG6ivWuYrG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qF8/9V2G4MraMWyzrl3ralCRX4y7FFyUWHf6cCGqqaD470x2howpvAKXx0SADRPMrI ED432cKCtH7pdHTyS1NYGBmoCyi8CivOAu6KtvfIDUDK6mgeRKAIRg1ojc8FcqUaPBQI 25kF1RsHooHdI2RBp5BE5qefU1XSp6TF6I4Ic= MIME-Version: 1.0 Received: by 10.42.228.8 with SMTP id jc8mr4364449icb.86.1288384589782; Fri, 29 Oct 2010 13:36:29 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.180.2 with HTTP; Fri, 29 Oct 2010 13:36:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 13:36:29 -0700 X-Google-Sender-Auth: fGsagLzbPZtIbgsvghtjpWsIH3c Message-ID: From: Artem Belevich To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 20:36:30 -0000 On Fri, Oct 29, 2010 at 11:34 AM, Rumen Telbizov wrote= : > The problem I think comes down to what I have written in the zpool.cache > file. > It stores the mfid path instead of the gpt/disk one. > =A0=A0 =A0 =A0children[0] > =A0=A0 =A0 =A0 =A0 =A0 =A0 type=3D'disk' > =A0=A0 =A0 =A0 =A0 =A0 =A0 id=3D0 > =A0=A0 =A0 =A0 =A0 =A0 =A0 guid=3D1641394056824955485 > =A0=A0 =A0 =A0 =A0 =A0 =A0 path=3D'/dev/mfid33p1' > =A0=A0 =A0 =A0 =A0 =A0 =A0 phys_path=3D'/pci@0,0/pci8086,3b42@1c/pci15d9,= c480@0/sd@1,0:a' > =A0=A0 =A0 =A0 =A0 =A0 =A0 whole_disk=3D0 > =A0=A0 =A0 =A0 =A0 =A0 =A0 DTL=3D55 Yes, phys_path does look like something that came from solaris. > Compared to a disk from a partner server which is fine: > =A0=A0 =A0 =A0children[0] > =A0=A0 =A0 =A0 =A0 =A0 =A0 type=3D'disk' > =A0=A0 =A0 =A0 =A0 =A0 =A0 id=3D0 > =A0=A0 =A0 =A0 =A0 =A0 =A0 guid=3D5513814503830705577 > =A0=A0 =A0 =A0 =A0 =A0 =A0 path=3D'/dev/gpt/disk-e1:s6' > =A0=A0 =A0 =A0 =A0 =A0 =A0 whole_disk=3D0 If you have old copy of /boot/zfs/zpool.cache you could try use "zpool import -c old-cache-file". I don't think zpool.cache is needed for import. Import should work without it just fine. Just remove /boot/zfs/zpool.cache (or move it somewhere else and then try importing with -d /dev/gpt again. --Artem From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 21:19:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 877DC1065670 for ; Fri, 29 Oct 2010 21:19:06 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35C968FC0A for ; Fri, 29 Oct 2010 21:19:05 +0000 (UTC) Received: by qyk2 with SMTP id 2so2469512qyk.13 for ; Fri, 29 Oct 2010 14:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mAh5UqY9H2tLWcIqmZXWlT3J3KeLPkro22E65LnhqTI=; b=JaT8nbrt4DteWzO+3TLp+hWGk/edqxVKltrh0ylas4BoQmIVj3ajSrEV6fJqmBUrQi APitAXAR+buv8tjLJg/MXb8ANZVQC+p3NWgSBrQPYP65XuP2psxQZbVFqKimtDEs4P7M 6URs/g9ZGWmv6YTO556VvHgJi8vfHJYvgqzqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FDmKG1N4yLx6fKkt+9jO5UPlqiTvKN/bME5y9YgjXHCbv836RsaGVwaJgZIJPeuApE VO71zbx2hwHP+grMC+/lgjqdV27JiTgpP2k2u6xuQ7TAdTu96q7drGi/+KM/K8qjekG+ iENbsjroOTD155WFGv7J6Xw905XP2Ab4Rf9LA= MIME-Version: 1.0 Received: by 10.224.29.3 with SMTP id o3mr601837qac.334.1288387145383; Fri, 29 Oct 2010 14:19:05 -0700 (PDT) Received: by 10.229.110.12 with HTTP; Fri, 29 Oct 2010 14:19:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 14:19:05 -0700 Message-ID: From: Rumen Telbizov To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 21:19:06 -0000 Artem, > If you have old copy of /boot/zfs/zpool.cache you could try use "zpool > import -c old-cache-file". > Unfortunately I don't :( I'll make a habit of creating a copy from now on! > > I don't think zpool.cache is needed for import. Import should work > without it just fine. Just remove /boot/zfs/zpool.cache (or move it > somewhere else and then try importing with -d /dev/gpt again. > You're right. zpool export tank seems to remove the cache file so import has nothing to consult so doesn't make any difference. I guess my only chance at this point would be to somehow manually edit the zpool configuration, via the zpool.cache file or not, and substitute mfid with gpt/disk?! Is there a way to do this? Thanks, -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 21:21:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 879CE10656B4 for ; Fri, 29 Oct 2010 21:21:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 488548FC17 for ; Fri, 29 Oct 2010 21:21:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D447B46B17; Fri, 29 Oct 2010 17:21:06 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BB90C8A009; Fri, 29 Oct 2010 17:21:05 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, sclark46@earthlink.net Date: Fri, 29 Oct 2010 17:20:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CCAE59E.5020006@earthlink.net> <4CCB25CC.9050405@earthlink.net> <4CCB2C88.9050208@earthlink.net> In-Reply-To: <4CCB2C88.9050208@earthlink.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010291720.11771.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 29 Oct 2010 17:21:05 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Jeremy Chadwick Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 21:21:07 -0000 On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote: > > rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) > > hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) > > > big snip > > lo0: bpf attached > > rr232x: no controller detected. > > hptrr: no controller detected. > > m > > > Why does FreeBSD think I have a rocket raid controller? This the generic > kernel. > Is there some way disable this from loading? The hptrr driver is in GENERIC in 6.x and it always prints out the first message. You can ignore it. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 21:21:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1727410656B8; Fri, 29 Oct 2010 21:21:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DCE568FC18; Fri, 29 Oct 2010 21:21:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 91FA246B0C; Fri, 29 Oct 2010 17:21:07 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CBB738A01D; Fri, 29 Oct 2010 17:21:06 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 29 Oct 2010 17:21:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101029193850.GH11447@gradx.cs.jhu.edu> In-Reply-To: <20101029193850.GH11447@gradx.cs.jhu.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010291721.05089.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 29 Oct 2010 17:21:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Nathaniel W Filardo , freebsd-sparc64@freebsd.org Subject: Re: Cross-build failure on sparc64 for TARGET=amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 21:21:08 -0000 On Friday, October 29, 2010 3:38:50 pm Nathaniel W Filardo wrote: > Running > > sudo make TARGET_ARCH=amd64 TARGET=amd64 DESTDIR=/usr/x86_64 -j4 buildworld Maybe just set TARGET and not TARGET_ARCH? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 21:24:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 344841065694 for ; Fri, 29 Oct 2010 21:24:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 052418FC1E for ; Fri, 29 Oct 2010 21:24:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8DB8D46B0C; Fri, 29 Oct 2010 17:24:17 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 923038A009; Fri, 29 Oct 2010 17:24:16 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, sclark46@earthlink.net Date: Fri, 29 Oct 2010 17:24:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CCAE59E.5020006@earthlink.net> In-Reply-To: <4CCAE59E.5020006@earthlink.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010291724.09211.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 29 Oct 2010 17:24:16 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 21:24:18 -0000 On Friday, October 29, 2010 11:17:50 am Stephen Clark wrote: > Hello, > > I am having a problem getting 6.3 to boot on an intel atom mb. When it > gets to > where it should identify the drive it hangs. > > If I boot with no acpi it does the same thing. > > If I boot with safe mode it comes up and identifies the drive but then > starts spewing the following errors: > ipfw2 initialized, divert enabled, rule-based forwarding disabled, > default to ad > interrupt storm detected on "irq15:"; throttling interrupt source > ad4: 152627MB at ata2-master PIO4 > interrupt storm detected on "irq15:"; throttling interrupt source > interrupt storm detected on "irq15:"; throttling interrupt source > interrupt storm detected on "irq15:"; throttling interrupt source It's odd that you have IRQ15 without a handler. It also seems that, for whatever reason, IRQ15 is set to level trigger, active low (default for PCI) instead of edge trigger, active hi (default for ISA). Would be interesting to see a verbose dmesg from a 7.2 boot perhaps. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 21:53:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84D651065670; Fri, 29 Oct 2010 21:53:50 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1638FC0A; Fri, 29 Oct 2010 21:53:50 +0000 (UTC) Received: by iwn39 with SMTP id 39so4145687iwn.13 for ; Fri, 29 Oct 2010 14:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.226.5 with SMTP id iu5mr670308icb.12.1288387414388; Fri, 29 Oct 2010 14:23:34 -0700 (PDT) Received: by 10.220.187.71 with HTTP; Fri, 29 Oct 2010 14:23:34 -0700 (PDT) X-Originating-IP: [128.95.133.12] In-Reply-To: <20101029193850.GH11447@gradx.cs.jhu.edu> References: <20101029193850.GH11447@gradx.cs.jhu.edu> Date: Fri, 29 Oct 2010 14:23:34 -0700 Message-ID: From: Rob Farmer To: Nathaniel W Filardo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: Cross-build failure on sparc64 for TARGET=amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 21:53:50 -0000 On Fri, Oct 29, 2010 at 12:38, Nathaniel W Filardo wrote: > Running >> sudo make TARGET_ARCH=3Damd64 TARGET=3Damd64 DESTDIR=3D/usr/x86_64 -j4 b= uildworld > on >> FreeBSD sparcslave.priv.oc.ietfng.org 8.1-STABLE FreeBSD 8.1-STABLE #2 r= 214092=3D9050e7b-dirty: Thu Oct 21 01:25:54 UTC 2010 root@t@sparcslave.priv= .oc.ietfng.org:/usr/obj/usr/src/sys/SLAVKERN =A0sparc64 I tried this about a year ago - it didn't work then and I suspect it never has. I'm not sure what the cause is. In any case, sparc's are almost always a lot slower than just building natively on amd64 hardware, so you probably aren't going to get people too excited about fixing it without tracking down the exact problem and/or sending a patch. --=20 Rob Farmer From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 22:59:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EBBF106564A for ; Fri, 29 Oct 2010 22:59:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EB7CB8FC08 for ; Fri, 29 Oct 2010 22:59:55 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9TMxpGS044681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Oct 2010 01:59:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9TMxpIL033834; Sat, 30 Oct 2010 01:59:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9TMxp6H033833; Sat, 30 Oct 2010 01:59:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Oct 2010 01:59:51 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101029225951.GZ2392@deviant.kiev.zoral.com.ua> References: <4CCACDC0.7050802@icyb.net.ua> <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> <20101029145349.GX2392@deviant.kiev.zoral.com.ua> <4CCAE2B6.1050906@icyb.net.ua> <20101029151727.GY2392@deviant.kiev.zoral.com.ua> <4CCAE6CE.9020509@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YvLLLzhFN3pBahCG" Content-Disposition: inline In-Reply-To: <4CCAE6CE.9020509@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, Alexander Zagrebin Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 22:59:56 -0000 --YvLLLzhFN3pBahCG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 29, 2010 at 06:22:54PM +0300, Andriy Gapon wrote: > on 29/10/2010 18:17 Kostik Belousov said the following: > > On Fri, Oct 29, 2010 at 06:05:26PM +0300, Andriy Gapon wrote: > >> on 29/10/2010 17:53 Kostik Belousov said the following: > >>> Could it be the priming of the vm object pages content ? > >> > >> Sorry, not familiar with this term. > >> Do you mean prepopulation of vm object with valid pages? > >> > >>> Due to double-buffering, and (possibly false) optimization to only > >> > >> What optimization? > > On zfs vnode read, the page from the corresponding vm object is only > > populated with the vnode data if the page already exists in the > > object. >=20 > Do you mean a specific type of read? > For "normal" reads it's the other way around - if the page already exists= and is > valid, then we read from the page, not from ARC. Let me repeat it once more: zfs does not properly caches the vnode data content in the page cache (the cache is used in a weaker sence, not meaning the freebsd 'cached' memory, but a cache in more common sence). Not doing the optimization I mentioned would mean always allocating the pages and making it (partially) valid for each read call. >=20 > > Not doing the optimization would be to allocate the page uncoditionally > > on the read if not already present, and copy the data from ARC to the p= age. > >> > >>> perform double-buffering when vm object already has some data cached, > >>> reads can prime vm object page list before file is mmapped or > >>> sendfile-ed. > >>> > >> > >> No double-buffering is done to optimize anything. Double-buffering > >> is a consequence of having page cache and ARC. The special > >> "double-buffering code" is to just handle that fact - e.g. making > >> sure that VOP_READ reads data from page cache instead of ARC if it's > >> possible that the data in them differs (i.e. page cache has more > >> recent data). > >> > >> So, if I understood the term 'priming' correctly, no priming should > >> ever occur. > > The priming is done on the first call to VOP_READ() with the right > > offset after the page is allocated. >=20 > Again, what is priming? Filling the cache with an appropriate content. --YvLLLzhFN3pBahCG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzLUecACgkQC3+MBN1Mb4gh8wCeIlW79u45lF5hA/a6C4kVz90V qDQAn1k3WXZQj6KMeT2XfZiG+lfSRu2x =J/ZR -----END PGP SIGNATURE----- --YvLLLzhFN3pBahCG-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 23:06:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4709106564A for ; Fri, 29 Oct 2010 23:06:47 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 700718FC0C for ; Fri, 29 Oct 2010 23:06:47 +0000 (UTC) Received: by qwg8 with SMTP id 8so1554555qwg.13 for ; Fri, 29 Oct 2010 16:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=96wKBaNyHn7eEpYAN9jhtAHDhZF2rIzA3bmlJvp3a3M=; b=DEIFUxCF3vVPqQYLFg0/74gpkAnjSEWwqkz36EHQG5XQAU54w6yAifIFh+EWPyCjef BBi/LtcCiqWuh7UIxcVt3ePPdzKBGJLOoN9LAjREeG2GprxntOqwjVkCkzeNCc/uRD1T 98k7daKdwcxC/OX+k5m9yuYRwoICrxrFqALOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DoLs+ittWJtPVp7CvGdZr1+SFFW6P2dWVHLxIEJigfXCPP1MeYvN2f8seroYqtZ5sV kpEBoxNnJCECAg2pFR4GQZG+0jzi2d02WDI6fMjhQAPxpwqulwKnXtiMCiwx6hOcEI53 VGpwR8vsEF4W1Tj+AdTgbfrCCHQVJjdR4ehaI= MIME-Version: 1.0 Received: by 10.229.218.11 with SMTP id ho11mr12184280qcb.251.1288393606623; Fri, 29 Oct 2010 16:06:46 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.180.2 with HTTP; Fri, 29 Oct 2010 16:06:46 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 16:06:46 -0700 X-Google-Sender-Auth: OsnPdnIRBf_rzcCOvmqckc3-DKE Message-ID: From: Artem Belevich To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 23:06:47 -0000 On Fri, Oct 29, 2010 at 2:19 PM, Rumen Telbizov wrote: > You're right.=A0zpool export tank seems to remove the cache file so impor= t has > nothing to consult so doesn't=A0make any difference. > I guess my only chance at this point would be to somehow manually edit > the zpool configuration, via the zpool.cache file or not, and substitute > mfid with gpt/disk?! > Is there a way to do this? I'm not aware of any tools to edit zpool.cache. What's really puzzling is why GPT labels disappear in the middle of zpool import. I'm fresh out of ideas why that would happen. What FreeBSD version are you running. SVN revision of the sources would be good, but date may also work. --Artem From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 23:42:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA92106566B for ; Fri, 29 Oct 2010 23:42:45 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id AA7998FC0A for ; Fri, 29 Oct 2010 23:42:44 +0000 (UTC) Received: by qwg8 with SMTP id 8so1578746qwg.13 for ; Fri, 29 Oct 2010 16:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=FsNdxuvX+CUyMTwxijb1p1WWtZ9fn37KZn3ZLHzuADc=; b=WXz7shstdgCbaOteODR+MPHRNVsm9u+gBZP9o0gCPzyt64nOwZIGtPMYR1gspElo+D +Wpj/Ovv0oOlGOwjkflhiFGmf0e0RBILAaUxl2suwIJxu53OQHks1ebyFCLngeMDMGxa 5puscoAyoZlLvp9eH8owRo9lc7c03zBCPGT5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cvWUbc27zK8Sebz8Q7R0rpnarUUmQDKqWzl27Yka8lSOlLM0BgmJVHa1iszmD18eIY hdK4pelFbZHRk0T73wrjLZExylpLqT7VD6iUPBBJ7fhugreto1CkNnsCkgBDLh58ZJxI KVR3C3XYHDlVY5uCobzhGXvrmRLDeLM6SLnCc= MIME-Version: 1.0 Received: by 10.224.75.69 with SMTP id x5mr6032462qaj.82.1288395763773; Fri, 29 Oct 2010 16:42:43 -0700 (PDT) Received: by 10.229.110.12 with HTTP; Fri, 29 Oct 2010 16:42:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 16:42:43 -0700 Message-ID: From: Rumen Telbizov To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 23:42:45 -0000 Hi Artem, What's really puzzling is why GPT labels disappear in the middle of > zpool import. I'm fresh out of ideas why that would happen. > Thanks for your support anyway. Appreciated. What FreeBSD version are you running. SVN revision of the sources > would be good, but date may also work. > FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 That's when I csuped and rebuilt world/kernel. I can (and probably will) very easily csup it to the latest stable and try to upgrade zfs to version 15 which was incorporated shortly after this build. See if that makes any difference. I wonder if there's a way to fix it over OpenSolaris LiveCD. Somehow load the gpt labeled partitions and save the cache file. Regards, -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 00:01:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA9C91065694 for ; Sat, 30 Oct 2010 00:01:23 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 735758FC08 for ; Sat, 30 Oct 2010 00:01:23 +0000 (UTC) Received: by vws12 with SMTP id 12so528944vws.13 for ; Fri, 29 Oct 2010 17:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vvHMdcYNJ/Pu8U9EHZlUaL7RZmsAVnKdNEYTipG9Fjw=; b=dLGCRBkkYgnzs2s+0ODY+mAAJmj/CGbk6+Qc+712t6gHGBt4pfqt/ttv1erz32H1t4 BVbbg/3WripqyznDinbab9C0DYcsazHaMTofthLmflSVnbIb2/IQ+irgiqppYF1XnGmr s0yOYjwpP/1KX1de/PkXaQLMIaVkmPKCYlK18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XB3aMXk7mcjeTrVlil69C1ndaEBjkF4hBTkhWZVU7XjnfDIXDoYn/eA53FHCrr+3Kj kJoStPrEUjhtlRpzdm2caSAoc3+MKrAZP3g7rSqb9y7rb/I6YBIbZGp9ld/1R8x+4uYe QpuQMEmA7lpLuX32YFxljLitX4hfzeiG2krOA= MIME-Version: 1.0 Received: by 10.224.217.74 with SMTP id hl10mr2737816qab.124.1288396882426; Fri, 29 Oct 2010 17:01:22 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.180.2 with HTTP; Fri, 29 Oct 2010 17:01:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 17:01:22 -0700 X-Google-Sender-Auth: g1SaAgpOm7hzHvzbf3c37-TQ8WM Message-ID: From: Artem Belevich To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 00:01:23 -0000 On Fri, Oct 29, 2010 at 4:42 PM, Rumen Telbizov wrote: > FreeBSD 8.1-STABLE #0: Sun Sep =A05 00:22:45 PDT 2010 > That's when I csuped and rebuilt world/kernel. There were a lot of ZFS-related MFCs since then. I'd suggest updating to the most recent -stable and try again. I've got another idea that may or may not work. Assuming that GPT labels disappear because zpool opens one of the /dev/mfid* devices, you can try to do "chmod a-rw /dev/mfid*" on them and then try importing the pool again. --Artem From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 01:24:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 436E61065780 for ; Sat, 30 Oct 2010 01:24:38 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD7A48FC1A for ; Sat, 30 Oct 2010 01:24:37 +0000 (UTC) Received: by vws12 with SMTP id 12so621625vws.13 for ; Fri, 29 Oct 2010 18:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CSAV51YPuXn71D0qOi8/XLuvemZA27VUTEOPQEIRNFE=; b=lJPUWt/oW/IslJtj/1yYh2P94zce/ez3lNHNQSy8sdWAnEZyc+ZY5Wu1wgbRmCf0Gz OD6+HGBUwE8Q5Ju/l3znyfTSl/5JaOPagt2sbfWlV1XtCN8F0ZQGwlv+F1ktP2koWaXN FHAtVbZWSGqz7nFCnesfRPIBhVoDNeQE/uQaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o1DNgk+mLnE1Rg8GtyEvbWBrStysaIKsRrwRbf20KBGBx9sLFVkOPBLwDUaVG7Su1Z 6RfGhJ75MhgyeOgQik+hGUyDv+cblc9J2A+gnk3yZzYrMqqEAg1Zx4hpPJb5moaw/PBr 4eCd9kzd4FJ8gVFX9J7Ned+VDdfsUJe/y3Qfk= MIME-Version: 1.0 Received: by 10.224.20.166 with SMTP id f38mr5364689qab.274.1288401876272; Fri, 29 Oct 2010 18:24:36 -0700 (PDT) Received: by 10.229.110.12 with HTTP; Fri, 29 Oct 2010 18:24:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Oct 2010 18:24:36 -0700 Message-ID: From: Rumen Telbizov To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 01:24:38 -0000 Thanks Artem, I'll upgrade to latest stable and zfs 15 tomorrow or Sunday and I'll see if that makes it any better. If not I'll also try the chmod operation below. Thanks for the suggestions. I'll report back here. Regards, Rumen Telbizov On Fri, Oct 29, 2010 at 5:01 PM, Artem Belevich wrote: > On Fri, Oct 29, 2010 at 4:42 PM, Rumen Telbizov > wrote: > > FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 > > That's when I csuped and rebuilt world/kernel. > > There were a lot of ZFS-related MFCs since then. I'd suggest updating > to the most recent -stable and try again. > > I've got another idea that may or may not work. Assuming that GPT > labels disappear because zpool opens one of the /dev/mfid* devices, > you can try to do "chmod a-rw /dev/mfid*" on them and then try > importing the pool again. > > --Artem > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 03:27:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBFE31065672 for ; Sat, 30 Oct 2010 03:27:51 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6DCB98FC21 for ; Sat, 30 Oct 2010 03:27:51 +0000 (UTC) Received: by gxk9 with SMTP id 9so2529593gxk.13 for ; Fri, 29 Oct 2010 20:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=jPXhkWXzG5/L3gdAKPt/oJkHZ2+WCMem8kNShACLJDs=; b=dWUv11MMctbFcJKZ5N24bT3yTaiRqqTwe0ay7kAuMeV9qLaky0qw0G6mO7gbE2EYC2 bKU8QjRr92HOhC0Y7bn8Ngofxc7cUmtNdLQof/i9al5iScjYYTRQALj0JisJOoU9BIsw ak4X8Ua1K70nmvOxN3t0ZPoD5HD3H6wqdiN3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=smN2V3TLtAu7nR7Cjkz74YAFODT0lqmzBMpx/OJBRzm0rbg5OSXC+Xdvs9lh7rq4mG VsFsZDM6f/wVtWEb9tg8yRMRFJvKw7x2ept21DGq7vpuoiLQ6ScCAt1Aizn3qPb1HcBB GV8EpnltmzqX+shdzs3xDObBm8bD9q5LocmYI= Received: by 10.151.154.2 with SMTP id g2mr23218278ybo.67.1288409270567; Fri, 29 Oct 2010 20:27:50 -0700 (PDT) Received: from centel.dataix.local ([99.181.136.243]) by mx.google.com with ESMTPS id q41sm2501277ybk.1.2010.10.29.20.27.47 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 20:27:48 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CCB90B1.90008@DataIX.net> Date: Fri, 29 Oct 2010 23:27:45 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Chuck Swiger References: <4CC5F489.50403@omnilan.de> <88CBD70C-DA5A-4B3A-A703-7C0D6B189697@mac.com> In-Reply-To: <88CBD70C-DA5A-4B3A-A703-7C0D6B189697@mac.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org Subject: Re: POSIX file permission (understanding) problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 03:27:51 -0000 On 10/25/2010 18:28, Chuck Swiger wrote: > chmod g+w testdir/ (as superuser, exit again) >> > > ls -ld testdir >> > > drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir >> ls -l testdir >> total 0 >> -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile > >> -> Now editing with vi (as user harry) changes the ownership of the >> file and writing is successfull: >> ls -l testdir/ >> total 2 >> -rw-r----- 1 harry intern 5 25 Okt 23:10 testfile > > A file in a sticky directory may only be removed or renamed > by a user if the user has write permission for the directory and the user > is the owner of the file, the owner of the directory, or the super-user. Obviously he is not the owner of the file, directory, nor the superuser in this case so if I am missing something here please forgive me but I still see a big problem with this.... -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 03:29:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 163461065672 for ; Sat, 30 Oct 2010 03:29:33 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB1CC8FC08 for ; Sat, 30 Oct 2010 03:29:32 +0000 (UTC) Received: by gxk9 with SMTP id 9so2529912gxk.13 for ; Fri, 29 Oct 2010 20:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=y5OrAgLqGY5wPvCcADi4+3Ryr0l7/DpUCnIlNlwNPPo=; b=Z5eO1mk+Xenn4O5V6YyQPsr5kohwkK7r/ecYDGNSq8OXH9I8Xw+BxdZz6NHvHPgvVo ufFg380MevqivjNF4acpuo1gjSr9DUMsiJsdX61MqSrZOHrSKMyI445Sb9stkHA4W1A7 eQcPbnpPb+BefIMHgTeWoHsow3wRrPMwG6uYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=AAGAJlYvAbtsEPP4cDlQqYp/6PREmynnsQgjL5OyCJIygQ6ALAiy74xD+fPpEY00wq KCrydLyWpNsfI2r3hhNAsCwdIL40nRinWywBFhBtosxaaiJ0R+uMAPOHh3pr9wiMVn/4 iu8solzmWO8pZDUFOYAlfubh+AgxnJRPr2PJs= Received: by 10.151.43.21 with SMTP id v21mr23121247ybj.196.1288409371931; Fri, 29 Oct 2010 20:29:31 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-136-243.dsl.klmzmi.sbcglobal.net [99.181.136.243]) by mx.google.com with ESMTPS id p38sm137005ybk.4.2010.10.29.20.29.30 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 20:29:31 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CCB9119.6070303@DataIX.net> Date: Fri, 29 Oct 2010 23:29:29 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Chuck Swiger References: <4CC5F489.50403@omnilan.de> <88CBD70C-DA5A-4B3A-A703-7C0D6B189697@mac.com> <4CCB90B1.90008@DataIX.net> In-Reply-To: <4CCB90B1.90008@DataIX.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org Subject: Re: POSIX file permission (understanding) problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 03:29:33 -0000 On 10/29/2010 23:27, jhell wrote: > On 10/25/2010 18:28, Chuck Swiger wrote: >> chmod g+w testdir/ (as superuser, exit again) >>> >> >> ls -ld testdir >>> >> >> drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir >>> ls -l testdir >>> total 0 >>> -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile >> >>> -> Now editing with vi (as user harry) changes the ownership of the >>> file and writing is successfull: >>> ls -l testdir/ >>> total 2 >>> -rw-r----- 1 harry intern 5 25 Okt 23:10 testfile >> >> A file in a sticky directory may only be removed or renamed >> by a user if the user has write permission for the directory and the user >> is the owner of the file, the owner of the directory, or the super-user. > > > Obviously he is not the owner of the file, directory, nor the superuser > in this case so if I am missing something here please forgive me but I > still see a big problem with this.... > Never mind... forhot the chmod g+w. -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 07:53:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C60181065674; Sat, 30 Oct 2010 07:53:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D895C8FC18; Sat, 30 Oct 2010 07:53:43 +0000 (UTC) Received: from porto.topspin.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 KAA18202; Sat, 30 Oct 2010 10:53:38 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC6Ft-000J3E-Kv; Sat, 30 Oct 2010 10:53:37 +0300 Message-ID: <4CCBCF00.2030904@icyb.net.ua> Date: Sat, 30 Oct 2010 10:53:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> In-Reply-To: <4CCADD37.7000306@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Alexander Zagrebin , freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 07:53:45 -0000 on 29/10/2010 17:41 Andriy Gapon said the following: > on 29/10/2010 15:36 Andriy Gapon said the following: >> on 29/10/2010 12:04 Artemiev Igor said the following: >>> Yep, this problem exists. You may workaround it via bumping up >>> net.inet.tcp.sendspace up to 128k. zfs sendfile is very ineffective. I have >>> made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm >>> only one page (4K). I.e. if you have a file with size 512K, sendfile make >>> calls freebsd_zfs_read 128 times. >> >> What svn revision of FreeBSD source tree did you test? >> > > Ah, I think I see what's going on. > Either sendfile should (have an option to) use VOP_GETPAGES to request data or ZFS > mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY case. > Currently ZFS would read a whole FS block into ARC, but populate only one page > with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from > ARC data. > So, e.g. zpool iostat would show that there are only few actual reads from a pool. > The rest of the time must be spent churning over the data already in ARC and > doing page-per-VOP_READ copies from it. Hmm, I investigated the issue some more and now I wouldn't put all the blame on ZFS. Indeed, perhaps ZFS is very inefficient here, perhaps it does extra looping and extra copying. However those operations should not lead to such a significant slowdown, but mostly to an increased CPU usage. So, it looks that sendfile spends most of the time in sbwait(). Of course, "erratic" behavior of ZFS does contribute to that. It's this code in kern_sendfile that gets triggered by ZFS: if (pg->valid && vm_page_is_valid(pg, pgoff, xfsize)) VM_OBJECT_UNLOCK(obj); else if (m != NULL) error = EAGAIN; /* send what we already got */ else ... Essentially, data is not only read from ZFS page by page, but it is also mostly sent with page-sized chunk at a time. P.S. just stating the obvious, kind of :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 08:16:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E41921065673; Sat, 30 Oct 2010 08:16:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EBDA98FC1F; Sat, 30 Oct 2010 08:16:08 +0000 (UTC) Received: from porto.topspin.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 LAA18380; Sat, 30 Oct 2010 11:16:04 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC6bc-000J4e-Ad; Sat, 30 Oct 2010 11:16:04 +0300 Message-ID: <4CCBD443.7010305@icyb.net.ua> Date: Sat, 30 Oct 2010 11:16:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> In-Reply-To: <20101029175105.GB18613@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 08:16:10 -0000 on 29/10/2010 20:51 Artemiev Igor said the following: > On Fri, Oct 29, 2010 at 07:06:03PM +0300, Andriy Gapon wrote: >> Probably yes, but have to be careful there. >> First, do vm_page_grab only for UIO_NOCOPY case. >> Second, the first page is already "shared busy" after vm_page_io_start() call in >> kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a deadlock. > > RELENG_8 doesn`t have VM_ALLOC_IGN_SBUSY, it appeared only in HEAD. > Can you review this patch, Whether correctly I have understood? (didnt test it yet) > > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2010-10-29 18:18:23.921078337 +0200 > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-10-29 19:23:48.142513084 +0200 > @@ -449,7 +449,7 @@ > int bytes = MIN(PAGESIZE - off, len); > > again: > - if ((m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL && > + if (uio->uio_segflg != UIO_NOCOPY && (m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL && > vm_page_is_valid(m, off, bytes)) { > if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > @@ -464,7 +464,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { > + } else if (uio->uio_segflg == UIO_NOCOPY) { > /* > * The code below is here to make sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -472,11 +472,9 @@ > * but it pessimize performance of sendfile/UFS, that's > * why I handle this special case in ZFS code. > */ > - KASSERT(off == 0, > - ("unexpected offset in mappedread for sendfile")); > - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > - goto again; > - vm_page_busy(m); > + if((m = vm_page_lookup(obj, OFF_TO_IDX(start))) == NULL || !vm_page_is_valid(m, off, bytes)) > + m = vm_page_grab(obj, OFF_TO_IDX(start), VM_ALLOC_NORMAL|VM_ALLOC_RETRY); > + > VM_OBJECT_UNLOCK(obj); > if (dirbytes > 0) { > error = dmu_read_uio(os, zp->z_id, uio, Or maybe something like the following? It looks a little bit cleaner to me, but still is not perfect, as I have not handled unnecessary busy-ing of the pages where something more lightweight could have sufficed (e.g. wiring and shared busying). Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -476,6 +477,16 @@ ("unexpected offset in mappedread for sendfile")); if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } vm_page_busy(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 08:16:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2CAC1065674; Sat, 30 Oct 2010 08:16:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D57618FC19; Sat, 30 Oct 2010 08:16:50 +0000 (UTC) Received: from porto.topspin.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 LAA18390; Sat, 30 Oct 2010 11:16:47 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC6cI-000J4l-TR; Sat, 30 Oct 2010 11:16:46 +0300 Message-ID: <4CCBD46E.9030200@icyb.net.ua> Date: Sat, 30 Oct 2010 11:16:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> In-Reply-To: <4CCBD443.7010305@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 08:16:51 -0000 on 30/10/2010 11:16 Andriy Gapon said the following: > Or maybe something like the following? > It looks a little bit cleaner to me, but still is not perfect, as I have not > handled unnecessary busy-ing of the pages where something more lightweight could > have sufficed (e.g. wiring and shared busying). Note: I have only compile tested the patch. > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =================================================================== > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > /* > * Programming rules. > @@ -464,7 +465,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { > + } else if (uio->uio_segflg == UIO_NOCOPY) { > /* > * The code below is here to make sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -476,6 +477,16 @@ > ("unexpected offset in mappedread for sendfile")); > if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > + if (m == NULL) { > + m = vm_page_alloc(obj, OFF_TO_IDX(start), > + VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM); > + if (m == NULL) { > + VM_OBJECT_UNLOCK(obj); > + VM_WAIT; > + VM_OBJECT_LOCK(obj); > + goto again; > + } > + } > vm_page_busy(m); > VM_OBJECT_UNLOCK(obj); > if (dirbytes > 0) { > > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 08:25:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D5D1065670; Sat, 30 Oct 2010 08:25: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 DA2458FC19; Sat, 30 Oct 2010 08:25:10 +0000 (UTC) Received: from porto.topspin.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 LAA18465; Sat, 30 Oct 2010 11:25:06 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC6kM-000J5V-5p; Sat, 30 Oct 2010 11:25:06 +0300 Message-ID: <4CCBD661.3000204@freebsd.org> Date: Sat, 30 Oct 2010 11:25:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> In-Reply-To: <4CCBD46E.9030200@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 08:25:11 -0000 on 30/10/2010 11:16 Andriy Gapon said the following: > on 30/10/2010 11:16 Andriy Gapon said the following: >> Or maybe something like the following? >> It looks a little bit cleaner to me, but still is not perfect, as I have not >> handled unnecessary busy-ing of the pages where something more lightweight could >> have sufficed (e.g. wiring and shared busying). > > Note: I have only compile tested the patch. Missed one NULL check. Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,8 +475,18 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } vm_page_busy(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 09:53:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21DC9106566B; Sat, 30 Oct 2010 09:53:01 +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 317CA8FC0C; Sat, 30 Oct 2010 09:52:59 +0000 (UTC) Received: from porto.topspin.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 MAA19288; Sat, 30 Oct 2010 12:52:56 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC87M-000JBJ-Dx; Sat, 30 Oct 2010 12:52:56 +0300 Message-ID: <4CCBEAF6.2030408@freebsd.org> Date: Sat, 30 Oct 2010 12:52:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Artemiev Igor References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> In-Reply-To: <4CCBD661.3000204@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Alexander Zagrebin , freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 09:53:01 -0000 Heh, next try. Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,9 +475,23 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; - vm_page_busy(m); + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_NORMAL); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } else { + vm_page_lock_queues(); + vm_page_wire(m); + vm_page_unlock_queues(); + } + vm_page_io_start(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, @@ -494,7 +509,10 @@ VM_OBJECT_LOCK(obj); if (error == 0) m->valid = VM_PAGE_BITS_ALL; - vm_page_wakeup(m); + vm_page_io_finish(m); + vm_page_lock_queues(); + vm_page_unwire(m, 0); + vm_page_unlock_queues(); if (error == 0) { uio->uio_resid -= bytes; uio->uio_offset += bytes; -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 09:54:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C48D21065670; Sat, 30 Oct 2010 09:54:16 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4C58FC1E; Sat, 30 Oct 2010 09:54:16 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PC88c-0007UR-Cg; Sat, 30 Oct 2010 13:54:14 +0400 Date: Sat, 30 Oct 2010 13:54:25 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101030095425.GA79691@two.kliksys.ru> References: <3D1C350B94A44E5D95BAA1596D1EBF13@vosz.local> <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCBD661.3000204@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 09:54:16 -0000 On Sat, Oct 30, 2010 at 11:25:05AM +0300, Andriy Gapon wrote: > > Note: I have only compile tested the patch. > > Missed one NULL check. > > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =================================================================== > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > /* > * Programming rules. > @@ -464,7 +465,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { > + } else if (uio->uio_segflg == UIO_NOCOPY) { > /* > * The code below is here to make sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -474,8 +475,18 @@ > */ > KASSERT(off == 0, > ("unexpected offset in mappedread for sendfile")); > - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > + if (m == NULL) { > + m = vm_page_alloc(obj, OFF_TO_IDX(start), > + VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM); > + if (m == NULL) { > + VM_OBJECT_UNLOCK(obj); > + VM_WAIT; > + VM_OBJECT_LOCK(obj); > + goto again; > + } > + } > vm_page_busy(m); > VM_OBJECT_UNLOCK(obj); > if (dirbytes > 0) { Ok, i tested this patch. It worked :) freebsd_zfs_read now calls (file_size/MAXBSIZE) times. Thanks! From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 10:12:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85F3106564A; Sat, 30 Oct 2010 10:12:44 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1D18FC13; Sat, 30 Oct 2010 10:12:44 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PC8QV-0007nb-Av; Sat, 30 Oct 2010 14:12:43 +0400 Date: Sat, 30 Oct 2010 14:12:54 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101030101254.GB79691@two.kliksys.ru> References: <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCBEAF6.2030408@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 10:12:44 -0000 On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: > Heh, next try. Got a panic, "vm_page_unwire: invalid wire count: 0" From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 10:33:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7860E106564A; Sat, 30 Oct 2010 10:33:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7AF8FC0A; Sat, 30 Oct 2010 10:33:04 +0000 (UTC) Received: from porto.topspin.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 NAA19683; Sat, 30 Oct 2010 13:33:01 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PC8k8-000JE4-SC; Sat, 30 Oct 2010 13:33:00 +0300 Message-ID: <4CCBF45C.4080208@icyb.net.ua> Date: Sat, 30 Oct 2010 13:33:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Artemiev Igor References: <20101029090417.GA17537@two.kliksys.ru> <4CCABFC2.3040701@icyb.net.ua> <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> In-Reply-To: <20101030101254.GB79691@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 10:33:05 -0000 on 30/10/2010 13:12 Artemiev Igor said the following: > On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: > >> Heh, next try. > > Got a panic, "vm_page_unwire: invalid wire count: 0" Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm_page_alloc): Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,9 +475,23 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; - vm_page_busy(m); + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_WIRE | VM_ALLOC_NORMAL); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } else { + vm_page_lock_queues(); + vm_page_wire(m); + vm_page_unlock_queues(); + } + vm_page_io_start(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, @@ -494,7 +509,10 @@ VM_OBJECT_LOCK(obj); if (error == 0) m->valid = VM_PAGE_BITS_ALL; - vm_page_wakeup(m); + vm_page_io_finish(m); + vm_page_lock_queues(); + vm_page_unwire(m, 0); + vm_page_unlock_queues(); if (error == 0) { uio->uio_resid -= bytes; uio->uio_offset += bytes; -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 11:25:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30000106566C; Sat, 30 Oct 2010 11:25:10 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id DA32D8FC18; Sat, 30 Oct 2010 11:25:09 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PC9Ya-0008zL-SL; Sat, 30 Oct 2010 15:25:08 +0400 Date: Sat, 30 Oct 2010 15:25:20 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101030112520.GD79691@two.kliksys.ru> References: <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCBF45C.4080208@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam_score: 0.0 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 11:25:10 -0000 On Sat, Oct 30, 2010 at 01:33:00PM +0300, Andriy Gapon wrote: > on 30/10/2010 13:12 Artemiev Igor said the following: > > On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: > > > >> Heh, next try. > > > > Got a panic, "vm_page_unwire: invalid wire count: 0" > > Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm_page_alloc): Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, therefore i slightly modified your patch: --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2010-10-30 11:56:41.621138440 +0200 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-10-30 12:49:32.858692096 +0200 @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,9 +475,23 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; - vm_page_busy(m); + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_NORMAL); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } + vm_page_lock_queues(); + vm_page_wire(m); + vm_page_unlock_queues(); + + vm_page_io_start(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, @@ -494,6 +509,10 @@ VM_OBJECT_LOCK(obj); if (error == 0) m->valid = VM_PAGE_BITS_ALL; + vm_page_io_finish(m); + vm_page_lock_queues(); + vm_page_unwire(m, 0); + vm_page_unlock_queues(); vm_page_wakeup(m); if (error == 0) { uio->uio_resid -= bytes; From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 12:26:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 523AB106564A; Sat, 30 Oct 2010 12:26:03 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A23E18FC12; Sat, 30 Oct 2010 12:26:02 +0000 (UTC) Received: by fxm17 with SMTP id 17so3987590fxm.13 for ; Sat, 30 Oct 2010 05:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=9XvX+Uz72cRL2KM9u38CIuXYBkmBZxVuQ0gDVdbmfjQ=; b=EbCgkX95ZYigNMmmR00L1txNNshpehvxJ5GBNqf3W1UEJLdE09qAo/kRhfwx8fZFUO 2KcoQqk9NZx4IGtrXmsmACQyvcNLROUE3Dy0bvIemco5fKG31hlaWMcYQnzvBxtwW0gP delHOZ9a6EPRWeQAc2hYJLNA+yytcr+x1sMHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=cKfqggoPjLlcS7SJEsxGhFuJBwaPvfnkMhMr7vAhCvt77e5v/Lb6UnLNw92qSBHU/W L6N3olyiFMu6BRelPG+oiCkwq1oOTYa5PPkB1mPctAIbkd3BlOQlJZirzXmWa93IDFGy tGSEXplAKtOToa/5x6apd30NbRTWSNU4/Bqgo= Received: by 10.223.102.78 with SMTP id f14mr1920469fao.66.1288441561769; Sat, 30 Oct 2010 05:26:01 -0700 (PDT) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id j14sm1527460faa.47.2010.10.30.05.25.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 30 Oct 2010 05:25:59 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek References: <86wrp3wj67.fsf@kopusha.home.net> <20101028163036.GA2347@garage.freebsd.pl> <86lj5i3zjt.fsf@kopusha.home.net> X-Comment-To: Mikolaj Golub Date: Sat, 30 Oct 2010 15:25:56 +0300 In-Reply-To: <86lj5i3zjt.fsf@kopusha.home.net> (Mikolaj Golub's message of "Thu, 28 Oct 2010 22:08:54 +0300") Message-ID: <86d3qr3m0b.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: hast vs ggate+gmirror sychrnoisation speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 12:26:03 -0000 --=-=-= On Thu, 28 Oct 2010 22:08:54 +0300 Mikolaj Golub wrote to Pawel Jakub Dawidek: PJD>> I looked at the code and the keepalive packets arbe sent from another PJD>> thread. Could you try turning them off in primary.c and see if that PJD>> helps? MG> At first I set RETRY_SLEEP to 1 sec to have more keepalive packets. The errors MG> started to observe frequently: MG> Oct 28 21:35:53 bolek hastd[1709]: [storage] (secondary) Unable to receive request header: RPC version wrong. MG> Oct 28 21:35:54 bolek hastd[1632]: [storage] (secondary) Worker process exited ungracefully (pid=1709, exitcode=75). MG> Oct 28 21:36:12 bolek hastd[1722]: [storage] (secondary) Unable to receive request header: RPC version wrong. MG> Oct 28 21:36:12 bolek hastd[1632]: [storage] (secondary) Worker process exited ungracefully (pid=1722, exitcode=75). MG> ... MG> Now I have been running synchronization for more then a half an hour with MG> keepalive_send disabled and have not seen any error. So :-) What do you think about sending keepalive in remote_send_thread() to avoid this problem and sending them only when a connection is idle (it looks like there is no much use to send them all the time)? Something like in the patch below (it works for me). -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=hastd.keepalive.patch Index: sbin/hastd/primary.c =================================================================== --- sbin/hastd/primary.c (revision 214550) +++ sbin/hastd/primary.c (working copy) @@ -190,6 +190,19 @@ static pthread_mutex_t metadata_lock; hio_next[(ncomp)]); \ mtx_unlock(&hio_##name##_list_lock[(ncomp)]); \ } while (0) +#define QUEUE_TRY1(hio, name, ncomp) do { \ + mtx_lock(&hio_##name##_list_lock[(ncomp)]); \ + (hio) = TAILQ_FIRST(&hio_##name##_list[(ncomp)]); \ + if (hio == NULL) { \ + cv_timedwait(&hio_##name##_list_cond[(ncomp)], \ + &hio_##name##_list_lock[(ncomp)], RETRY_SLEEP); \ + hio = TAILQ_FIRST(&hio_##name##_list[(ncomp)]); \ + } \ + if (hio != NULL) \ + TAILQ_REMOVE(&hio_##name##_list[(ncomp)], hio, \ + hio_next[(ncomp)]); \ + mtx_unlock(&hio_##name##_list_lock[(ncomp)]); \ +} while (0) #define QUEUE_TAKE2(hio, name) do { \ mtx_lock(&hio_##name##_list_lock); \ while (((hio) = TAILQ_FIRST(&hio_##name##_list)) == NULL) { \ @@ -1176,6 +1189,38 @@ local_send_thread(void *arg) return (NULL); } +static void +keepalive_send(struct hast_resource *res, unsigned int ncomp) +{ + struct nv *nv; + + if (!ISCONNECTED(res, ncomp)) + return; + + assert(res->hr_remotein != NULL); + assert(res->hr_remoteout != NULL); + + nv = nv_alloc(); + nv_add_uint8(nv, HIO_KEEPALIVE, "cmd"); + if (nv_error(nv) != 0) { + nv_free(nv); + pjdlog_debug(1, + "keepalive_send: Unable to prepare header to send."); + return; + } + if (hast_proto_send(res, res->hr_remoteout, nv, NULL, 0) < 0) { + pjdlog_common(LOG_DEBUG, 1, errno, + "keepalive_send: Unable to send request"); + nv_free(nv); + rw_unlock(&hio_remote_lock[ncomp]); + remote_close(res, ncomp); + rw_rlock(&hio_remote_lock[ncomp]); + return; + } + nv_free(nv); + pjdlog_debug(2, "keepalive_send: Request sent."); +} + /* * Thread sends request to secondary node. */ @@ -1184,6 +1229,7 @@ remote_send_thread(void *arg) { struct hast_resource *res = arg; struct g_gate_ctl_io *ggio; + time_t lastcheck, now; struct hio *hio; struct nv *nv; unsigned int ncomp; @@ -1194,10 +1240,19 @@ remote_send_thread(void *arg) /* Remote component is 1 for now. */ ncomp = 1; + lastcheck = time(NULL); for (;;) { pjdlog_debug(2, "remote_send: Taking request."); - QUEUE_TAKE1(hio, send, ncomp); + QUEUE_TRY1(hio, send, ncomp); + if (hio == NULL) { + now = time(NULL); + if (lastcheck + RETRY_SLEEP <= now) { + keepalive_send(res, ncomp); + lastcheck = now; + } + continue; + } pjdlog_debug(2, "remote_send: (%p) Got request.", hio); ggio = &hio->hio_ggio; switch (ggio->gctl_cmd) { @@ -1883,32 +1938,6 @@ failed: } static void -keepalive_send(struct hast_resource *res, unsigned int ncomp) -{ - struct nv *nv; - - nv = nv_alloc(); - nv_add_uint8(nv, HIO_KEEPALIVE, "cmd"); - if (nv_error(nv) != 0) { - nv_free(nv); - pjdlog_debug(1, - "keepalive_send: Unable to prepare header to send."); - return; - } - if (hast_proto_send(res, res->hr_remoteout, nv, NULL, 0) < 0) { - pjdlog_common(LOG_DEBUG, 1, errno, - "keepalive_send: Unable to send request"); - nv_free(nv); - rw_unlock(&hio_remote_lock[ncomp]); - remote_close(res, ncomp); - rw_rlock(&hio_remote_lock[ncomp]); - return; - } - nv_free(nv); - pjdlog_debug(2, "keepalive_send: Request sent."); -} - -static void guard_one(struct hast_resource *res, unsigned int ncomp) { struct proto_conn *in, *out; @@ -1926,12 +1955,6 @@ guard_one(struct hast_resource *res, unsigned int if (ISCONNECTED(res, ncomp)) { assert(res->hr_remotein != NULL); assert(res->hr_remoteout != NULL); - keepalive_send(res, ncomp); - } - - if (ISCONNECTED(res, ncomp)) { - assert(res->hr_remotein != NULL); - assert(res->hr_remoteout != NULL); rw_unlock(&hio_remote_lock[ncomp]); pjdlog_debug(2, "remote_guard: Connection to %s is ok.", res->hr_remoteaddr); --=-=-=-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 14:44:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D3C71065780; Sat, 30 Oct 2010 14:44:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 95BD48FC17; Sat, 30 Oct 2010 14:44:00 +0000 (UTC) Received: from porto.topspin.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 RAA22200; Sat, 30 Oct 2010 17:43:55 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCCew-000JUj-KC; Sat, 30 Oct 2010 17:43:54 +0300 Message-ID: <4CCC2F2A.7020809@icyb.net.ua> Date: Sat, 30 Oct 2010 17:43:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Artemiev Igor References: <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> In-Reply-To: <20101030112520.GD79691@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 14:44:01 -0000 on 30/10/2010 14:25 Artemiev Igor said the following: > On Sat, Oct 30, 2010 at 01:33:00PM +0300, Andriy Gapon wrote: >> on 30/10/2010 13:12 Artemiev Igor said the following: >>> On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: >>> >>>> Heh, next try. >>> >>> Got a panic, "vm_page_unwire: invalid wire count: 0" >> >> Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm_page_alloc): > > Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, therefore i slightly modified your patch: I apologize for my haste, it should have been VM_ALLOC_WIRED. Here is a corrected patch: Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -67,6 +67,7 @@ #include #include #include +#include /* * Programming rules. @@ -464,7 +465,7 @@ uiomove_fromphys(&m, off, bytes, uio); VM_OBJECT_LOCK(obj); vm_page_wakeup(m); - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { + } else if (uio->uio_segflg == UIO_NOCOPY) { /* * The code below is here to make sendfile(2) work * correctly with ZFS. As pointed out by ups@ @@ -474,9 +475,23 @@ */ KASSERT(off == 0, ("unexpected offset in mappedread for sendfile")); - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) goto again; - vm_page_busy(m); + if (m == NULL) { + m = vm_page_alloc(obj, OFF_TO_IDX(start), + VM_ALLOC_NOBUSY | VM_ALLOC_WIRED | VM_ALLOC_NORMAL); + if (m == NULL) { + VM_OBJECT_UNLOCK(obj); + VM_WAIT; + VM_OBJECT_LOCK(obj); + goto again; + } + } else { + vm_page_lock_queues(); + vm_page_wire(m); + vm_page_unlock_queues(); + } + vm_page_io_start(m); VM_OBJECT_UNLOCK(obj); if (dirbytes > 0) { error = dmu_read_uio(os, zp->z_id, uio, @@ -494,7 +509,10 @@ VM_OBJECT_LOCK(obj); if (error == 0) m->valid = VM_PAGE_BITS_ALL; - vm_page_wakeup(m); + vm_page_io_finish(m); + vm_page_lock_queues(); + vm_page_unwire(m, 0); + vm_page_unlock_queues(); if (error == 0) { uio->uio_resid -= bytes; uio->uio_offset += bytes; -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 16:02:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1841D1065672; Sat, 30 Oct 2010 16:02:56 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id B8C498FC0C; Sat, 30 Oct 2010 16:02:54 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PCDtI-0007Ed-Jd; Sat, 30 Oct 2010 20:02:48 +0400 From: "Alexander Zagrebin" To: "'Andriy Gapon'" References: <4CCADD37.7000306@icyb.net.ua> <20101029152602.GA18613@two.kliksys.ru> <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua><4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org><4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua><20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> Date: Sat, 30 Oct 2010 20:02:48 +0400 Keywords: freebsd-stable Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <4CCC2F2A.7020809@icyb.net.ua> Thread-Index: Act4QSnRQ3vtTkc7S9uXBhrhQGUa3QACAn3w Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, 'Artemiev Igor' Subject: RE: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 16:02:56 -0000 > >> Oh, thank you for testing - forgot another piece > (VM_ALLOC_WIRE for vm_page_alloc): > > > > Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, > therefore i slightly modified your patch: > > I apologize for my haste, it should have been VM_ALLOC_WIRED. > Here is a corrected patch: > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =================================================================== > --- > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > (revision 214318) > +++ > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > (working copy) > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > /* > * Programming rules. > @@ -464,7 +465,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { > + } else if (uio->uio_segflg == UIO_NOCOPY) { > /* > * The code below is here to make > sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -474,9 +475,23 @@ > */ > KASSERT(off == 0, > ("unexpected offset in mappedread > for sendfile")); > - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > + if (m != NULL && > vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > - vm_page_busy(m); > + if (m == NULL) { > + m = vm_page_alloc(obj, > OFF_TO_IDX(start), > + VM_ALLOC_NOBUSY | > VM_ALLOC_WIRED | VM_ALLOC_NORMAL); > + if (m == NULL) { > + VM_OBJECT_UNLOCK(obj); > + VM_WAIT; > + VM_OBJECT_LOCK(obj); > + goto again; > + } > + } else { > + vm_page_lock_queues(); > + vm_page_wire(m); > + vm_page_unlock_queues(); > + } > + vm_page_io_start(m); > VM_OBJECT_UNLOCK(obj); > if (dirbytes > 0) { > error = dmu_read_uio(os, zp->z_id, uio, > @@ -494,7 +509,10 @@ > VM_OBJECT_LOCK(obj); > if (error == 0) > m->valid = VM_PAGE_BITS_ALL; > - vm_page_wakeup(m); > + vm_page_io_finish(m); > + vm_page_lock_queues(); > + vm_page_unwire(m, 0); > + vm_page_unlock_queues(); > if (error == 0) { > uio->uio_resid -= bytes; > uio->uio_offset += bytes; > Big thanks to Andriy, Igor and all who has paid attention to this problem. I've tried this patch on the test system running under VirtualBox, and it seems that it solves the problem. I'll try to test this patch in real conditions today. -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 19:01:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A450106566C; Sat, 30 Oct 2010 19:01:11 +0000 (UTC) (envelope-from ai@kliksys.ru) Received: from gate.kliksys.ru (gate.kliksys.ru [78.110.241.113]) by mx1.freebsd.org (Postfix) with ESMTP id 22BA88FC28; Sat, 30 Oct 2010 19:01:11 +0000 (UTC) Received: from [192.168.0.204] (helo=two.kliksys.ru) by gate.kliksys.ru with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PCGft-000GSz-GV; Sat, 30 Oct 2010 23:01:09 +0400 Date: Sat, 30 Oct 2010 23:01:20 +0400 From: Artemiev Igor To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20101030190120.GA80301@two.kliksys.ru> References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCC2F2A.7020809@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-Rspamd-Flag: YES X-Spam_score: 36050387444074.7 Cc: Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 19:01:11 -0000 On Sat, Oct 30, 2010 at 05:43:54PM +0300, Andriy Gapon wrote: > I apologize for my haste, it should have been VM_ALLOC_WIRED. Ok, applied and tested under some load(~1200 active connections, outgoing ~80MB/s). Patch work as expected and i has noted no side effects. Just one question - should grow Active memory counter, if some pages is "hot"(during multiple sendfile on one file)? From owner-freebsd-stable@FreeBSD.ORG Sat Oct 30 23:37:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55947106566B; Sat, 30 Oct 2010 23:37:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id DD8438FC0C; Sat, 30 Oct 2010 23:37:43 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9UNbddd045480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Oct 2010 02:37:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9UNbdiO068739; Sun, 31 Oct 2010 02:37:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9UNbdbY068737; Sun, 31 Oct 2010 02:37:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Oct 2010 02:37:39 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101030233739.GE2392@deviant.kiev.zoral.com.ua> References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H0CA2egUVSYJgt8C" Content-Disposition: inline In-Reply-To: <4CCC2F2A.7020809@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Artemiev Igor Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 23:37:44 -0000 --H0CA2egUVSYJgt8C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 30, 2010 at 05:43:54PM +0300, Andriy Gapon wrote: > on 30/10/2010 14:25 Artemiev Igor said the following: > > On Sat, Oct 30, 2010 at 01:33:00PM +0300, Andriy Gapon wrote: > >> on 30/10/2010 13:12 Artemiev Igor said the following: > >>> On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: > >>> > >>>> Heh, next try. > >>> > >>> Got a panic, "vm_page_unwire: invalid wire count: 0" > >> > >> Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm= _page_alloc): > >=20 > > Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, therefore i sli= ghtly modified your patch: >=20 > I apologize for my haste, it should have been VM_ALLOC_WIRED. > Here is a corrected patch: > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision = 214318) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working c= opy) > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include >=20 > /* > * Programming rules. > @@ -464,7 +465,7 @@ > uiomove_fromphys(&m, off, bytes, uio); > VM_OBJECT_LOCK(obj); > vm_page_wakeup(m); > - } else if (m !=3D NULL && uio->uio_segflg =3D=3D UIO_NOCOPY) { > + } else if (uio->uio_segflg =3D=3D UIO_NOCOPY) { > /* > * The code below is here to make sendfile(2) work > * correctly with ZFS. As pointed out by ups@ > @@ -474,9 +475,23 @@ > */ > KASSERT(off =3D=3D 0, > ("unexpected offset in mappedread for sendfile")); > - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > + if (m !=3D NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) > goto again; > - vm_page_busy(m); > + if (m =3D=3D NULL) { > + m =3D vm_page_alloc(obj, OFF_TO_IDX(start), > + VM_ALLOC_NOBUSY | VM_ALLOC_WIRED | VM_ALLOC_NORMAL); > + if (m =3D=3D NULL) { > + VM_OBJECT_UNLOCK(obj); > + VM_WAIT; > + VM_OBJECT_LOCK(obj); > + goto again; > + } > + } else { > + vm_page_lock_queues(); > + vm_page_wire(m); > + vm_page_unlock_queues(); > + } > + vm_page_io_start(m); Why wiring the page if it is busied ? --H0CA2egUVSYJgt8C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzMrEIACgkQC3+MBN1Mb4jzjACgpf/B2jMS6qDaPNXeiZh9PsB8 srcAoOonoQX11nzARvxoXtKXWY7UVVJu =DbNN -----END PGP SIGNATURE----- --H0CA2egUVSYJgt8C--